a) Sometimes, an application crashes on a test computer 😉 And sometimes this occurs immediately at startup, so that you don’t have time to attach windbg before to get a crashdump.
b) Sometimes, an application crashes, and immediately restarts on a test computer. This can be hindering the debugging. E.g. because it would be nice to look at the state of the databases at the time of the crash. And because you would like to have a crashdump.
There is a solution for both of these problems. Use the procdump.exe utility of Russinovich. You can attach it to your application immediately at startup and make creating crashdumps automatic.
I use a batchfile
procdump.bat with this content:
procdump.exe -e -ma -x %1.exe %1.dmp
Then I open a commandline in the program folder where the app under examination resides (e.g. C:\Program Files (x86)\Xyz\App) and start the batch via
When the application crashes now, a crashdump is written to the program folder, called
AppNameWithoutDotExe_140304_161853.dmp or the like. The numbers contain date and time. At the same time, in the cmd window where you started it, there is written something like “The process has crashed. A dump has been written to …”
Procdump is something like a debugger and it attaches itself immediately to the app. Therefore debugging protection is triggered when you start to do something in your app that uses debugging protection.
Then, it may be that the app just silently closes. This is reflected in the cmd window by a line like “The process has exited.”
Before I forget it, procdump has another feature that may come in handy sometime. It can monitor an application for its CPU load and create a crasdump when the load gets too high.