Kernel Bugcheck 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.

Scope

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.

Workflow

1. Establish symbols and bugcheck evidence

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

2. Decode parameters for the specific code

Do not reuse a parameter layout across different bugchecks.

3. Recover the original faulting context

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.

4. Investigate the driver, not just the detector

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

Validation

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.

References

• Bugcheck reference
• 0x3B SYSTEM_SERVICE_EXCEPTION
• 0x7E SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
• Context record
• Trap frame

Feedback

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.