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
Look for blocked work in an application, service, or user-mode driver host (including UMDF), and threads in wait, COM, RPC, or I/O paths. The process displaying the symptom may not own the underlying defect. Idle worker threads waiting normally are not evidence of a hang.
Workflow
1. Identify the affected operation and its thread
.lastevent
~*kb
!runaway
Confirm why the dump was collected. A dump is a snapshot; .lastevent does not
by itself certify "hang" or "no crash." Identify the UI/serving thread from
application evidence instead of assuming thread zero is always the UI thread.
If work is spinning rather than blocked, collect appropriate CPU evidence.
2. Identify each wait and its owner
Inspect frames around WaitForSingleObject, WaitForMultipleObjects, COM
send/receive, and RPC calls. Use matching symbols/source for your own proxy,
interface, and server registration to determine what was requested.
For each edge record:
process / thread -> waited resource or request -> owner / serving thread
Do not guess a server PID from undocumented private COM layouts. Use available Wait Chain Traversal, RPC/COM tracing, application correlation IDs, or registration/process information, and explicitly mark unresolved edges.
3. Gather corresponding server evidence
Obtain authorized dumps or live state of the relevant server processes close enough in time to represent the same operation. Inspect their serving threads. For kernel context use documented commands such as:
!process 0 7
!thread <ethread>
Available user pages and symbol/context support vary by dump type. If the chain
ends in a kernel lock use windbg-kernel-lock-deadlock-triage; if blocked I/O is supported
by IRP evidence use windbg-kernel-irp-lifecycle-triage. Do not promise process heaps or
user stacks absent from the dump.
4. Distinguish a cycle from a slow or missing responder
- Cycle: show every required wait/owner edge back to the starting actor.
- Contention: a runnable owner may eventually release the resource.
- Starvation: queued work cannot obtain execution capacity.
- Lost completion: the actor/event expected to unblock the waiter no longer exists or no path signals it.
- Slow server: the endpoint is doing work, blocked on another dependency, or looping; gather its evidence before blaming the client.
Multiple snapshots or tracing may be needed to distinguish transient waits from persistent blocking.
Fix patterns and COM boundaries
A synchronous COM call from an STA can pump messages and permit reentrancy. It is not automatically a deadlock. Investigate locks held across calls, callbacks, apartment access, and any non-pumping waits that form an actual dependency cycle.
Possible remedies include asynchronous APIs, shorter lock scopes, moving destruction/cross-process calls outside critical sections, and bounded wait/cancellation protocols where the API supports them. A timeout on the caller does not cancel server work by itself.
If work moves to another apartment, marshal apartment-bound interfaces, keep
captured state alive, and dispatch UI updates to the correct thread. Merely
capturing a COM pointer and this in a worker lambda is not a safe fix.
Validation
Identify the affected thread, relevant resources and owners, and demonstrated cycle or deepest supported blocker. Test the proposed remedy under concurrency, reentrancy, shutdown, and timeout/cancellation. Do not stop at "waiting in RPC." If the server dump or an owner edge is missing, state the unresolved hypothesis.
References
Feedback
Follow FEEDBACK.md and submit only reviewed, sanitized feedback to
WinDbg-Feedback.
Include windbg-user-wait-chain-analysis and the package version from plugin.json; no
automatic capture or public upload of process dumps or full diagnostic
transcripts.