The long (boring) story
Currently i have an application that leads to an exception on only one pc. After some digging around i could encapsulate the problem with a small sample application, but the true reason is still hiding.
Due to the fact that on this pc is no Visual Studio installed nor we are able to do so i searched for another solution to find the true reason.
In a first approach i stripped down my small application more and more by just carefully reading the exception message, compare to the code and try & error to come to the concrete line of problem. But that wouldn't help to get all the informations about what are the current values of all the used variables etc.
So i searched for another better way to get the informations i need. I already read about Dumps and Minidumps about a long time but never need them, cause till now i could always reproduce the user described scenario on my developer or test machine.
But this time there seems to be only one pc having the problem and unfortunately changing the complete machine or installing everything new there isn't an option.
To get familiar on how to work with dumps i just wrote a simple c# test application, containing a single button which does nothing more than throw new ArgumentException("Test");
Now i need to create such a magical dump file after pushing the malicious button, read it into Visual Studio 2008 Professional and can look at it like a normal running application within VS except that Step next, etc. won't work.
As far as i know the best tool to create a dump at a specific point in time is procdump, due to the possibility you can define when one or multiple dumps are taken.
So i simply downloaded it and started it by calling procdump -o -e MyApp.exe d:\MyApp.dmp. It claims that MyApp.exe doesn't exists. Okay, my fault. Just start MyApp first and afterwards procdump.
Procdump is running now showing me all its options it uses and seems to await an unhandled exception. Nothing easier than this, i simply push my malicious button ... and nothing happens in procdump.
Instead a dialog window from my application pops up that explains that an unhandled exception occured (surprise, surprise) and what i'd like to do (Details, Continue, Quit). But no matter what i select, procdump isn't able to create a dump file automatically.
If i go and just call procdump -o MyApp.exe d:\MyApp.dmp when the dialog is showing the dump file seems to be useless, cause after opening it in VS the call stack is just hanging around somewhere in ntdll.dll but nowhere within my code (i would guess that this is the MessageQueue of the dialog waiting for some mouse clicks).
If i take a closer look into the details you'll find some informations about how to delegate the unhandled exception to a JIT-debugger. But i don't want a JIT-debugger, i'd like to crash the application to get the dump file.
After these tries i found ClrDump, but that didn't produce any better dumps (if i load it into VS and take a look at the call stack).
With these informations taken into account you are now (hopefully) able to provide me with a (working) solution for my .Net application:
The (short) question
How i'm able to create a dump file when an unhandled exception occurs within an .net application, that i'm able to load MyApp .pdb files and see under which circumstances the exception was thrown?
The answer
With the help of Naveen and Lex Li i could get a little more insight on how debugging with crash dumps works. And now i just like to recap all the stuff, that is needed to get it to work:
Whenever you like to get a dump of a process, you can select between several tools to get the job done:
- Procdump
- easy command line tool that can create dumps in complicated scenarios, but it does not work to catch .net unhandled exceptions.
- DebugDiag
- easy graphical tool that can create dumps at crashes (even .net exceptions), but it can't create dumps at advanced scenarios like Procdump.
As you can see you'll get two tools that are capable to create dumps under different circumstances, so both are more partners then rivals in creating a dump at the needed point in time.
After creating a dump with one of the above tool it's time to analyze the dump to find out the reason for the problem. For analyzing you can grab WinDbg. It is part of the Debugging Tools for Windows and can be get from Microsoft. Unfortunately is the entry-barrier of WinDbg quite high but it is really powerful. Maybe take a look into this blog to get a better understanding on how to use this tool.
If you have a .Net 4 application and using Visual Studio 2010 you can also use this for analyzing. It's much easier to use, due to the better graphical user interface, but it doesn't have the power of WinDbg. To get a better comparison, you should take a look into this article.
Last but not least you can also use the sos.dll in Visual Studio 2008. Here is the article describing what you can do with it.
-maswitch (full memory). I tried it for the answer at #24874527 – Seedbed