本文通过一个实例来讲解如何使用WinDbg来调试Windows CriticalSection死锁的问题。
一. 演示示例
这里有一个关键区锁死问题的程序,运行之后依次点击“CS锁死”按钮、右上角退出按钮,程序就会卡死。
对于眼下的这个问题,界面完全失去响应,这说明负责消息处理的UI线程阻塞了。
对于几乎所有的windows GUI程序,编号为0的初始线程就是UI线程,windows发现该界面一段时间没有消息响应之后就会在标题后面加上“(未响应)”。
二. WinDbg调试
启动Windbg,附加到执行进程(F6)。
~*knv3
查看各个线程的调用堆栈,数字3表示显示的堆栈深度,省略即显示完整堆栈。
#0号线的栈帧0表示线程程阻塞在NtWaitForSingleObject
函数,MSDN得知该函数原型为:
1 | NTSTATUS WINAPI NtWaitForSingleObject( |
第一个参数Handle为其等待的句柄,第三个参数TimeOut为超时时间。
同样从栈帧0得知NtWaitForSingleObject正在等待句柄000000c4,超时时间为0(即没信号就一直等待)。
!handle 000000c4 f
命令查看000000c4句柄的信息:
现在我们知道c4句柄就是线程ID:20d0的句柄,主线程在退出的时候等待该线程退出,而该线程一直没有退出,所以主线程卡死了。
根据图3得知20d0线程就是#1线程,~1kvn
查看该线程完整堆栈:
栈帧00 NtWaitForSingleObject
表示线程在等待000000c0句柄。
!handle
!handle 000000c0 f
查看句柄信息,得知c0句柄为事件句柄:
1 | 0:002> !handle c0 f |
!locks
!locks
查看进程中哪些锁处于锁定状态:
从第一行结果可以得知是gcsName临界区(需要有pdb才会显示具体变量名)处于锁定状态。
其实,我们从栈帧02
RtlEnterCriticalSection
也可以很快的知道该线程一直在等待进入关键区。
经过分析,知道程序无法退出的原因了:线程#1中的关键区gcsName处于锁定状态(也就是一直等待进入关键区),导致线程#1阻塞无法执行。又因主线程在退出的时候执行了WaitForSingleObject等待#1线程,从而导致主线程卡死。
RTL_CRITICAL_SECTION结构
关键区机制主要是通过下面这样的RTL_CRITICAL_SECTION结构来实现的,可以通过dt
命令查看该结构定义:
1 | 0:002> dt RTL_CRITICAL_SECTION |
其中,LockCount字段用来标识关键区的锁状态,RecursionCount字段用来记录递归次数,用来支持同一个线程多次进入关键区,OwningThread字段用来记录进入(拥有)关键区的线程ID,LockSemaphore用来记录这个关键区对应的事件对象,当有线程需要等待这个关键区时,便是通过等待这个事件来做到的,这个事件对象是按需创建的,如果LockSemaphore为NULL表示这个关键区从来没有线程在此等待过。
通过图6中的OwningThread=738得知,关键区被线程ID为738的线程所拥有,即Enter之后一直没有Leave。
知道了是哪个线程获取了关键区但没有释放,就可以很容易的在代码中定位问题了。
!cs -l
!locks
没有显示LockSemaphore字段,我们可以通过!cs -l
命令获取更为全面的关键区信息:
从上图可以看到LockSemaphore=0xC0,正好是#1线程NtWaitForSingleObject的事件对象。
文章图片带有“CSDN”水印的说明:
由于该文章和图片最初发表在我的CSDN 博客中,因此图片被 CSDN 自动添加了水印。