Analyze Bug Check Blue Screen Data
Note
This article is for programmers. If you're a customer who has received a blue screen error code while using your computer, see Troubleshoot blue screen errors.
Note
If you're an IT professional or support agent, see Advanced troubleshooting for stop or blue screen errors for more information.
Gather the stop code parameters
Each bug check code has four associated parameters that provide information. The parameters are described in Bug check code reference for each stop code.
There are multiple ways to gather the four stop code parameters.
Examine the Windows system log in the Event Viewer. The event properties for the bug check will list the four stop code parameters. For more information, see Open Event Viewer.
Load the generated dump file and use the !analyze command with the debugger attached. For more information, see Analyzing a kernel-mode dump file with WinDbg.
Attach a kernel debugger to the faulting PC. When the stop code occurs, the debugger output will include the four parameters after the stop code hex value.
******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 9F, {3, ffffe000f38c06a0, fffff803c596cad0, ffffe000f46a1010} Implicit thread is now ffffe000`f4ca3040 Probably caused by : hidusb.sys
Bug check symbolic names
DRIVER_POWER_STATE_FAILURE is the bug check symbolic name, with an associated bug check code of 9F. The stop code hex value associated with the bug check symbolic name is listed in the Bug check code reference.
Read bug check information from the debugger
If a debugger is attached, and debugging is enabled on the PC, a bug check will cause the target computer to break into the debugger. In this case, the blue screen might not appear immediately. The full details on this crash will be sent to the debugger and appear in the debugger window. To see this information a second time, use the .bugcheck (Display bug check data) command or the !analyze extension command. For information on enabling debugging see, Getting started with WinDbg (Kernel-Mode).
Kernel debugging and crash dump analysis
Kernel debugging is especially useful when other troubleshooting techniques fail, or for a recurring problem. Remember to capture the exact text in the bug check information section of the error message. To isolate a complex problem and develop a viable workaround, it's useful to record the exact actions that lead to the failure.
The !analyze debug extension displays information about the bug check and can be helpful in determining the root cause.
You can also set a breakpoint in the code leading up to this stop code and attempt to single step forward into the faulting code.
For more information, see the following articles:
Crash dump analysis using the Windows debuggers (WinDbg)
Analyzing a kernel-mode dump file with WinDbg
Using the !analyze extension and !analyze
Use Driver Verifier to gather information
It's estimated that about three quarters of blue screens are caused by faulting drivers. Driver Verifier is a tool that runs in real time to examine the behavior of drivers. For example, Driver Verifier checks the use of memory resources, such as memory pools. If it finds errors in the execution of driver code, it proactively creates an exception to allow that part of the driver code to be further scrutinized. The driver verifier manager is built into Windows and is available on all Windows PCs. To start the driver verifier manager, enter Verifier at a command prompt. You can configure which drivers you would like to verify. The code that verifies drivers adds overhead as it runs, so try to verify the smallest number of drivers as possible. For more information, see Driver Verifier.
Tips for software engineers
When a bug check occurs as a result of code you've written, you should use the kernel debugger to analyze the problem, and then fix the bugs in your code. For full details, see the individual bug check code in the Bug check code reference section.
However, you might also encounter bug checks that aren't caused by your own code. In this case, you probably won't be able to fix the actual cause of the problem, so your goal should be to work around the problem. If possible, isolate and remove the hardware or software component that's at fault.
Many problems can be resolved through basic troubleshooting procedures, such as verifying instructions, reinstalling key components, and verifying file dates. Also, the Event Viewer, the Sysinternals diagnostic tools, and network monitoring tools might isolate and resolve these issues.