Skip to main content

windbg-user-exception-triage

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.

소스 정보

저장소
microsoft/win-dev-skills
최근 소스 활동
2026년 10월 7일 20:51
감지된 SKILL.md 언어
영어
스타
492
포크
39

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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.
GitHub에서 보기