Search code examples
c#debuggingwindbgcrash-dumpsminidump

How to open a C# crash dump (Minidump)


Our C# application calls MinidumpWriteDump upon an unhandled exception.

I have received some crash dumps from users where i cannot seem to open the crash dump with SOS and see the exception that caused the crash.

The dump type we're taking is MiniDumpWithPrivateReadWriteMemory

I have my _NT_SYMBOL_PATH configured to use MS public symbol server, and when debugging this crash dump in WinDBG, it automatically downloads the needed DLLs (as this dump was taken on a machine with a different version of .NET 2 - namely the one that ends with .3053)

When running !Threads i am getting this output:

Failed to request ThreadStore

I have gone over ALL POSSIBLE sites that explain techniques for handling different versions of the CLR than the one taken in the dump machine, none worked for me.

What can i do in order to debug these crashes?

Are we doing something wrong (taking the wrong kind of dump from the .NET process, etc)

EDIT:

Here's the result of ~*:

0:000> ~* . 0 Id: 1338.258 Suspend: 0 Teb: 7ffdf000 Unfrozen Priority: 0 1 Id: 1338.2a0 Suspend: 0 Teb: 7ffde000 Unfrozen Priority: 0 2 Id: 1338.1fd4 Suspend: 0 Teb: 7ffdd000 Unfrozen Priority: 0 3 Id: 1338.17e8 Suspend: 0 Teb: 7ffda000 Unfrozen Priority: 0 4 Id: 1338.1148 Suspend: 0 Teb: 7ffd9000 Unfrozen Priority: 0 5 Id: 1338.b1c Suspend: 0 Teb: 7ffd7000 Unfrozen Priority: 0 6 Id: 1338.f94 Suspend: 0 Teb: 7ffd4000 Unfrozen Priority: 0 7 Id: 1338.11b4 Suspend: 0 Teb: 7ff4f000 Unfrozen Priority: 0 8 Id: 1338.1814 Suspend: 0 Teb: 7ff4e000 Unfrozen Priority: 0 9 Id: 1338.1cc4 Suspend: 0 Teb: 7ffdb000 Unfrozen Priority: 0 10 Id: 1338.1e48 Suspend: 0 Teb: 7ffd5000 Unfrozen Priority: 0 11 Id: 1338.1a5c Suspend: 0 Teb: 7ff4c000 Unfrozen Priority: 0 12 Id: 1338.1874 Suspend: 0 Teb: 7ff4b000 Unfrozen Priority: 0 13 Id: 1338.1498 Suspend: 0 Teb: 7ff4a000 Unfrozen Priority: 0

Here's the result of !analyze -v:

analyze


Solution

  • WinDbg is probably loading the wrong version of the mscorwks DLL. Try using .cordll -lp to explicitly tell WinDbg which CLR debug modules it should load, see also this blog post: Issues Debugging Managed Code in WinDbg with SOS and PSSCOR2 (e.g. "Failed to request ThreadStore")