How do I gather information on a Windows 7 freeze up that may involve both a driver and user mode code?

Question

I am experiencing a crash in an application, that is crashing windows 7, but not in the traditional "blue screen of death" crash, that happens when device drivers or other kernel-space processes crash the whole system, but rather, I am seeing a lock-up of all user-space processes.

Here is the state of the machine:

(1) Windows mouse movement is still responding, and Aero composition layer is still working (certain mouse over effects in explorer still work), but no win32 process is working, and the GDI and user session seem frozen. (2) Ctrl+Alt+Delete does not bring up the task manager. (3) There are no crash dumps, and there is no blue screen of death.

Does anybody know any way to gather any more information about the crash? I know that there are driver level issues involved, and I would like to gather information that the device driver level people could use. When you get a Blue Screen Of Death, you can gather the memory dump (DMP) files, and send them to the developers to help. What I am looking for is a way to trace the processes, and the state of the system, perhaps connect a kernel debugger or something. I have never done kernel debugger work, so I'm looking for a way to get started with that.

I can easily reproduce the crash in a win7/32 bit VM, and I do not yet have the kernel debug tools installed. I'm wondering first, if it seems that I have chosen a worthwhile approach (kernel debug tools?) and if so, I don't really know how to use those tools to gather information that might help the kernel mode devs locate the trouble.

Answer 1

Download WinDbg and connect to the machine in question by Firewire or serial cable (USB also works under some circumstances IIRC). This would allow you to search for deadlocks in the running system from a remote machine.

Another possibility is to provoke a system crash (post-mortem analysis). You should make sure before to set the crash dump settings to full dump. This will create a crash dump of the same size as your amount of RAM. Of course that may pose a problem when getting the dump to the people (e.g. via the net). Also be aware that private data can be contained in the dump, depending on the circumstances.

How to provoke the crash dump is what I described here, relevant part quoted below. If you are connected via the kernel debugger you can also provoke the creation of a memory dump.

---

The keyboard driver(s) can be told to cause a BSOD:

HKLM\CurrentControlSet\Services\kbdhid\Parameters

or (for older PS/2 keyboards)

HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters

And there set a REG_DWORD named CrashOnCtrlScroll to 1.

After the next reboot you can force the blue screen by Ctrl+ScrollLk+ScrollLk. The bug check code will in this case be 0xE2 (MANUALLY_INITIATED_CRASH).