BSOD Debugging Part 2: Debugging

Check out BSOD Debugging: Part 1 if you missed it.  OK, so you have your Windows debugging environment set up and you have a dump file to analyse. Lets get on with it!

Here I will show you how I use the debugger to get to the bottom of a BSOD issue I was having.  Your BSOD issue(s) will be completely different, however the basics of using the Windows debugger and investigating the Windows debugger output will be the same.

Using Windows Debugging tools to find a BSOD root cause

Start up WinDbg, and choose File - Open Crash Dump...


Open your MEMORY.DMP file.
Wait whilst the the debugger to does it's thing:

If you have set up your debugging environment as described in part 1, you will be using the Microsoft symbols server.  This is confirmed by the debugger when a debug is under way, as highlighted in the screenshot above.

Symbol search path is: SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols

OK so what can we see then?

Firstly the details of the BSOD, or BugCheck as the debugger calls it:


OK, a STOP 9F... What is that?

Looking at this handy list of BSOD codes (pcsupport.about.com) a STOP 9F is described as follows:

STOP Error 0x0000009F: DRIVER_POWER_STATE_FAILURE
STOP error 0x9F means that the driver is in an inconsistent or invalid power state. STOP code 0x0000009F may also display "DRIVER_POWER_STATE_FAILURE" on the same STOP message.

So some sort of driver issue when the system is changing power state.

Next the debugger is suggesting that the BSOD was probably caused by ntkrpamp:


OK, whats a ntkrpamp?  Searching for ntkrpamp at processlibrary.com shows the following:

So ntkrpamp is the NT Kernel.  That's not a driver!  However it is the kernel's job to run drivers.  We are going to need to do some further digging with the debugger.

Luckily, the debugger makes it easy for us.  Simply click the blue text !analyze -v in the debugger results window to perform some further analysis.
Here is the output:

Right, now we are getting there. 

 and
WIN7_DRIVER_FAULT that ties in with the BSOD being caused by a driver power state failure.  However, what is this FAULTING_MODULE dne2000 ?

Lets click on the  dne2000 link in the debugger window to find out:

Oh look. dne2000.sys, a driver located in C:\Windows\system32\DRIVERS folder.

Wa-hey! Root cause found: The driver dne2000.sys is having issues, causing the BSOD.

Fixing the Root Cause

So we know that there is an issue with the driver dne2000.sys that is causing the Windows BSOD. Lets get Google (other search engines are available) to take the strain from here on in.

Something like dne2000.sys bsod should do us nicely.

The very first google search result points us to this discussion thread on MS Technet Forums  Which in turn links us to this page discussing an available DNE update

Following the advice and completing the installation of the DNEUpdate and after a bit of extensive testing, my STOP 9F BSOD's are a thing of the past.  Job done!

Conclusion

As I said at the top of the post, your BSOD may - probably will - be completely different to mine.  However the basics of using the Windows debugger and investigating the Windows debugger output will be the same.  The take away from this post is as follows:

1. How to use the Windows debugger to open a BSOD crash dump
2. How to find out more about the BSOD here
3. How to find out about Windows processes here
4. How to use the Windows debugger !analyze -v function to find out more about the BSOD crash dump
5. How to use other links offered by the Windows debugger to find out more, such as file names etc
6. Finally, once you have an idea of BSOD the root cause, use a search engine to investigate further.  Chances are you are not the first person to suffer with the issue!

Happy debugging.

- Chris