One Man’s Quest to Fix A Driver Crash or How I Learned to Stop Worrying and

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:

image

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 Smile

0: kd> !analyze -v

…truncated..

DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 0000000000000004, The power transition timed out waiting to synchronize with the Pnp
subsystem.
Arg2: 0000000000000258, Timeout in seconds.
Arg3: fffffa8003b85b60, The thread currently holding on to the Pnp lock.
Arg4: fffff80000b9e510

Debugging Details:

DRVPOWERSTATESUBCODE: 4
DRIVER
OBJECT: fffffa8006b15550
IMAGENAME: usbhub.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7a68e
MODULE
NAME: usbhub
FAULTINGMODULE: fffff880068ba000 usbhub
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA
DRIVERFAULT
BUGCHECK
STR: 0x9F
PROCESSNAME: System
CURRENT
IRQL: 2

STACKCOMMAND: kb
FOLLOWUP
NAME: MachineOwner
FAILURE_BUCKET_ID: X640x9F4IMAGEusbhub.sys
BUCKETID: X640x9F4IMAGE_usbhub.sys
Followup: MachineOwner