2010-03-03 74 views
3

我正在尝试排查间歇性死锁的COM +应用程序故障。上次锁定时,我能够获取dllhost进程的用户模式转储并使用WinDbg进行分析。检查所有的线程和锁后,这一切都归结为这个线程拥有一个关键部分:COM +应用程序死锁故障排除

ChildEBP RetAddr Args to Child    
0deefd00 7c822114 77e6bb08 000004d4 00000000 ntdll!KiFastSystemCallRet 
0deefd04 77e6bb08 000004d4 00000000 0deefd48 ntdll!ZwWaitForSingleObject+0xc 
0deefd74 77e6ba72 000004d4 00002710 00000000 kernel32!WaitForSingleObjectEx+0xac 
0deefd88 75bb22b9 000004d4 00002710 00000000 kernel32!WaitForSingleObject+0x12 
0deeffb8 77e660b9 000a5cc0 00000000 00000000 comsvcs!PingThread+0xf6 
0deeffec 00000000 75bb21f1 000a5cc0 00000000 kernel32!BaseThreadStart+0x34 

它等待的对象是一个事件:

0:016> !handle 4d4 f 
Handle 000004d4 
    Type   Event 
    Attributes 0 
    GrantedAccess 0x1f0003: 
     Delete,ReadControl,WriteDac,WriteOwner,Synch 
     QueryState,ModifyState 
    HandleCount 2 
    PointerCount 4 
    Name   <none> 
    No object specific information available 

至于我可以告诉,事件永远不会发出信号,导致线程挂起并阻塞进程中的其他几个线程。有没有人对接下来的步骤有什么建议来确定发生了什么?

现在,看到该方法称为PingThread,是否有可能试图在已经死锁的进程中ping另一个线程?

UPDATE
这实际上竟然是在Oracle 10.2.0.1客户端的错误。尽管如此,我仍然对如何在没有发现Oracle缺陷数据库中的错误的情况下了解这些想法感兴趣。

回答

0

SIEExtPub可以帮助你找出锁在COM

这里是article这个

如果您在使用本扩展任何问题请回来后

0

你可以使用!locks将尝试自动分析死锁,然后转储线程~* kb的调用堆栈,并检查哪些线程正在等待临界区或事件对象。

有一个例子使用这里:http://www.dumpanalysis.org/blog/index.php/2007/07/28/crash-dump-analysis-patterns-part-9c/

再加上那家伙的网站有许多使用WinDbg的其他类型的死锁,包括托管代码的例子:http://www.dumpanalysis.org/只是做了“僵局”页面上的搜索,希望这有助于。