/windbg-user-exception-triage

name: windbg-user-exception-triage
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.'

User-Mode Exception Triage

**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.

When to use

Start here for access violations, heap corruption, stack overflow, fail-fast, breakpoints, and other structured exceptions in a native application, service, or user-mode driver host process dump. This includes UMDF driver failures that occur in their user-mode host. Confirm the dump type from WinDbg; the filename extension alone does not distinguish user-mode from kernel-mode dumps.

Workflow

1. Establish the exception context

.exr -1
.ecxr
k
!analyze -v

Record the exception code, address, parameters, access type, registers, module, and stack. `.ecxr` selects the saved exception context when available. If no exception context was captured, report that limitation rather than treating the currently selected thread as the faulting thread.

Use matching binaries and PDBs for your modules and public Windows symbols. Investigate mismatches or truncated stacks before naming a failing source line.

2. Classify and choose an available investigation

| Evidence | Next step | |---|---| | `0xC0000005` with allocation/free or overrun evidence | `windbg-user-heap-corruption-investigation` | | `0xC0000374` heap corruption | `windbg-user-heap-corruption-investigation` | | `0xC0000017`, `0x8007000E`, or an allocation-failure path | `windbg-user-virtual-memory-exhaustion` | | Lock/unlock failure following coroutine suspension | `windbg-user-mutex-held-across-co-await` | | A TTD recording is available and earlier mutation is in question | `windbg-user-ttd-reverse-debugging-triage` | | No crash exception and evidence of blocked work | `windbg-user-wait-chain-analysis` | | A kernel dump reports a bugcheck | `windbg-kernel-bugcheck-triage` |

Do not classify every address in a heap range as a lifetime bug. Check access type, faulting instruction, object layout, and valid allocation boundaries.

3. Investigate families without a dedicated skill

• **Access violation without a match:** identify the read/write/execute target,

object/register used, and whether bounds, ownership, or synchronization was violated. Distinguish a null pointer from stale or corrupted state.

• **`0xC0000409` / fail-fast:** inspect exception parameters and the documented

fast-fail subcode, then the failing condition and call path. The historical status name alone does not prove a buffer overrun or rule one out. Not every fast-fail carries an HRESULT.

• **`0xC00000FD` / stack overflow:** inspect stack bounds and frame sizes; test

recursion, reentrancy, large frames, and inability to commit stack growth. Use the memory-exhaustion skill when commit evidence supports that branch.

• **`0xE06D7363` / MSVC C++ exception:** establish whether it was handled,

identify the throw/catch path with available symbols, and inspect the exception information supported by the runtime/version. A first-chance throw is not automatically a defect. This package does not decode thrown-object layouts or fully diagnose `noexcept`/termination behavior.

• **Stowed/WinRT exceptions:** preserved error information can precede the

final failure. Correlate its originating stack and nested errors with the application; this package does not include a XAML extension workflow.

• **Illegal instruction or breakpoint:** distinguish CPU/architecture or

code-corruption hypotheses from intentional assertions/debug breaks.

Validation

• Exception context and code are established, or their absence is stated.
• Faulting instruction and relevant object/register agree with the hypothesis.
• Alternatives are tested against evidence, not just stack names.
• Missing memory, symbols, and specialized exception coverage are explicit.
• The proposed fix addresses a demonstrated invariant and has a repro/test plan.

References

• [Exception context](https://learn.microsoft.com/windows-hardware/drivers/debuggercmds/-ecxr--display-exception-context-record-)
• [Exception record](https://learn.microsoft.com/windows-hardware/drivers/debuggercmds/-exr--display-exception-record-)
• [Controlling exceptions and events](https://learn.microsoft.com/windows-hardware/drivers/debugger/controlling-exceptions-and-events)

Feedback

For this skill, follow the plugin's `FEEDBACK.md` and report a reviewed, sanitized issue to [WinDbg-Feedback](https://github.com/microsoft/WinDbg-Feedback/issues). Include `windbg-user-exception-triage` and the package version from `plugin.json`; do not upload dumps or private source automatically.