I use a Lenovo Thinkpad X201s for work. It’s mostly a solid workhorse – I like the form factor, the screen is bright and the machine is relatively powerful. I recently reinstalled Windows 7 Enterprise on it and, to my consternation, it started crashing with maddening frequency. The only thing I knew for sure was that the fatal crash happened when I put the laptop to sleep. This was particularly annoying because I had to reboot my computer after a crash, losing all my in-progress work.
I tried the obvious venues. Reliability Monitor gives a stop code, 0x0000009f:
Search indicated that this was a driver issue. Great! Which driver? My only guess was that a driver pushed by Windows Update had screwed me over. ARGH! This is when I came upon an idea: why not inspect the minidump Windows spews out every time a fatal crash happens? Here’s what I did:
1. Install the Windows SDK
WinDbg.exe is not released as a separate tool. You need to install the Windows SDK, which will install WinDbg.exe along with a bunch of other cool tools. Install it from here.
2. Load the dump and symbols
a) Start WinDbg
b) Click File > Open Crash Dump and point to a minidump. Minidumps are located in %windir%\Minidump
[box icon="lifesaver"] If WinDbg can’t load the dump, try copying it to a non-Windows directory such as temp [/box]
c) Now you will see a scary message like this:
Symbol search path is: * Invalid *
Symbol loading may be unreliable without a symbol search path.
Use .symfix to have the debugger choose a symbol path.
After setting your symbol path, use .reload to refresh symbol locations.
This just means that Windows symbols have not been loaded, so you can’t really analyze the minidump. A couple of commands will fix this:
0: kd> .symfix
0: kd> .sympath
Symbol search path is: srv*
Expanded Symbol search path is: cache*;SRV*http://msdl.microsoft.com/download/symbols
0: kd> .reload /f
WinDbg will now load symbols from the Microsoft symbol server. Now you just run one command and you’ll see a very interesting result – by looking at the result of !analyze, you can see that this was indeed a problem with drivers, and specifically with the USB hub driver. I found a fix, now let’s see if it actually worked
0: kd> !analyze -v
A driver is causing an inconsistent power state.
Arg1: 0000000000000004, The power transition timed out waiting to synchronize with the Pnp
Arg2: 0000000000000258, Timeout in seconds.
Arg3: fffffa8003b85b60, The thread currently holding on to the Pnp lock.
FAULTINGMODULE: fffff880068ba000 usbhub