Unfortunately, once in a while, computers fail. If you’re running Windows you’ve probably witnessed the dreaded Blue Screen of Death, commonly referred to as a BSOD. Once the BSOD occurs, some machines will immediately restart, before you’ve got a chance to actually see what happened. Other times users will just report that the BSOD happened, without noting anything down about what the message actually said. In this post I’ll show you how analyzing BSOD minidump files using Windbg will enable you to find the cause of the BSOD after the fact.
Enabling Dump Files
By default, never Windows installs will automatically create minidump files once a BSOD occurs. Once restarted, you should be able to see a .dmp file here:
If you don’t see any .dmp files there, or if the directory doesn’t exist, you may have to tell Windows to create minidump files when the BSOD occurs. To do so, press the Win+Break keys to open up the System control panel. Now click Advanced system settings in the left menu. Once there, go to the Advanced tab and click the Settings… button under the Startup and Recovery section. Now make sure the Write debugging information setting is set to anything but “none”:
Analyzing BSOD Minidump Files Using Windbg
Once a dump file has been created, you can analyze it using Windbg. Start by opening Windbg and pressing the Ctrl+D keys. Now select the .dmp file you want to analyze and click Open. This should yield something like this:
Already this tells us a couple of things - your OS details, when exactly the problem occurred as well as what module probably caused the issue (FiioE17.sys in this case). Also, it tells you how to proceed:
Use !analyze -v to get detailed debugging information.
As suggested, let’s try and run the !analyze -v command:
This tells us a number of interesting things:
The BSOD error was: BUGCODE_USB_DRIVER
This is the error caused by the driver: IRP_URB_DOUBLE_SUBMIT The caller has submitted an irp that is already pending in the USB bus driver.
The process that invoked the error: audiodg.exe
The stack trace of the active thread on which the error occurred. Note that Windbg can’t find the right symbols as this is a proprietary driver with no public symbols. Even so, to the developer of said driver, the above details will help immensely.
The driver name: FiioE17.sys
With the above options, you’ve got a lot of details that can be sent to the developer, hopefully enabling him/her/them to fix the issue. For now, I’ll have to unplug my Fiio E17 USB DAC :(
Mark S. Rasmussen
I'm the CTO at iPaper where I cuddle with databases, mold code and maintain the overall technical & team responsibility. I'm an avid speaker at user groups & conferences. I love life, motorcycles, photography and all things technical. Say hi on Twitter, write me an email or look me up on LinkedIn.