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 kernel thread stacks, synchronization-object evidence, and Driver Verifier deadlock records. A watchdog bugcheck can indicate CPU/DPC progress failures, not necessarily a lock cycle. Establish the actual waits before choosing this workflow.

!locks
!thread <ethread-address>
!process 0 7

enumerates ERESOURCE information. It is not an inventory of all pushlocks, fast mutexes, and spinlocks. For other primitives use documented primitive-specific inspection when available, matching symbols for your driver, its source, and recorded acquisition evidence. State missing owners explicitly.

If Driver Verifier deadlock detection was enabled and the dump contains its records:

!deadlock 1

Inspect the reported resources, acquisition sequence, and threads. Verifier can detect an unsafe ordering before a persistent deadlock actually forms. An empty result without the required verification/history is not proof that the lock order is safe. For Verifier setup/safety use .

thread A holds resource X -> waits for Y owned by B
thread B holds resource Y -> waits for X owned by A

Show evidence for every edge. Check recursive acquisition, callbacks under locks, I/O completion dependencies, and destruction/rundown paths.

Distinguish:

If blocked on an IRP use ; if a chain crosses into a user-mode COM/RPC operation use . Carry the proven graph edges into the next skill rather than starting the same investigation again.

Identify which call path held one resource while acquiring/waiting for another. Check the required IRQL, permitted waits, lock hierarchy, and object lifetime. Private Windows implementation layouts are not prerequisites; if public symbols and captured state cannot recover an edge, request appropriate authorized evidence and keep the conclusion provisional.

Use a consistent acquisition hierarchy, reduce lock scope, avoid unbounded waits/cross-component callbacks while holding resources, and move potentially blocking destruction outside locks where the ownership design permits. Do not replace a lock or add a timeout without preserving invariants and completion/cancellation semantics.

Record the graph, supported cycle/inversion, and offending driver path. Test concurrency, callbacks, teardown, and the same applicable Verifier checks. Separate a demonstrated fix from an unproven contention hypothesis.

Follow and report reviewed, sanitized feedback to WinDbg-Feedback. Include and the package version from ; no automatic dump, lock-history transcript, or driver-source upload.