windbg-kernel-lock-deadlock-triage

Kernel Lock and Deadlock 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.

Detection

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.

Workflow

1. Gather owners and waiters

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

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

2. Inspect recorded lock-order evidence

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 windbg-kernel-verifier-triage.

3. Build and test the graph

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:

• A demonstrated cycle or Verifier-reported order inversion.
• Contention where a runnable owner can progress.
• Starvation or an owner blocked on a separate request.
• Spin/IRQL problems, which are not necessarily blocking-lock deadlocks.