« Crash Dump Analysis Patterns (Part 112)
Icons for Memory Dump Analysis Patterns (Part 83) »

Crash Dump Analysis Patterns (Part 9f)

This is a variation of a deadlock pattern where a thread that owns a resource (either in shared or exclusive mode) attempts to acquire it exclusively again. This results in a self-deadlock:

Resource @ 0x85d9c018    Shared 1 owning threads
    Contention Count = 2
    NumberOfExclusiveWaiters = 2
     Threads: 85db0030-02<*>
     Threads Waiting On Exclusive Access:
              85f07d78       85db0030

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

This entry was posted on Wednesday, October 27th, 2010 at 3:53 pm and is filed under Crash Dump Analysis, Crash Dump Patterns, Debugging. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

3 Responses to “Crash Dump Analysis Patterns (Part 9f)”

  1. Crash Dump Analysis » Blog Archive » Icons for Memory Dump Analysis Patterns (Part 83) Says:
    October 27th, 2010 at 4:33 pm

    […] Crash Dump Analysis Exploring Memory Dumps, Software Tracing, Debugging and Malware Analysis Techniques « Crash Dump Analysis Patterns (Part 9f) […]

  2. Lenka Says:
    December 7th, 2010 at 9:01 am

    I think this can happen only if the resource has been first acquired as shared and then exclusively.
    According to WDK resources support recursive locking. The only scenario which is not supported (and which causes deadlocks) is acquiring a resource as shared and then exclusively.

  3. Dmitry Vostokov Says:
    January 2nd, 2011 at 12:36 am

    Thanks for pointing this out!

Leave a Reply