Since monitors can be reacquired reentrantly, it won't be any of the threads that are blocked on the Monitor.Enter call. So it must be one of the other threads.
If there are no other threads, then that's a little strange. Are you running on v1.0 or v1.1 of the .NET framework? On v1.0 there was a bug which could very occasionally cause the monitor to appear to be locked when it wasn't. (But only when you use TryEnter rather than Enter. And I only ever saw it happen on a multi-processor hyper-threaded machine. Didn't happen on 1-CPU hyper-threaded machines, and didn't happen on multi-processor non-hyper-threaded machines...) I'm not aware of any way of discovering which thread a lock is owned by. The implementation of Monitor is all internalcall stuff, i.e. the guts are inside of the CLR. You can see what the data structure Rotor uses for the SyncBlock (the underlying data structure that is used to implement locking) can be seen here: http://dotnet.di.unipi.it/Content/sscli/docs/doxygen/clr/vm/syncblk_8h-s ource.html As you can see, it's all C++. (And even if you could find the SyncBlock in question, it's probably not quite the same in the CLR, so this header file probably isn't much use - I'm just illustrating that it's all deep in the guts of the runtime.) So this stuff would only be accessible if there were some managed API for it - sadly you can't dig around with reflection. I'm not aware of any API to discover this unfortunately. -- Ian Griffiths - DevelopMentor http://www.interact-sw.co.uk/iangblog/ > -----Original Message----- > From: Chris Mullins > Subject: [ADVANCED-DOTNET] 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. =================================== 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
