使用的WinDbg处于挂起C＃应用程序死锁检测 [英] detecting deadlock in a hung C# application using windbg

查看：245
本文介绍了使用的WinDbg处于挂起C＃应用程序死锁检测的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我的多线程应用程序在C＃2.0中使用线程池每隔几个星期左右挂在刺。



我做了一个syncblk 

 
！syncblk 
 
指数的SyncBlock MonitorHeld递归拥有的线程信息的SyncBlock所有者
 201 05b9493c 979 1 05bc1040 BCC 45 022f3490 System.Collections.ArrayList 
 2875 05b4c914 1 17b99e10 1af8 290 024862d8 MyProg.MyChildClass 
 3045 05b4dbec 1 17ca7e98 1990 664 02392120 MyProg.MyChildClass 
 3046 05b4dc1c 1 17ca8668 1038 666 02394b00 MyProg.MyChildClass 
 3194 05b4f80c 3 1 05b5b638 1594 31 02537b88 MyProg.MyChildClass 
 3072 05b4e114 1 17d660f0 1120 848 023dd578 MyProg.MyChildClass 
 3073 05b4e144 1 17c45c30 1884年518 023dfc2c MyProg.MyChildClass 
 3390 05b51cfc 3 1 16cefcc0 1350 102 02768868 MYPROG .MyChildClass 
 3072 05b4e114 1 17d660f0 1120 848 023dd578 MyProg.MyChildClass 
 3073 05b4e144 1 17c45c30 1884年518 023dfc2c MyProg.MyChildClass

我已经删除了数百行看起来像这样的：

 
 3073 05b4e144 1 17c45c30 1884年518 023dfc2c MyProg.MyChildClass

线程持有979显示器是锁定一个ArrayList，但谁正在等待其他所有线程都试图获得一个不同的对象上readerlock。



我不知道哪个锁都读线程试图获取，但我不知道是谁在持有该锁。我如何发现了??



与MonitorHeld = 1的所有主题clrstack和DSO的相似的输出。
这里是线程持有979锁（n = 45）和等待读取器线程（ID = 290）的DSO和clrstack输出。同样的，当我做
〜* E！clrstack
与Monitor.Enter所有线程具有相同的堆栈在以下2个线程的clrstack 

 
！0：000>〜45E clrstack 
 OS线程ID：0xbcc（45）
 ESP EIP 
 17fbe590 77d2013d [GCFrame：17fbe590] 
 17fbe6cc 77d2013d [HelperMethodFrame：17fbe6cc] System.Threading.Monitor.Enter（System.Object的）
 17fbe720 00638427 MyProg.MyParentClass.ClockTimeElapsed（的System.DateTime）
 17fbe798 00637cf6 MyProg.MyEngine.ClockTimeElapsed（System.Object的） 
 17fbe830 71df843f System.Threading._TimerCallback.TimerCallback_Context（System.Object的）
 17fbe838 71e302ff System.Threading.ExecutionContext.Run（System.Threading.ExecutionContext，System.Threading.ContextCallback，System.Object的）
 17fbe850 71df83ab System.Threading._TimerCallback.PerformTimerCallback（System.Object的）
 17fbe9dc 74071b4c [GCFrame：17fbe9dc] 
 



 
 0：000>〜45E DSO 
 OS线程ID：！0xbcc（45）
 ESP / REG对象名称
 17fbe5a8 022a2ff4 System.Globalization.DaylightTime 
 17fbe5ac 022a2f3c System.Int32 
 17fbe5c8 02537b88 MyProg.MyChildClass 
 17fbe738 02537b88 MyProg.MyChildClass 
 17fbe740 02537b88 MyProg.MyChildClass 
 17fbe7ac 11572f28 System.Collections.ArrayList + ArrayListEnumeratorSimple 
 17fbe7b0 022f3490 System.Collections.ArrayList 
 17fbe7b4 0231860c System.String错误加载MyConfig.txt 
 17fbe7c0 022f3014 MyProg.MyEngine 
 17fbe84c 0231b48c System.Threading._TimerCallback 
 17fbe9fc 0231b48c的System.Threading。 _TimerCallback 
 



 
 0：000>〜290E clrstack 
 OS线程ID：！0x1af8（290） 
 ESP EIP 
 2e77f39c 77d2013d [HelperMethodFrame_1OBJ：2e77f39c] System.Threading.ReaderWriterLock.AcquireReaderLockInternal（Int32）已
 2e77f3f8 0c3630d4 MyProg.MyEngine.GetBuyValue（）
 2e77f424 076fd4ad MyProg.MyParentClass。执行（System.Object的）
 2e77f474 71e19fcf System.Threading._ThreadPoolWaitCallback.WaitCallback_Context（System.Object的）
 2e77f47c 71e302ff System.Threading.ExecutionContext.Run（System.Threading.ExecutionContext，System.Threading.ContextCallback， System.Object的）
 2e77f494 71e1a533 System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal（System.Threading._ThreadPoolWaitCallback）
 2e77f4a8 71e1a3c9 System.Threading._ThreadPoolWaitCallback.PerformWaitCallback（System.Object的）
 2e77f638 74071b4c [GCFrame ：2e77f638] 
 



 
 0：000>〜290E DSO 
 OS线程ID：！0x1af8（ 290）
 ESP / REG对象名称
 2e77f35c 022f3014 MyProg.MyEngine 
 2e77f360 02369b98 System.Threading.ContextCallback 
 2e77f378 02369b98 System.Threading.ContextCallback 
 2e77f3dc 023188f8系统。 Threading.ReaderWriterLock 
 2e77f400 024862d8 MyProg.MyChildClass 
 2e77f410 02369b98 System.Threading.ContextCallback 
 2e77f430 024862d8 MyProg.MyChildClass 
 2e77f43c 024862d8 MyProg.MyChildClass 
 2e77f460 02369b98的System.Threading .ContextCallback 
 2e77f490 1156dd74 System.Threading._ThreadPoolWaitCallback


解决方案

我想你应该尝试被这家伙 http://stevestechspot.com/ 编写扩展DLL SOSEX，有一个 ！DLK 它试图找到死锁和他最近增加了一些，这将是利益对您新的命令的命令：




mlocks - 他们的所有者线程ID一起列出所有管理锁和非托管CriticalSections，
。 ！mwaits - 列出所有等待的线程
，如果能够确定，他们正在等待锁定的对象。



。

My multithreaded app in C# 2.0 using threadpool hangs every few weeks or so in prod.

I did a syncblk

!syncblk

Index SyncBlock MonitorHeld Recursion Owning Thread Info  SyncBlock Owner
  201 05b9493c          979         1 05bc1040   bcc  45   022f3490 System.Collections.ArrayList
 2875 05b4c914            1         1 17b99e10  1af8 290   024862d8 MyProg.MyChildClass
 3045 05b4dbec            1         1 17ca7e98  1990 664   02392120 MyProg.MyChildClass
 3046 05b4dc1c            1         1 17ca8668  1038 666   02394b00 MyProg.MyChildClass
 3194 05b4f80c            3         1 05b5b638  1594  31   02537b88 MyProg.MyChildClass 
 3072 05b4e114            1         1 17d660f0  1120 848   023dd578 MyProg.MyChildClass
 3073 05b4e144            1         1 17c45c30  1884 518   023dfc2c MyProg.MyChildClass 
 3390 05b51cfc            3         1 16cefcc0  1350 102   02768868 MyProg.MyChildClass
 3072 05b4e114            1         1 17d660f0  1120 848   023dd578 MyProg.MyChildClass
 3073 05b4e144            1         1 17c45c30  1884 518   023dfc2c MyProg.MyChildClass

I have deleted hundreds of lines that look like this:

3073 05b4e144            1         1 17c45c30  1884 518   023dfc2c MyProg.MyChildClass

The thread holding 979 monitors is locking an arraylist but all other threads who are waiting are trying to acquire a readerlock on a different object.

I do know which lock are all reader threads trying to acquire but I do not know who is holding that lock. How do I find that out??

All threads with MonitorHeld = 1 has the similar output of clrstack and dso. Here is the dso and clrstack output for the thread holding 979 locks (id = 45) and waiting reader threads (id = 290). Similarly, when I do ~* e !clrstack all threads with Monitor.Enter have the same stack as the clrstack on the following 2 threads

0:000> ~45e !clrstack
OS Thread Id: 0xbcc (45)
ESP       EIP     
17fbe590 77d2013d [GCFrame: 17fbe590] 
17fbe6cc 77d2013d [HelperMethodFrame: 17fbe6cc] System.Threading.Monitor.Enter(System.Object)
17fbe720 00638427 MyProg.MyParentClass.ClockTimeElapsed(System.DateTime)
17fbe798 00637cf6 MyProg.MyEngine.ClockTimeElapsed(System.Object)
17fbe830 71df843f System.Threading._TimerCallback.TimerCallback_Context(System.Object)
17fbe838 71e302ff System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
17fbe850 71df83ab System.Threading._TimerCallback.PerformTimerCallback(System.Object)
17fbe9dc 74071b4c [GCFrame: 17fbe9dc] 


0:000> ~45e!dso
OS Thread Id: 0xbcc (45)
ESP/REG  Object   Name
17fbe5a8 022a2ff4 System.Globalization.DaylightTime
17fbe5ac 022a2f3c System.Int32
17fbe5c8 02537b88 MyProg.MyChildClass
17fbe738 02537b88 MyProg.MyChildClass
17fbe740 02537b88 MyProg.MyChildClass
17fbe7ac 11572f28 System.Collections.ArrayList+ArrayListEnumeratorSimple
17fbe7b0 022f3490 System.Collections.ArrayList
17fbe7b4 0231860c System.String    Error loading MyConfig.txt
17fbe7c0 022f3014 MyProg.MyEngine
17fbe84c 0231b48c System.Threading._TimerCallback
17fbe9fc 0231b48c System.Threading._TimerCallback


0:000> ~290e !clrstack
OS Thread Id: 0x1af8 (290)
ESP       EIP     
2e77f39c 77d2013d [HelperMethodFrame_1OBJ: 2e77f39c] System.Threading.ReaderWriterLock.AcquireReaderLockInternal(Int32)
2e77f3f8 0c3630d4 MyProg.MyEngine.GetBuyValue()
2e77f424 076fd4ad MyProg.MyParentClass.Execute(System.Object)
2e77f474 71e19fcf System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(System.Object)
2e77f47c 71e302ff System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
2e77f494 71e1a533 System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(System.Threading._ThreadPoolWaitCallback)
2e77f4a8 71e1a3c9 System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(System.Object)
2e77f638 74071b4c [GCFrame: 2e77f638] 


0:000> ~290e!dso
OS Thread Id: 0x1af8 (290)
ESP/REG  Object   Name
2e77f35c 022f3014 MyProg.MyEngine
2e77f360 02369b98 System.Threading.ContextCallback
2e77f378 02369b98 System.Threading.ContextCallback
2e77f3dc 023188f8 System.Threading.ReaderWriterLock
2e77f400 024862d8 MyProg.MyChildClass
2e77f410 02369b98 System.Threading.ContextCallback
2e77f430 024862d8 MyProg.MyChildClass
2e77f43c 024862d8 MyProg.MyChildClass
2e77f460 02369b98 System.Threading.ContextCallback
2e77f490 1156dd74 System.Threading._ThreadPoolWaitCallback

解决方案

I think you should try the extension dll SOSEX written by this guy http://stevestechspot.com/, there is a !dlk command which tries to find deadlocks and he recently added some new commands which will be of interest for you:

!mlocks – Lists all managed locks and unmanaged CriticalSections, along with their owner thread ID. !mwaits – Lists all waiting threads and, if it can be determined, the lock objects they are waiting on.

这篇关于使用的WinDbg处于挂起C＃应用程序死锁检测的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
C#/.NET最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆