如何使用windbg从挂起转储中找到句柄所有者?

时间:2009-01-22 17:08:47

标签: windbg deadlock handle

如何在windbg中找出哪个主题是我的事件句柄的所有者:

我正在运行

!handle 00003aec f

并获取

Handle 00003aec
  Type          Event
  Attributes    0
  GrantedAccess 0x1f0003:
     Delete,ReadControl,WriteDac,WriteOwner,Synch
     QueryState,ModifyState
  HandleCount   2
  PointerCount  4
  Name          <none>
  No object specific information available

回来了,因为没有名字我还没弄明白如何让主人出来证明我的帖子正在等待哪个帖子

[编辑]我必须对转储进行处理,因为原始进程需要在用户计算机上重新启动,因此无法调试实时会话

到目前为止我发现的关于这个主题的最佳讨论是在this blog,但不幸的是我们最终使用了不同的锁方法(我最终使用WaitForMultipleObjectsEx,描述是针对WaitForSingleObject),他似乎可以访问实时流程

我的线程的堆栈跟踪(被阻塞的东西以及我正在寻找当前所有者的那个)是:

0:045> k9
ChildEBP RetAddr 
1130e050 7c90e9ab ntdll!KiFastSystemCallRet
1130e054 7c8094e2 ntdll!ZwWaitForMultipleObjects+0xc
1130e0f0 79ed98fd kernel32!WaitForMultipleObjectsEx+0x12c
1130e158 79ed9889 mscorwks!WaitForMultipleObjectsEx_SO_TOLERANT+0x6f
1130e178 79ed9808 mscorwks!Thread::DoAppropriateAptStateWait+0x3c
1130e1fc 79ed96c4 mscorwks!Thread::DoAppropriateWaitWorker+0x13c
1130e24c 79ed9a62 mscorwks!Thread::DoAppropriateWait+0x40
1130e2a8 79e78944 mscorwks!CLREvent::WaitEx+0xf7
1130e2bc 7a162d84 mscorwks!CLREvent::Wait+0x17
1130e33c 7a02fd94 mscorwks!CRWLock::RWWaitForSingleObject+0x6d
1130e364 79ebd3af mscorwks!CRWLock::StaticAcquireWriterLock+0x12e
1130e410 00f24557 mscorwks!CRWLock::StaticAcquireWriterLockPublic+0xc9

4 个答案:

答案 0 :(得分:2)

查看callstack,看来有问题的堆栈正在使用ReaderWriterLock锁定机制。

1130e410 00f24557 mscorwks!CRWLock::StaticAcquireWriterLockPublic+0xc9

更改为主题9并使用 sos.dll 运行!dso 来转储托管的ReaderWriterLock对象。然后运行!对ReaderWriterLock对象执行操作。我相信你可以查询一个拥有的线程字段。我会测试一下然后看看。

确定这一点的旧学校方法是运行〜* e!clrstack 并检查所有在读写器锁上等待的托管线程,然后查看是否可以找到已输入相同的线程函数但通过锁(即不同的偏移量)

谢谢, 亚伦

注意:不确定是否有链接帖子的方法,但这个方法非常类似于 How do I find the lockholder (reader) of my ReaderWriterLock in windbg

答案 1 :(得分:1)

使用!htrace命令获取线程ID。您必须首先(可能在程序开始时)使用!htrace -enable启用跟踪集合。

0:001> !htrace 00003aec
--------------------------------------
Handle = 0x00003aec - OPEN
Thread ID = 0x00000b48, Process ID = 0x000011e8

...

以上输出是虚构的,对于您的系统会有所不同。但它会为您提供所需的信息 - 线程ID(在我的示例中为0x00000b48)。

  

我必须反对转储   原始进程需要重新启动   在用户机器上,所以无法调试   现场会议。

我不是百分百肯定,但我认为这会奏效:

  1. 附加到流程并运行!htrace -enable
  2. 使用qd从流程中删除。可执行文件将继续。
  3. 您现在可以获取转储文件并使用上述命令 - 我想您将获得所描述的结果。

答案 2 :(得分:0)

你可以从内核转储中挖掘出来。

现在,就内核调试而言,来自sysinternals的livekd应该足够了,但不幸的是它只能在正在运行的系统上使用。

还有一个内核模式memory acquisition tool可能会用来进行转储(以windbg代替)以供以后检查。

否则,启用句柄跟踪(!htrace -enable)和(如果代码对特定线程唯一),可以从堆栈跟踪中得出句柄所有权。

答案 3 :(得分:0)

这是我找到的最终答案。没试过自己。您需要实时调试才能确定所有者。但它很快。 http://weblogs.thinktecture.com/ingo/2006/08/who-is-blocking-that-mutex---fun-with-windbg-cdb-and-kd.html