WinDbg -- 调试关键区(CriticalSection)死锁
本帖最后由 jiangxueqiao 于 2018-9-30 10:11 编辑> **如果图片显示太小，可以放大浏览器页面查看。**
# 一. 演示示例
这里一个有关键区锁死问题的程序，运行之后依次点击“CS锁死”按钮、右上角退出按钮，程序就会卡死。（图1）
> 对于眼下的这个问题，界面完全失去响应，这说明负责消息处理的UI线程阻塞了。对于几乎所有的windows GUI程序，编号为0的初始线程就是UI线程，windows发现该界面一段时间没有消息响应之后就会在标题后面加上“（未响应）”。
# 二. WinDbg调试
启动Windbg，附加到执行进程（F6）。
```~*knv3```查看各个线程的调用堆栈（图3），数字3表示显示的堆栈深度，省略即显示完整堆栈。
\#0号线的栈帧0表示线程程阻塞在```NtWaitForSingleObject```函数，MSDN得知该函数原型为：
```c
NTSTATUS WINAPI NtWaitForSingleObject(
_In_ HANDLE Handle,
_In_ BOOLEAN Alertable,
_In_ PLARGE_INTEGER Timeout
);
```
第一个参数Handle为其等待的句柄，第三个参数TimeOut为超时时间。
同样从栈帧0得知NtWaitForSingleObject正在等待句柄000000c4，超时时间为0（即没信号就一直等待）。
```!handle 000000c4 f``` 命令查看000000c4句柄的信息（图4）：
现在我们知道c4句柄就是线程ID:20d0的句柄，主线程在退出的时候等待该线程退出，而该线程一直没有退出，所以主线程卡死了。
根据图3得知20d0线程就是#1线程，```~1kvn```查看该线程完整堆栈（图5）：
栈帧00 ```NtWaitForSingleObject```表示线程在等待000000c0句柄。
### !handle
```!handle 000000c0 f```查看句柄信息，得知c0句柄为事件句柄：
```
0:002> !handle c0 f
Handle c0
Type Event
Attributes 0
GrantedAccess 0x100003:
Synch
QueryState,ModifyState
HandleCount 2
PointerCount 4
Name <none>
Object Specific Information
Event Type Auto Reset
Event is Waiting
```
### !locks
```!locks```查看进程中哪些锁处于锁定状态（图6）：
从第一行结果可以得知是gcsName临界区（需要有pdb才会显示具体变量名）处于锁定状态。
> 其实，我们从栈帧02 ```RtlEnterCriticalSection```也可以很快的知道该线程一直在等待进入关键区。
经过分析，知道程序无法退出的原因了：线程#1中的关键区gcsName处于锁定状态（也就是一直等待进入关键区），导致线程#1阻塞无法执行。又因主线程在退出的时候执行了WaitForSingleObject等待#1线程，从而导致主线程卡死。
### RTL_CRITICAL_SECTION结构
关键区机制主要是通过下面这样的RTL_CRITICAL_SECTION结构来实现的，可以通过```dt```命令查看该结构定义：
```
0:002> dt RTL_CRITICAL_SECTION
Test1!RTL_CRITICAL_SECTION
+0x000 DebugInfo : Ptr32 _RTL_CRITICAL_SECTION_DEBUG
+0x004 LockCount : Int4B
+0x008 RecursionCount : Int4B
+0x00c OwningThread : Ptr32 Void
+0x010 LockSemaphore : Ptr32 Void
+0x014 SpinCount : Uint4B
```
其中，LockCount字段用来标识关键区的锁状态，RecursionCount字段用来记录递归次数，用来支持同一个线程多次进入关键区，OwningThread字段用来记录进入（拥有）关键区的线程ID，LockSemaphore用来记录这个关键区对应的事件对象，当有线程需要等待这个关键区时，便是通过等待这个事件来做到的，这个事件对象是按需创建的，如果LockSemaphore为NULL表示这个关键区从来没有线程在此等待过。
通过图6中的OwningThread=738得知，关键区被线程ID为738的线程所拥有，即Enter之后一直没有Leave。
知道了是哪个线程获取了关键区但没有释放，就可以很容易的在代码中定位问题了。
### !cs -l
```!locks```没有显示LockSemaphore字段，我们可以通过```!cs -l```命令获取更为全面的关键区信息：
从上图可以看到LockSemaphore=0xC0，正好是#1线程NtWaitForSingleObject的事件对象。 挺不错的问题排查思路。看问题是0#线程等待1#号线程退出，但是1#号线程发生死锁，无法退出。最后导致0#线程卡死（即UI线程）
但是有个问题，1#线程是和谁死锁了呢？ 0xc0有被其他线程持有？导致资源没有释放？ 谢谢LZ分享 唉，微软的东西 …… 能用别的就用别的吧。 这个有点意思~~~先回帖插个眼再仔细看看~~ 好东西。。 这个不错，要支持... {:1_921:}如果能给出解决办法就好了，希望楼主再写详细一点 难度有点大，还是感谢
页:
[1]
2