How can .NET threads be waiting on a syncblk which is not owned by any thread?

SyncBlock 000000019f1ec5d8 is the one with no owner. Is also the only one with an even MonitorHeld count. Since the MonitorHeld increments with 1 for the owner and 2 for each waiter my guess would be that this is a resource that was released just before the dump was taken, and there was not yet granted a new owner. Unfair resources signal all waiters on release and the waiters rush to acquire it (this unfair behavior avoid convoy locks). Until the waiters are scheduled and run, and the first waiter grabs the resource, there will be no owner.

See also A high waiter count on a free critical section may indicate a lock convoy:

If you're debugging a performance problem in your application, you may run across a critical section in a very strange state: A lot of threads are waiting for it, but nobody owns it!

...

This state means that the previous owner of the critical section has just exited it and signalled a waiting thread to take it, but that thread hasn't yet gotten a chance to run yet

What you describe might have several reasons:

• Owning thread got unstable with some nasty access violations
• Owning thread got unstable with OutOfMemoryExceptions
• Some part of the system (like a driver...) caused a strange situation
• Some 3rd-party library using native code caused the process to become unstable
• Some essential part of the framework (like GC/memory management/thread management) got unstable and/or died while in the middle of some important operation

Any of the above is rather hard to reproduce...

For a nice summary on syncblk see http://blogs.msdn.com/b/tess/archive/2006/01/09/a-hang-scenario-locks-and-critical-sections.aspx

Possibility 1: The syncblk is cleared and the next of the 16 threads will grab it as soon as it is scheduled again.Possibility 2: You have corrupt memory.