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.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
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.
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.
!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.
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.
windbg-kernel-bugcheck-triage.windbg-kernel-lock-deadlock-triage.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.
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.
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.
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.
Follow FEEDBACK.md and submit reviewed, sanitized feedback to
WinDbg-Feedback.
Include windbg-kernel-verifier-triage and the package version from plugin.json; do not
automatically upload dumps or proprietary driver source.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
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.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original 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.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.