Note: What is described below applies to Windows Vista x64 (at least I used such OS). I’m not going to describe what to do with a mini dump – how to analyze it in a debugger (e.g. in Visual Studio); such information can be found in a very good article at CodeProject. What I’m going to present here is how to set up Windows Vista so that mini dumps are created when an application crashes, and enforce they are stored locally on the machine on which that happened.
I believe every developer uses debugger while product creation. However it’s also possible to debug the application after it’s delivered to the client. One of such techniques is postmortem debugging – the act of debugging the memory dump of a process, which is stored in a special file (not human readable).
Microsoft has created a special service – Windows Error Reporting. Prior to Vista, Dr. Watson was default Windows application debugger that created crash dumps. Starting with Vista, Microsoft has replaced Dr. Watson with a new, improved mechanism. In short (supposing Windows Error Reporting is enabled), if an application crashes a mini dump (representation of the state of the process) is created. Mini dump is much smaller but still provides plenty of needed information. Depending on settings, a mini dump can be sent to Microsoft for further analysis. This is default behavior which, at least in my case, resulted in no mini dumps stored locally on the machine where the crash took place.
In order to enforce storing mini dumps locally (so that I could collect them in for the sake of debugging) I had to make a couple of additional steps:
- Add ForceQueue key to Windows registry at the following location: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting; this should be DWORD with value of 1.
- Change error reporting settings so that user is always asked before sending data to Microsoft. This can be done in Control Panel\System and Maintenance\Problem Reports and Solutions\Change settings\Advanced settings.
First setting results in mini dumps being stored at c:\Users\XXX\AppData\Local\Microsoft\Windows\WER\ReportQueue\ReportXXX. However, without the second step it was automatically send with the report to Microsoft – at this point it was not possible for me to get the dump for that crash (correct me if I’m wrong, but I caouldn’t…).
Let’s assume an application crashes now. Go to Control Panel\System and Maintenance\Problem Reports and Solutions\XXX and open the appropriate item on the list. You should get such window:
When you click ‘View a temporary copy of these files’ you will be moved to the folder that contains the dump. Now that you have the dump, you can open it in Visual Studio and start debugging it. Please bear in mind in order to debug the dump you will need debug information (e.g. pdb files). You will probably need a few more modules, for example kernel32.dll but they are easy to collect with Visual Studio. Again, for more details on how to work with mini dumps please refer to this article on CodeProject.
Hi,
Thank you for the post. Do you know what to do in case of debugging a Windows Service, which is .net 4 app?
Eugeniu,
That depends on whether you have access to the server that hosts the web service or not.
If you have, what is described in the post says briefly what to do in order to allow storing mini dumps of application that crashed.
If you don’t have access to the server though things are getting more complex… There are techniques that allow remote debugging. Check WinDbg; there’s a short lesson on how debug remotely with that tool: http://www.codeproject.com/KB/debug/windbg_part1.aspx#_Toc64133666
I hope that helps,
Jarek
Thanks
How do you set this up in Win7. The locations and names seem quite a bit different in Win7 vs Vista.
Thanks,
Brian
Brian,
Here you can find the answer:
http://wiki.blackviper.com/wiki/Problem_Reports_and_Solutions_Control_Panel_Support
Look for ‘Additional Information’ subsection in section related to Windows 7.
Jarek
Hello, Nice and useful article.
Bud I would like add some information.
Important is to set some additional keys in registry to improve core dump it’s described in msdn article (you can also setup different dump options per application):
http://msdn.microsoft.com/en-us/library/bb787181(v=vs.85).aspx
for more information see also this link:
http://msdn.microsoft.com/en-us/library/bb513638(v=vs.85).aspx
Przemek, thanks for sharing!
Thank you for the article!
I have spent half a day to figure out how to get dump files on windows 2008 x64, there is no ForceQueue entry on my machine. I’m reading advanced .net debugging, it says I need to set this entry, I failed to find it.
your article is really helpful.
I’m now still have a question about dump files, can we get Just in time feature without installing vs? I’d like to debug when the error arises, but it seems if vs is not installed, just in time is not available.
Thanks and Regards
Harry,
You need to have a debugger you can open dump file with. It can be vs or any other dubugger available on the market.
Jare