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.
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
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.
Use a kernel crash dump or authorized live kernel session. A process dump captured after a reboot does not contain the earlier kernel fault. Confirm the dump type with the debugger, not a filename or the user's visible symptom. This skill includes exception-context and trap-frame recovery.
.symfix
.sympath+ <your-vendor-symbol-directory>
.reload
!analyze -v
.bugcheck
k
Replace the placeholder with the approved symbol location for your own binaries. Record dump type, target architecture/build, bugcheck code and parameters, faulting instruction, and available memory. Public Windows symbols suffice for many investigations; do not require private Windows source or PDBs.
| Code | Parameter meaning / next step |
|---|---|
0x1E | P1 exception code; P2 exception address; P3/P4 exception-specific information. These are not generically a CONTEXT pair. |
0x7E | P1 exception code; P2 exception address; P3 EXCEPTION_RECORD; P4 CONTEXT. |
0x3B | P1 exception code; P2 instruction address; P3 CONTEXT; P4 unused. |
0x0A / 0xD1 | Referenced address, IRQL, access information, instruction address. Decode the access field for that code; these parameters are not generally a trap-frame pointer. |
0x50 | Invalid memory reference; parameter interpretation varies with target version. Consult the code reference. |
0x9F | P1 selects the power-failure subtype; use its specific parameter table and windbg-kernel-irp-lifecycle-triage where applicable. |
| Verifier-class stop | Use windbg-kernel-verifier-triage and the exact code/subcode definition. |
Do not reuse a parameter layout across different bugchecks.
For 0x7E:
.exr <P3>
.cxr <P4>
kb
r
For 0x3B:
.cxr <P3>
kb
r
For other exception-style bugchecks, locate a valid saved exception/context
using the documented code procedure and available analysis output. Do not
guess .cxr arguments from arbitrary P1..P4 values.
When !analyze -v or verified stack evidence identifies a TRAP_FRAME:
.trap <trap-frame-address>
kb
r
Trap frames can be partial: some registers may be missing or reconstructed incorrectly. Note the debugger's warnings and do not treat unsaved registers as reliable evidence. If a frame is missing, malformed, or absent from the dump, report the limitation rather than scanning arbitrary pointers and claiming a recovered context.
!thread
lmvm <driver-module>
.frame /r <frame-number>
Inspect the recovered instruction, register/object used, IRQL, ownership,
and nearby driver frames. A crash in an operating-system routine may result
from prior driver corruption. Conversely, a third-party name in
MODULE_NAME does not establish that the named driver caused the failure.
Verify vendor build identity against the matching binary/PDB.
For concurrency or blocked requests use windbg-kernel-lock-deadlock-triage or
windbg-kernel-irp-lifecycle-triage. Kernel ~ commands select processors, not the
application thread list; use documented thread/process inspection such as
!thread and !process 0 7.
Record the decoded parameters, recovered context and its limitations, and the
evidence connecting the driver's operation to the violated invariant. Test
competing lifetime, bounds, IRQL, and synchronization explanations. Recommend
an instrumented test/repro only with approval; route Verifier evidence to
windbg-kernel-verifier-triage. Do not call a guessed module assignment a proven cause.
Follow FEEDBACK.md and submit only reviewed, sanitized feedback to
WinDbg-Feedback.
Include windbg-kernel-bugcheck-triage and the package version from plugin.json; no
automatic kernel dump, private-symbol, or source upload.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
Use when an app, service, or user-mode driver host heap fails or Application Verifier detects corruption; inspect history and bounds. Not for kernel pool corruption or ordinary OOM.
中文简介正在准备中。当前显示原文说明。