How to debug a WER minidump of an "ngen"ed image

Question

When ngen is executed on a .NET managed application at installation time, and a crash dump is retrieved from Windows Error Reporting for the app, how can you use it to see a stack trace, variables, etc.?

Here's some background related to the question: We have a .NET app that gets ngened at installation. When it crashes due to an unhandled .NET exception, the crash is bucketted in Windows Error Reporting, and from that I was able to download the minidump.mdmp file from winqual.microsoft.com.

I put minidump.mdmp in a folder containing the .dbg files for the build of the app that crashed, and double-clicked minidump.mdmp to open it in a new instance of VS2008 SP1. My stack trace looks like this:

kernel32.dll!RaiseException() + 0x3d bytes
mscorwks.dll!RaiseTheExceptionInternalOnly() + 0x295 bytes
mscorwks.dll!JIT_Throw() + 0x130 bytes
MyApp.ni.exe!000007feee74c84c()
[Frames below may be incorrect and/or missing, no symbols loaded for MyApp.ni.exe]
0000000070000d5e()
MyApp.ni.exe!000007feee611000()
000000000300bf78()
000000000300bf60()

The Modules window indicates that symbols are loaded for the OS and .NET DLLs, but for the application modules, I get this:

MyApp.exe -> No native symbols in symbol file.
MyApp.ni.exe -> No matching binary found.
MyAppsLibrary.ni.dll -> No matching binary found.

Ducky

Maybe a stupid question, did you compile your app with DEBUG defined so it would create the .pdb files? – Similarity

This question from Stack Overflow may be of interest. #851117 – Similarity

And this is a Geting Started section for crash debugging. microsoft.com/whdc/devtools/debugging/installx86.mspx#a microsoft.com/whdc/devtools/debugging/debugstart.mspx#a – Similarity

The application is built using a Release configuration and DEBUG is not defined; however, the Release configuration is set to output pdb files (the "pdb-only" setting) and I have the pdb files. I've used this approach to successfully debug Win32 native apps before, but this is my first attempt at a ngened .NET app. – Ducky

Thanks too, scope-creep, for the links. Unfortunately, the stackoverflow link just covers getting the crash dump. I have the crash dump, but don't know how to use it. The "Debugging Tools and Symbols" is a bit scary since its support list includes native apps, but it doesn't mention managed apps. :-( – Ducky

Answer 1

The easiest way to debug those dumps is with the Windows Debuggers (Windbg, cdb, or ntsd) and to load the SOS debugger extension (you can search for SOS for more details).

As far as I remember, the NGEN'ed part of thing shouldn't matter for SOS as long as you have the original EXE and the symbols (Since it's your app, I'd expect you have the non ngen'ed exe and symbols).

Rake

Answer 2

"Debugging Tools for Windows" (specifically, WinDBG) has limited support for managed apps. Provided with PDBs, you should be able to see the call stack, including source line references. To see variable values, you'll need to use the SOS plugin, which is more difficult that just opening the call stack window.

Walleyed

Answer 3

If you're able to request the clients to run your app again, ask them to run it with the following environment variable set: COMPLUS_ZapDisable=1 This way CLR won't load the native images when running your app and you'll see your usual modules with symbols on the stack.

http://referencesource.microsoft.com/faq.aspx

Enlarge

Answer 4

Is this of any help for you:

• Symbol issue when debugging C# code

The guy seems to be able to load some symbols to debug his application from the crash dump, had a problem loading the correct symbols but someone answered his question.

Jaggy

Answer 5

Since this is managed code, you may need to set the _NT_EXECUTABLE_IMAGE_PATH environment variable to point to the folders where your executables live. In this case, you'll need to locate the folder in the NativeImage cache that points to your assemblies. The debugger needs the images in order to load the assembly.

Kwabena