Harvesting Memory Dumps (2)

August 31st, 2009

We knew that one can generate a crash dump file by pressing Ctrl-Scrlk, and MSDN has articles detailing how. First, you’ll need Enabling a Kernel-Mode Dump File, and then Forcing a System Crash from the Keyboard. There are several caveats that you need to know before instructing users to do so.

First of all, the user’s page file must be configured correctly following the guide line of Microsoft KB 307973, which means the size of page file must be

RAM size Paging file should be no smaller than
256 MB–1,373 MB 1.5 times the RAM size
1,374 MB or greater 32-bit system: 2 GB plus 16 MB
64-bit system: size of the RAM plus 128 MB

We must double check the page file size since certain system optimization softwares touch this value without user consent.

The kernel dump is actually very hard for debugging user-mode crashes. If user had more than 2GB of RAM and a 32-bit system, hunting user-mode crashes via kernel dump is most likely hopeless. Moreover, debugging a 32-bit user-mode process from a 64-bit kernel dump can be (if not always is) very frustrating. Unfortunately, most of today’s user-mode processes are still 32-bit.

As noted in Forcing a System Crash from the Keyboard, the keyboard crashing way will not work if kernel is handling some high IRQL request, which means one shall not use it to hunt for hangs caused by drivers that already requested high IRQL. In fact, this shall not happen in the field. Any high IRQL driver shall not hang otherwise the QA quality is questionable.

For debugging driver issues, we should be able to get the memory.dmp after blue screen, and thus the usage of Ctrl-Scrlk generated crash will be quite limited. So, please don’t advise your user to Ctrl-Scrlk for you unless you’re debugging hanging driver issues.

Debugging, Technical, Windows | Comments Jump to the top of this page

Comments are closed.

Chef Peon's Melange

Archives

Meta

Social Links