How to open a C# crash dump (Minidump)

2
votes

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

2
c#debuggingwindbgcrash-dumpsminidump
What happens if you open the crash dump file in Visual Studio? - Philipp Schmid
Our application uses .NET 3.5 and VS2008, thus cannot be opened this way (only starting .NET 4 and VS2010 as far as i know). - lysergic-acid
Don't know if that is your problem, but generally creating a mini dump from the crashing app itself is unreliable (see Remarks section). - Christian.K
That works fine, only these specific crashes that were taken on another OS/.NET version seem to give a hard time. What are the alternatives for taking it from the same process? - lysergic-acid
@Christian Taking a process dump from the same process can cause a deadlock, but generally speaking if you managed to create the dump then you have to assume that its probably OK. - Justin

2 Answers

2
votes

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")

1
votes

You need to change options you pass to 'MiniDumpWriteDump' make sure they contain options mentioned here: What is minimum MINIDUMP_TYPE set to dump native C++ process that hosts .net component to be able to use !clrstack in windbg