Analyzing a Crash Dump, aka BSOD
Today I have to face a weird behavior in my laptop since a few of days ago. It only happens that when the computer goes to sleep, that is, stand-by, either by my request or due to lack of battery, the screen goes blank but seemed to never finish the sleep process.
I say “seemed” because the last times this happened, I did not have the patience to wait and long-pressed the power button to force a shutdown. However, last night, I went to bed and left it in the sleeping attempt, and this morning I found a “nice” crash dump, also known as Blue Screen Of Death, complaining about DRIVER_POWER_STATE_FAILURE issue:
Sometime ago I had other BSOD that pointed me to a networking drivers issue (ndis.sys), and updating those available seemed to work and did not get BSOD anymore:
This time, while “DRIVER_POWER_STATE_FAILURE” points initially to a device driver that is preventing the kernel to suspend the computer, but the BSOD does not show which driver could it be, so it could be tedious to go and try to update and test every single driver. So lets get into memory dump analysis to see if we can find the faulty driver.
To do so, the first thing we need is a kernel memory dump. To get so, we need to have the system configured to do so in “Startup and Recovery” dialog. By default, Windows 7 does not show BSOD, but restarts the computer after system crash, so if you want to see the BSOD message, you need to uncheck the “Automatically restart” checkbox.
To analyze the memory dump generated after a BSOD, we can use WinDbg, included with Windows Debugging Tools. There is great intro and download links at at http://msdn.microsoft.com/en-us/windows/hardware/gg462988.aspx.
Once we launch WinDbg, the first thing to do is configure the symbols path. We do so from “File/Symbol File Path”, and specify “SRV*c:\SymbolsCache*=http://msdl.microsoft.com/download/symbols” as path (without quotes). This will download symbols from Microsoft to c:\SymbolsCache as needed by WinDbg.
Then we open the crash dump from “File/Open Crash Dump”
In my case, I opened “DRIVER_POWER_STATE_FAILURE.dmp”, as I renamed the dump file to prevent other dumps to overwrite it.
At the end of the initial output, there is a candidate driver for the BSOD, netw5s64.sys. Executing “!analyze –v” confirms this fact:
We can see that the error is caused by a device driver blocking an IRP (IoCompleteRequest) for too long, and we can see that the IRP address is fffffa80101fac10.
If we run !IRP fffffa80101fac10, we can see the drivers involved:
We can again see netw5s64, and this time also Virtual WiFi bus (vwifibus), available in Windows 7 for WiFi hosted networks feature. So here is my supossedly faulty driver:
The point is that it has being working without issues for a long time, so it may not necessary be a bug in the driver itself, but a hardware failure or a driver configuration. The first thing we can try though is look for driver updates. We can do this directly from Device Manager. Unfortunately, I had no luck this time:
Another thing we can try is go to the computer’s integrator website, or even directly to the driver’s manufacturer website, Intel Corporation in this case, to see if there is a new driver. This operation can be more or less lengthy, depending on the manufacturer/integrator's sites organization and complexity. In my case, my laptop vendor was not providing a good driver revision (even older than the one I had installed), but Intel did: there was an updated driver not available in Windows Update:
While I download the updated driver, I take a look at “Power Management” tab of the device which driver was causing the BSOD in Device Manager, and found the most possible reason for the failure: The interface is configured to not allow the computer to turn of this device to save power.
Before updating the driver, I checked this checkbox and try to suspend the computer. Guess what, this time the computer suspended just fine.
So there is no reason to update the driver…. but …. well…. we all like to be up-to-date … so I’ll install it anyways