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.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
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.
Include windbg-user-ttd-reverse-debugging-triage and the package version from
plugin.json; never automatically upload a recording or its memory/query
contents.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Use with every WinDbg plugin investigation to apply evidence-first reasoning, confidence calibration, contrarian review, structured reporting, and deterministic validation. Not a bug-family-specific triage skill.
The English summary is being prepared. Showing the original description.
Use when a kernel dump reports a Windows bugcheck; decode parameters and recover exception or trap context before investigating your driver. Not for user-mode process crashes or blaming a module from its name alone.
The English summary is being prepared. Showing the original description.
Use when kernel evidence shows stalled I/O, a power IRP, or completion/cancellation misuse; inspect request state and driver ownership. Not for interpreting an empty IRP search in a limited dump as proof of healthy I/O.
The English summary is being prepared. Showing the original description.
Use when kernel threads block on driver synchronization or Verifier reports a lock-order violation; build an owner/waiter graph. Not for treating every watchdog stop as a deadlock or listing every lock type with !locks.
The English summary is being prepared. Showing the original description.
Use when a kernel dump contains Driver Verifier violations; inspect flags, bugcheck subcodes, and available I/O shadow state. Not for Application Verifier user-mode stops or inferring a violation from enabled flags alone.
The English summary is being prepared. Showing the original description.
Use when a native C/C++ app, service, or user-mode driver host (including UMDF) crashes with a structured exception in a dump or WinDbg session, including native faults inside managed processes. Not for managed .NET exceptions, WinUI/XAML app errors, or kernel bugchecks.
The English summary is being prepared. Showing the original description.