How do I see the c# code that caused a crashdump in clr.dll?

I have a Windows Forms application (.NET 4) that runs fine on my development machine but crashes on two other test machines. I can load the mi开发者_运维问答nidump that it creates in VS2010.

Choosing to "Debug with Mixed" leads to apparently endless (I killed devenv after about 20 minutes) abuse of the CPU by Visual Studio.

When I "Debug with Native Only", it can't find the source (even though I have mirrored the source in the same folder as on the test machine). It simply says:

Unhandled exception at 0x793f5b8c in YourWinApp.exe.hdmp: 0xC0000409: 0xc0000409.

And then shows me

Call stack location: clr.dll!793f5b8c()

How would I find out what's causing the application to crash? Can I take a full crashdump whilst the "Notify Microsoft" dialog is being displayed, and would that help?

Minidump debugging was supposed to be majorly improved in VS2010. Haven't seen a lot of evidence for it myself yet, mixed-mode debugging looks as awkward as it was before when I did some quick tests. Don't take my word for it though. Native-only is however never going to show you a managed call stack.

Tackle this at the source. Write an event handler for AppDomain.CurrentDomain.UnhandledException and register it in your Main() method. Let it display the value of e.ExceptionObject.ToString() in, say, a message box. That gets you the managed stack trace of the exception. While that message box is displayed you could also snap the minidump, ought to get you closer to the crash location.

The particular exception you are getting is however definitely pointing to native C/C++ code. A buffer overflow that is corrupting the stack. Make sure you have the .pdb files for any native code your app uses. And setup the Microsoft symbol server so you get a good native stack trace from the minidump.

Edit: the fact that you don't get UnhandledException raised definitely points to stack integrity checking in the CRT. It was designed to not raise an exception but terminate the program immediately. Necessary behavior because the stack is compromised, the code cannot assume that it can be unwound safely. Given the crash location, it is likely that this check is actually done in the CLR code. I know this wasn't done in previous CLR versions but that might be different in the CLR version included with .NET 4.0

This is going to make it quite difficult to get a managed stack trace. There's a lot you can reverse-engineer from the unmanaged stack trace, as long as you setup the symbol server so that you'll get identifier names from the CLR stack frames. Post that stack trace in your question if you want help interpreting it. A bug in the CLR code is not unlikely btw, you may want to consider calling Microsoft Support. They will however need a consistent repro. They may make do with that all important stack trace if the repro is hard to come by. Setup the symbol server to get a good unmanaged stack trace. Easy in VS2010: Tools + Options, Debugging, Symbols, tick "Microsoft Symbol Servers".

You configure procdump to get full memory dump if the application has unhandled exception ,which you can debug it in VS or Windbg

And the minidump has call-stack information as watson buckets, here is one from CLR team and I wrote about the same

A brief explanation on the watson bucket information that you see in event viewer for unhandled exception

1. ExeFileName
2. Exe Assembly Version
3. Exe Assembly Timestamp
4. Full Name
5. Faulting Assembly version
6. Faulting assembly timestamp
7. Faulting assembly method def
8. Faulting method IL instruction that caused the exception
9. Exception type