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.

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

4. Localize the driver path

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.

Fix patterns

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.

Validation

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.

References

• ERESOURCE locks extension
• Deadlock extension
• Driver Verifier deadlock detection
• Thread inspection

Feedback

Follow FEEDBACK.md and report reviewed, sanitized feedback to WinDbg-Feedback. Include windbg-kernel-lock-deadlock-triage and the package version from plugin.json; no automatic dump, lock-history transcript, or driver-source upload.