If you develop enough drivers, eventually you’ll ship one with a bug. Yeah, I know, seems unlikely, doesn’t it? What, with all of the time everyone spends testing and profiling and code reviewing, bugs are almost non-existent, right? Well, on the off chance that the impossible happens, here’s a tip that I have used in the past.
Most computers will generate a dump of some sort when a crash happens, but what if the driver hangs in the field? You have only a couple of options in that case. One possibility would be to hook up a kernel debugger. That can be problematic, though – users have to find a null modem cable, modify the target to boot with debugging support (or step through an F8 menu that they may not be comfortable with), set up the debugger and turn on remote desktop for the host, and generally put the user through a nontrivial amount of trouble. When this works, it’s great; there are even variations on this theme that make it more convenient. But for many, the requirement for a second computer and a null modem connection kills the deal.
Another way to get a crash dump is to force windows to crash from the keyboard. [No dumb jokes, please. :-)] To get an idea of how this works, grab a DDK and check out the 8042 sample in the input directory. To enable keyboard-triggered crashes, do the following:
- create a DWORD value called “CrashOnCtrlScroll” in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
- set it to 1
Now, if you need a crash dump, hit ctrl+scroll lock twice. This will generate a bugcheck, and will drop a minidump or full dump or whatever you have your system configured for. The bugcheck code will be E2 – MANUALLY_INITIATED_CRASH.
Hope this helps.