Skip to content

/windbg-kernel-verifier-triage

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.

BOOST
From plugin
win-dev-skills
46211 skills2 agents
Install
$ npx -y skills add microsoft/win-dev-skills --skill windbg-kernel-verifier-triage --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/windbg-kernel-verifier-triage

Context preview

The summary Claude sees to decide when to auto-load this skill.

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.

SKILL.md

windbg-kernel-verifier-triage.SKILL.md
name: windbg-kernel-verifier-triage
description: '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.'

Driver Verifier 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

Driver Verifier checks kernel driver contracts. Application Verifier is a different user-mode facility; use `windbg-user-heap-corruption-investigation` for its heap stops. Enabled Driver Verifier flags alone do not prove a contract violation.

Use this skill when a verifier-class bugcheck or analysis identifies an actual violation. Examples include `0xC4`, `0xC9`, and `0xE6`; inspect the exact code and parameters rather than treating every stop as the same family.

Workflow

1. Preserve code, subcode, and active configuration

!analyze -v
.bugcheck
!verifier
k

Record the bugcheck, subtype/subcode, offending operation and driver when reported, enabled checks, target build, and evidence availability. Decode each subcode against its documented contract. Existing output may be incomplete in a small dump; do not discard captured evidence merely because live configuration is now different.

2. Decode available I/O history

When the violation supplies an appropriate IRP address and I/O verification state is available:

!iovirp <irp-address>
!irp <irp-address>

Shadow state may preserve information lost from the live request. Correlate it with the decoded contract and use `windbg-kernel-irp-lifecycle-triage` for completion, cancellation, pending state, and ownership.

3. Recover context or follow dependencies

  • Saved exception/trap context: `windbg-kernel-bugcheck-triage`.
  • Lock-order evidence: `windbg-kernel-lock-deadlock-triage`.
  • Outstanding or power request: `windbg-kernel-irp-lifecycle-triage`.

Avoid cyclic dispatch. Carry the evidence already collected to the next skill; re-enter only when a distinct evidence requirement exists.

4. Investigate uncovered violations

For a generic DDI violation, identify the exact precondition (IRQL, lifetime, parameters, or ownership) and the driver call that broke it. For a DMA violation, inspect supported adapter/map/unmap and buffer-lifetime evidence for that subcode. This package does not provide a specialized decoder for every DDI or DMA case; state the gap and continue from documentation and driver source.

Controlled repro

Do not enable Driver Verifier without approval. It can deliberately crash the system and expose boot-critical defects. Use a recoverable test machine, save the current configuration, select relevant vendor drivers/checks, and agree on rollback before restarting. Do not verify every installed driver by default.

Read-only configuration inspection on a test machine:

verifier /querysettings

`verifier /reset` clears settings and normally requires a restart to stop verification; it is a configuration change, not a harmless query. Restore previous intentional settings rather than unconditionally clearing them.

Validation

Name the exact violated contract, link the recorded operation to driver source, and test that the remedy satisfies it under the same checks and workload. Record dump/verification limitations and unverified assumptions. Passing a single repro is not proof that every driver path is safe.

References

  • [Driver Verifier](https://learn.microsoft.com/windows-hardware/drivers/devtest/driver-verifier)
  • [Verifier extension](https://learn.microsoft.com/windows-hardware/drivers/debuggercmds/-verifier)
  • [I/O verifier IRP extension](https://learn.microsoft.com/windows-hardware/drivers/debuggercmds/-iovirp)
  • [0xC4 verifier violation](https://learn.microsoft.com/windows-hardware/drivers/debugger/bug-check-0xc4--driver-verifier-detected-violation)

Feedback

Follow `FEEDBACK.md` and submit reviewed, sanitized feedback to [WinDbg-Feedback](https://github.com/microsoft/WinDbg-Feedback/issues). Include `windbg-kernel-verifier-triage` and the package version from `plugin.json`; do not automatically upload dumps or proprietary driver source.

Read more
Ships withwin-dev-skills

Agent plugins for Windows development and debugging—from apps and services to kernel-mode drivers—with GitHub Copilot, Claude Code, OpenAI Codex, and more. Add this repo as a marketplace once, then install the plugins you need.

Get the whole plugin, auto-invoked

Other skills on win-dev-skills.