windbg-diagnostic-meth…
Use with every WinDbg plugin investigation to apply evidence-first reasoning, confidence…
Use when an app, service, or user-mode driver host TTD recording is available and earlier calls, writes, or lifetimes matter. Not for kernel replay or history from a normal dump.
$ npx -y skills add microsoft/win-dev-skills --skill windbg-user-ttd-reverse-debugging-triage --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/windbg-user-ttd-reverse-debugging-triageContext preview
The summary Claude sees to decide when to auto-load this skill.
Use when an app, service, or user-mode driver host TTD recording is available and earlier calls, writes, or lifetimes matter. Not for kernel replay or history from a normal dump.
name: windbg-user-ttd-reverse-debugging-triage description: 'Use when an app, service, or user-mode driver host TTD recording is available and earlier calls, writes, or lifetimes matter. Not for kernel replay or history from a normal dump.'
**Load `windbg-diagnostic-method` first** if it is not already loaded in this conversation, and apply it throughout for evidence ranking, hypothesis testing, confidence calibration, independent review, and report validation. This skill adds the bug-family-specific commands and evidence requirements.
Time Travel Debugging records a user-mode process for replay, including an authorized application, service, or user-mode driver host process. A dump alone contains no execution timeline. Confirm a valid recording and matching module symbols before attempting timeline queries. It does not record kernel execution or automatically include another process's server-side activity.
Recording can change timing, require substantial storage, and capture sensitive memory. Obtain authorization before capture. Check the installed recorder's help for supported target, architecture, and options. WinDbg's **Launch executable (advanced)** / **Record with Time Travel Debugging** flow can record a named test application without guessing a recorder command.
Open the recorded `.run` file in WinDbg and load public Windows symbols and matching PDBs for your own binaries.
!tt.index dx @$cursession.TTD
Confirm the timeline range. Indexing and data-model availability depend on WinDbg/TTD versions; consult the installed help if the command is unavailable.
dx @$cursession.TTD.Calls("MyModule!MyFunction")
dx @$cursession.TTD.Memory(<start-address>, <end-address>, "w")Query the known function or exact memory range, then inspect relevant results and their timeline positions. An empty result can mean unmatched symbols, uninstrumented execution, or an out-of-range query, not proof of absence.
Use the call query to find allocation/free or module lifetime transitions and the memory query to locate candidate writes. Account for allocator reuse: the same virtual address may represent different objects over the recording.
!tt <position> k r g-
Seek to an actual position returned by the query. `g-` continues backward; use the installed reverse-step controls to refine the search. Capture the last-good and first-bad states, writer/caller stack, and ownership transition.
Do not equate the last write with the bug until you establish the object's identity, valid lifetime, intended invariant, and relevant cross-thread order.
| Evidence | Skill | |---|---| | Bad free/write or allocation-boundary violation | `windbg-user-heap-corruption-investigation` | | Growing allocation/reservation usage | `windbg-user-virtual-memory-exhaustion` | | Lock survives coroutine suspension | `windbg-user-mutex-held-across-co-await` | | Blocker or cross-process dependency at the selected moment | `windbg-user-wait-chain-analysis` |
For other user-mode families continue reasoning from the timeline rather than dispatching to absent skills. For a kernel crash use `windbg-kernel-bugcheck-triage`; TTD is not a kernel-history substitute.
Record the question, trace identity, timeline positions, relevant object lifetime, and source/stack evidence. Test alternatives and state recording boundaries. A reproducible timeline proves what occurred in that recording; it does not establish that instrumentation preserved all production timing.
Follow `FEEDBACK.md` and report a reviewed summary to [WinDbg-Feedback](https://github.com/microsoft/WinDbg-Feedback/issues). Include `windbg-user-ttd-reverse-debugging-triage` and the package version from `plugin.json`; never automatically upload a recording or its memory/query contents.
Agent plugins for Windows development and debugging—from apps and services to kernel-mode drivers—with GitHub Copilot, Claude Code, OpenAI Codex, and more. Add this repo as a marketplace once, then install the plugins you need.
Repo: microsoft/win-dev-skills
Use with every WinDbg plugin investigation to apply evidence-first reasoning, confidence…
Use when a kernel dump reports a Windows bugcheck; decode parameters and recover exception or…
Use when kernel evidence shows stalled I/O, a power IRP, or completion/cancellation misuse;…
Use when kernel threads block on driver synchronization or Verifier reports a lock-order…
Use when a kernel dump contains Driver Verifier violations; inspect flags, bugcheck subcodes,…
Use when a native C/C++ app, service, or user-mode driver host (including UMDF) crashes with…