Long (boring) story
I currently have an application that causes an exception on only one PC. After some digging, I could encapsulate the problem with a small sample application, but the true reason is still hidden.
Due to the fact that Visual Studio is not installed on this PC, and we cannot do this, I was looking for another solution to find the true reason.
In the first approach, I erased my small application more and more, just carefully reading the exception message, compare with the code and try the error to go to the specific line of the problem. But this does not help to get all the information about the current values of all the variables used, etc.
So, I was looking for another best way to get the information I need. I have read about Dumps and Minidumps for a long time, but I don’t need them, because so far I could always reproduce the user-described script on my developer or test machine.
But this time, it seems, there is only one computer that has a problem, and, unfortunately, changing the whole machine or installing everything new is not.
To learn how to work with dumps, I wrote a simple C # test application containing one button that does nothing more than throw new ArgumentException("Test");
Now I need to create such a magic dump file after clicking on the malicious button, read it in Visual Studio 2008 Professional and look at it like a normal running application in VS, except that it’s a step further, etc. will not work.
As far as I know, the best tool for creating a dump at a certain point in time is procdump , because of the possibility you can determine when one or more dumps are taken.
So, I just downloaded it and started it by calling procdump -o -e MyApp.exe d:\MyApp.dmp . He claims that MyApp.exe does not exist. Okay, my fault. Just start MyApp first and then procdump.
Procdump works by showing me all of its parameters that it uses, and seems to be waiting for an unhandled exception. Nothing is simpler, I just click my malicious button ... and nothing happens in procdump.
Instead, a dialog box appears from my application explaining that an unhandled exception occurred (unexpected, unexpected) and what I would like to do (Details, Continue, Quit). But no matter what I choose, procdump cannot automatically create the dump file.
If I go and just call procdump -o MyApp.exe d:\MyApp.dmp , when the dialog shows that the dump file seems useless, then after opening it in VS, the call stack just hangs somewhere in ntdll.dll , but nowhere inside of my code (i would suggest that this is a MessageQueue of a dialog waiting for a mouse click).
If I take a closer look at the details, you will find information on how to delegate an unhandled exception to a JIT debugger. But I don’t want a JIT debugger, I would like to minimize the application to get the dump file.
After these attempts, I found ClrDump , but it did not bring the best dumps (if I load it into VS and take a look at the call stack).
Given this data, you now (hopefully) can provide me with a (working) solution for my .Net application:
(short) question
How can I create a dump file when an unhandled exception occurs in a .net application, so that I can download Mypp.pdb files and see in what circumstances this exception was thrown?
Answer
With Naveen and Lex Lee, I could get a little more information on how debugging works with emergency dumps. And now I just like to tell everything that is needed to make it work:
When you want to get a process dump, you can choose between several tools to complete the task:
- procdump
- A simple command line tool that can dump in complex scenarios but does not work to catch .net unhandled exceptions.
- Debugdiag
- A simple graphical tool that can dump on failures (even .net exceptions), but it cannot dump in advanced scripts like Procdump.
As you can see, you will get two tools that can create dumps in different circumstances, so both partners are more competing with dumping at the right time.
After creating a dump with one of the above tools, you need to analyze the dump to find out the cause of the problem. For analysis, you can grab WinDbg. This is part of the Windows Debugging Tool and can be obtained from Microsoft. Unfortunately, the WinDbg entry barrier is quite high, but it is really powerful. Check out this blog post for a better understanding of how to use this tool.
If you have a .Net 4 application and you are using Visual Studio 2010, you can also use it for analysis. It is much easier to use, thanks to a better graphical user interface, but it does not have WinDbg capability. To get a better comparison, you should take a look at this article .
Last but not least, you can also use sos.dll in Visual Studio 2008. Here is an article that describes what you can do with it.