User dumps are powerful diagnostics you can enable when an application crashes, and in particular when you see no obvious reason for it to crash.
In my case I have been struggling with Visual Studio crashes, and have been reporting these back to Microsoft. The devs there love user dumps, because they show the exact state of the application when it crashed. A user dump can be opened in a debugger, to reveal call stacks and lot of other useful information.
User dumps have to be enabled and disabled using the registry, and a registry script is handy to do that. I have posted the details on that here, including links to reg script files.
However, it is much easier to do that using a tool, so I added it to IFix. Download IFix to get both this and a lot of other sweet commands.
Enabling/disabling user dumps
Ifix diagnostics –d 1 -f
Disabling user dumps:
Ifix diagnostics –d 0 -f
Check the current settings:
Ifix diagnostics –d 0 –c
You can also change the dump folder, the tool sets it to C:\dumps by default.
Ifix diagnostics –D C:\userdumps -f
The user dumps can be mini dumps or full dumps (see here for the difference) , so they might be later large, and you might eat up your disk pretty fast. A Visual Studio crash will give you a dump file in the order of 0.5 GB. Smaller apps give you much smaller dumps of course. So you should make it a habit of turning off the user dumps after you have done your diagnostics.
Now, looking at what I have collected over a couple of days:
I have a couple of IFix dumps, which bugs I am pretty sure I managed to fix. I have a couple of explorer crashes, interesting in itself – but I think I know how I provoked those, and then some weird crashes I really have no clue why happened. That is of course interesting, and should be target for an upcoming investigation.
If your machine is having random crashes, or is behaving strange, you can turn userdumps on for a while and see what it picks up.
Looking inside a user dump file
When you have a userdump file, you can open it directly in Visual Studio, either by loading it in, just by drag/dropping the file directly into Visual Studio:
Just from this information I can get an idea of what is happening. I see an exception code (1), which if I google it, points to me – in this case – just to an “unknown” exception. I can check the version that is crashing (2), and also see what modules is loaded – and check if that makes sense.
In many cases you don’t have the source code, or symbols (in this case I have, but we’ll start pretending I have not). So, I’ll go to start debugging the dump (!), by selecting (3) – Debug with Mixed.
And after having waited for symbols to load (whatever the debugger can find), I am presented with this nice dialog:
Ahh, I have been trying to access the registry, but without the right access rights!! That makes sense. To read the registry I need to run from an elevated admin prompt, which I obviously didn’t do, but the code should not crash on me – this should be fixed.
What is also very nice here, is that I can view the call stack (!), even without symbols, it picks what it can get. I don’t see all of my own code there, but enough to understand what is going on.
And I now has as much information as I need, I might not even need the symbols/source to fix this.
However, if you have the source code, and want to drill down using that, you can add that to the debugger, see this for all information on that. One thing to be aware of is that you must have a 100% match between the code that crashes and the source/symbols that are to be loaded. If you don’t have that, it will not accept the symbols.
The easy way is to load the dump into Visual Studio with your project open. It should preferably be in debug mode, or you should enable full debug symbols with your release code. But then, if you have the source, you could also just run it directly from your debugger, which is far simpler anyway.
1) If you want to enable/disable dumps for Windows itself, see this post.
2) There are many ways to enable dumps, see this post.