Program hangs on the other hand are harder to figure out. Technically speaking a hung process hasn't done anything illegal like an access violation, but it is stuck so from the end user's perspective it has 'crashed'. Perhaps the program is busy doing a lengthy operation and it will come back to life; perhaps it's stuck for good. All the user can see is a grayed out window with (Not Responding) added to its titlebar.
What is the hung process doing? We'd need a stack trace to say for sure. But we can't have a minidump generated automatically by the crash handler — because there was no crash. One extreme solution is to use the task manager to get a full memory dump, but that cannot be sent via email as it is huge. |
![]() |
Enter sysinternals procdump tool. ProcDump is a very powerful tool, but we will use it in its most simple guise to just write a minidump of the hung process. Open a command console window and type:
procdump xplorer2
This will create a dump file at the current location (directory) called something like xplorer2_UC_121021_104129.dmp. It is a bit bigger than minidumps but it is 100 times smaller than a full dump, so it is quite manageable via email, especially if zipped. Once emailed you can examine the hung process with your debugger.
NOTE: this simpler method cannot be used if xplorer² hangs on startup; in that case please use ProcDump tool
The obvious drawback is that you need an experienced user on the other side, able to complete some manual (albeit not too hard) operations:
Another important point is to get the exact version number of the hung program, so you can match the program database PDB files when you open the dump file in your debugger, so you can see the stack function names properly. But it can be done; thanks Mark Russinovich!
Post a comment on this topic »