If you're a company wanting to get access to the data from the crash dialog, this article isn't for you. But this is.
Also, I am not an expert in this topic.
Now that that is off my chest, and we've all had fair warning, here's my scenario: I've done something in an application that's caused it to crash and I get the "SomeProgram has encountered a problem and needs to close. We are sorry for this inconvenience." If you click on the "What data does this error report contain?" link, you'll notice it's also created a crash dump of the process.
A couple of times I've wanted to look at the dump file that's sent to the Online Crash Analysis to see if it was my code on the stack. Maybe it's a hard-to-repro thing, or maybe it doesn't repro under the debugger, yada yada.
Frustratingly, it's nearly impossible to get at that .dmp file. If you happen to find it, you can't copy it aside. And if you look for it after dismissing the dialog, the .dmp file has been deleted from the machine.
Or so I thought. Here's the trick that worked for me on Windows XP Professional: use the backup utility to back up the .dmp file, then open it in Visual Studio or Windbg. (I welcome anyone else's suggestions for a less painful process)
Creating an app that shows the dialog(you can skip this step if you already have a crashy app).
When you click the button you should now see the famous dialog. DON'T close it or you'll lose the .dmp!
Finding the .dmp file
It should be in your temp folder. Here's how I find it quickly:
Verify you can't copy the file..
Now you see what I mean. (Cannot copy A8E2728: It is being used by another person or program.) If you wait for the crash dialog to go away, the .dmp file will be removed from your machine. So we have to take action now.
Open up the Backup utility
Back up the .dmp file (you'll have to back up the entire temp dir)
Restoring the .dmp file from backup
Look for the restored .dmp file on your disk:
You should now see what state the program was in when it crashed - check the registers, get the call stack etc.
If you want to look at symbols, I'd recommend reading this article for how to set up the symbol server. You may also want to use strike to get a better picture of the CLR stack. In that case you may find using Windbg and SOS better.
For more information on working with .dmp files consult MSDN.