title: Critical section hang analysis with Windbg
body: <p>I recently got myself a dump file generated via procdump when my application remained unresponsive for a while.</p>
  
  <p>When I run !locks on the dump file, I get a lone entry that goes something like:</p>
  
  <pre><code>0:000&gt; !locks
  
  CritSec +123456 at 00123456
  WaiterWoken       No
  LockCount         0
  RecursionCount    2
  OwningThread      aaaa
  EntryCount        0
  ContentionCount   0
  *** Locked
  </code></pre>
  
  <p>Just that one listing. That's all. When I drill down further with:</p>
  
  <pre><code>0:000&gt; dt RTL_CRITICAL_SECTION 00123456
  MyModule!RTL_CRITICAL_SECTION
    +0x000 DebugInfo      : 0x00aabbcc _RTL_CRITICAL_SECTION_DEBUG
    +0x004 LockCount      : 0n-2
    +0x008 RecursionCount : 0n2
    +0x00c OwningThread   : 0x0000aaaa Void
    +0x010 LockSemaphore  : (null)
    +0x014 SpinCount      : 0
  </code></pre>
  
  <p>Questions:</p>
  
  <p>1) Should I take <code>MyModule!RTL_CRITICAL_SECTION</code> as definitive clue this critical section is probably defined inside MyModule?</p>
  
  <p>2) Is there a way to make Windbg display the actual variable name of this critical section? (i.e assuming #1 is true and this is a CS the application code has defined/access to.)</p>
  
  <p>3) Why do the LockCount values in the aforementioned listings at odds with each other? (one has 0 and the other has -2.)</p>
  
  <p>4) I think I understand LockCount well enough to know it can't go below -1. Not to mention RecursionCount seems to be badly out of step with LockCount.</p>
  
  <p>I guess the bottom line question is should I just chalk this up to corrupted CS?</p>