The approach that I have found to be most useful is to use the SyncBlk command in SOS. If you're not familiar with it, SOS is a native debugger extension that comes with the .NET SDK that provides access to CLR data structures. I has a bit of a learning curve, but it is totally invaluable when debugging certain tough problems. You can use SOS from within VS.NET 2003, but I often find it more convenient to use WinDbg instead. Here are some links about SOS:
http://msdn.microsoft.com/msdnmag/issues/03/06/bugslayer/default.aspx - MSDN Article about SOS by John Robbins. John's book (Debugging Applications for Microsoft .Net ...) is also required reading for any hard-core debugger. http://msdn.microsoft.com/library/en-us/dnbda/html/dbgch03.asp - "Production debugging for .NET framework applications" from the MS PAG group. Has some great info about SOS, and even a whole section on debugging contention problems. Just keep in mind it was written for .NET 1.0 and SOS is a little different in .NET 1.1 (most notably, you no longer need ".bin" files). Just typing "!SyncBlk" will effectively give you a list of all currently locked Monitors, and the thread ID that is holding the lock. Here is example output from the SOS documentation (Tool Developers Guide\Samples\sos\SOS.htm in the .NET SDK directory): 0:001> !SyncBlk Index SyncBlock MonitorHeld Recursion Thread ThreadID Object Waiting 46 001655e0 1 1 150c98 70 1 050a5060 System.Web.HttpApplication 294 00165664 1 1 1ad5f0 4cc 4 010a7a64 System.Web.HttpApplication 299 00164f84 1 1 1d6598 e38 11 051a27e4 System.Web.HttpApplication If there are many, you can find the one you're looking for by comparing the object type and instance address with the object you are waiting for. And if you really have too many SyncBlocks to look through, you can even find the SyncBlk index used by any arbitrary object by looking at the objects ObjHeader (sync block index is the lower 27 bits of the word in memory just before the object itself) - surprisingly SOS doesn't seem to have a command to do this for you automatically. Hope this helps, Rick ----- Original Message ----- From: "Chris Mullins" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, March 16, 2004 5:46 PM Subject: Debugging Deadlock > I've got a large system built in .NET that has a rarely occurring > deadlock during shutdown. > > > > The deadlock is around a System.Threading.Monitor. > > > > My problem is that on the rare occasion that I can get the deadlock to > occur, and the debugger to stop everything, all that I can see are a > dozen threads blocked on the Montior.Enter call. > > > > I'm trying to figure out how to look at the Monitor and figure out which > thread is actually inside the monitor, and then determine the call stack > for that thread. None of the books or articles that I've found has any > details on how to debug these issues in .NET. > > > > -- > > Chris Mullins > > > =================================== > This list is hosted by DevelopMentorŪ http://www.develop.com > Some .NET courses you may be interested in: > > NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles > http://www.develop.com/courses/gaspdotnetls > > View archives and manage your subscription(s) at http://discuss.develop.com > =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
