windbg 分析线程死锁

合集 - .NET8(13)

1..NET8依赖注入新特性Keyed services2023-11-162.C#12中的Primary Constructors（主构造函数）2023-11-173..NET8 Blazor的Auto渲染模式的初体验2023-11-184..NET8 Blazor新特性 流式渲染2023-11-195.C#12中的Collection expressions（集合表达式语法糖）2023-11-206.将 .NET Aspire 部署到 Kubernetes 集群2023-12-077.WinForm 开源组件 Realtiizor2024-12-088..NET 中 Logger 常被忽视的方法 BeginScope2025-01-219..NET中优雅使用Patch: JsonPatch2025-02-0610.dotnet-trace 分析.net程序性能2025-05-1711.用 Sidecar 容器为 .NET Core 应用做诊断和性能分析2025-05-2012.WinDbg 分析 .NET Dump 线程锁问题2025-05-24

13.windbg 分析线程死锁06-03

收起

目录

• 一、第一步：宏观看整体指标 !tp
• 二、第二步：排查托管锁 !syncblk
• 三、第三步：抽卡死线程栈（从syncblk里提取OS-TID）
• 四、第四步：结合代码解释「偶发正常、随机卡死」
• 五、第五步：区分两种死锁、落地修复
• 精简口诀

 

正文

整套ASP.NET线程卡死分析步骤总结（标准化排查套路）

回到顶部

一、第一步：宏观看整体指标 !tp

1. 查看线程池Worker总数、Running/Idle、排队队列；
2. 特征：Running=总线程、Idle=0、队列积压几千 → 大批量线程永久卡死不释放。
3. 初步结论：不是瞬时并发高，是线程泄漏卡死。

回到顶部

二、第二步：排查托管锁 !syncblk

1. 看每条：MonitorHeld=占用数、有无等待的Waiter线程
2. ① 有大量等待线程 = 多lock互相争抢，传统Monitor死锁
3. ② 只有占用、无等待线程 = 线程拿着锁卡在业务代码，锁是副产品，不是元凶（你的场景）

回到顶部

三、第三步：抽卡死线程栈（从syncblk里提取OS-TID）

~~[0xTID]s;!clrstack 打印单个卡死线程托管堆栈：

1. 栈出现：ManualResetEventSlim.Wait → Task.InternalWait → Task.Wait()
   → 锁定：同步.Wait()阻塞异步任务，上下文死锁。
2. 向上追溯业务类：定位出事方法（ServiceDiscovery、MatrixHelper、HttpModule、Controller）。

回到顶部

四、第四步：结合代码解释「偶发正常、随机卡死」

1. 命中缓存/连接复用：GetAsync同步执行完毕，返回已完成Task，await不放线程，全链路顺行，正常释放；
2. 真实跨网IO：返回未完成Task，await释放工作线程；IO完成回调要切回AspNetSynchronizationContext，但主线程被.Wait()占死 → 闭环死锁、线程永久滞留。

回到顶部

五、第五步：区分两种死锁、落地修复

1. 传统lock死锁：A拿锁1等锁2、B拿锁2等锁1 → 改锁顺序、缩小lock范围；
2. ASP上下文死锁(本次故障)：同步.Wait()/Result + await无ConfigureAwait(false)
   修复二选一：
   • 方案1：全链路改成async/await，删除所有.Wait()；
   • 方案2：所有await xxx.ConfigureAwait(false)，切断回调绑定请求上下文。

回到顶部

精简口诀

!tp看池子满不满，!syncblk辨锁死还是卡死，切线程栈找Wait，缓存决定偶发好坏