用途：当应用、服务或用户模式驱动宿主（含 UMDF）出现无响应，且阻塞发生在锁、COM/RPC、I/O 或跨进程等待路径时，沿等待链找到阻塞源头。进程表现症状不代表其自身拥有缺陷；正常空闲工作线程等待不构成挂起证据。
用法：先加载并全程应用 windbg-diagnostic-method 进行证据分级、假设检验、置信度校准与报告验证。
流程：一、用 .lastevent、~*kb、!runaway 确认转储收集原因并识别受影响线程；转储只是快照，.lastevent 本身不能证明“挂起”或“无崩溃”，应依据应用证据识别 UI/服务线程而非假定线程零。若工作是自旋而非阻塞，改收集 CPU 证据。二、检查 WaitForSingleObject、WaitForMultipleObjects、COM 收发与 RPC 调用附近的帧，结合匹配的符号/源码确定请求内容；对每条边记录：进程/线程 -> 等待的资源或请求 -> 持有者/服务线程。不要从无文档的私有 COM 布局猜测服务 PID，应使用 Wait Chain Traversal、RPC/COM 跟踪、应用关联 ID 或注册/进程信息，无法解析的边须明确标注。三、获取相关服务进程的授权转储或实时状态，检查其服务线程；内核上下文可用 !process 0 7 与 !thread <ethread>。用户页与符号支持因转储类型而异，若链终止于内核锁改用 windbg-kernel-lock-deadlock-triage，若阻塞 I/O 有 IRP 证据改用 windbg-kernel-irp-lifecycle-triage。不要承诺转储中不存在的进程堆或用户栈。四、区分环路、争用、饥饿、丢失完成与慢服务端；必要时用多次快照或跟踪区分瞬时等待与持续阻塞。
COM 边界：STA 中的同步 COM 调用可能泵消息并允许重入，不必然死锁；应调查跨调用持有的锁、回调、套间访问及构成真实依赖环的非泵等待。可能缓解手段包括异步 API、缩短锁范围、将析构/跨进程调用移出临界区，以及在 API 支持时采用有界等待/取消协议；调用方超时本身不取消服务端工作。若工作迁移套间，应封送套间绑定接口、保持捕获状态存活并把 UI 更新派发到正确线程。
验证：确认受影响线程、相关资源与持有者，展示环路或最深的受支持阻塞点，并在并发、重入、关闭与超时/取消场景下测试修复。若缺少服务端转储或某条持有者边，需说明未解决的假设。反馈按 FEEDBACK.md 提交经过审阅与脱敏的内容至 WinDbg-Feedback，并附 windbg-user-wait-chain-analysis 与 plugin.json 中的包版本；勿自动捕获或公开上传进程转储与完整诊断记录。