reverse-skills-max: initial public release (restored, redacted, hardened)

vendor-new/win-dev-skills/plugins/windbg/skills/windbg-user-exception-triage/SKILL.md

@@ -0,0 +1,98 @@
+---
+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
+
+```text
+.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.