使用WinDbg调试关键区死锁

发表于 更新于 分类于 本文字数： 995 阅读时长 ≈ 4 分钟

本文通过一个实例来讲解如何使用 WinDbg 来调试 Windows CriticalSection 死锁的问题。

演示示例

这里有一个关键区锁死问题的程序，运行之后依次点击“CS 锁死”按钮、右上角退出按钮，程序就会卡死。

对于眼下的这个问题，界面完全失去响应，这说明负责消息处理的 UI 线程阻塞了。

对于几乎所有的 windows GUI 程序，编号为 0 的初始线程就是 UI 线程，windows 发现该界面一段时间没有消息响应之后就会在标题后面加上“（未响应）”。

WinDbg 调试

启动 Windbg，附加到执行进程（F6）。

~*knv3查看各个线程的调用堆栈，数字 3 表示显示的堆栈深度，省略即显示完整堆栈。

#0 号线的栈帧 0 表示线程程阻塞在NtWaitForSingleObject函数，MSDN 得知该函数原型为：

1
2
3
4
5
NTSTATUS WINAPI NtWaitForSingleObject(
 _In_ HANDLE         Handle,
  _In_ BOOLEAN        Alertable,
  _In_ PLARGE_INTEGER Timeout
);

第一个参数 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
2
3
4
5
6
7
8
9
10
11
12
13
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查看进程中哪些锁处于锁定状态：

从第一行结果可以得知是 gcsName 临界区（需要有 pdb 才会显示具体变量名）处于锁定状态。

其实，我们从栈帧 02 RtlEnterCriticalSection也可以很快的知道该线程一直在等待进入关键区。

经过分析，知道程序无法退出的原因了：线程#1 中的关键区 gcsName 处于锁定状态（也就是一直等待进入关键区），导致线程#1 阻塞无法执行。又因主线程在退出的时候执行了 WaitForSingleObject 等待#1 线程，从而导致主线程卡死。

RTL_CRITICAL_SECTION 结构

关键区机制主要是通过下面这样的 RTL_CRITICAL_SECTION 结构来实现的，可以通过dt命令查看该结构定义：

1
2
3
4
5
6
7
8
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 的事件对象。

文章图片带有“CSDN”水印的说明：
由于该文章和图片最初发表在我的CSDN 博客中，因此图片被 CSDN 自动添加了水印。