Export (0) Print
Expand All

Blue Screen Data

When Microsoft Windows encounters a condition that compromises safe system operation, the system halts. This condition is called a bug check. It is also commonly referred to as a system crash, a kernel error, or a Stop error.

If crash dumps are enabled on the system, a crash dump file is created.

If a kernel debugger is attached and active, the system causes a break so the debugger can be used to investigate the crash.

If no debugger is attached, a blue text screen appears with information about the error. This screen is called a blue screen, a bug check screen, or a Stop screen.

The exact appearance of the blue screen depends on the cause of the error. The following is an example of one possible blue screen:


    STOP: 0x00000079 (0x00000002, 0x00000001, 0x00000002, 0x00000000)

Mismatched kernel and hal image.

Beginning dump of physical memory
Physical memory dump complete. Contact your system administrator or
technical support group.


   

On the other hand, some blue screens look like this:


    STOP: c000021a {Fatal System Error}

The Windows Logon Process system process terminated unexpectedly with
a status of 0x00000001 (0x00000000 0x00000000).
The system has been shut down.


   

The hexadecimal number following the word "STOP" is called the bug check code or Stop code. This is the most important item on the screen.

Each bug check code has four associated parameters. In the first blue screen shown here, all four parameters are displayed after the bug check code. However, in the second kind of blue screen, these parameters have been rearranged within the explanatory text. Regardless of the amount of rearrangement, they will always appear sequentially. If fewer than four parameters appear, the remaining parameters can be assumed to be zero.

The remainder of the text on the blue screen gives additional information. For some bug checks, this may be an explanation of what happened or suggestions for how you can deal with the problem. If a kernel-mode dump file has been written, this will usually be indicated as well.

Under some conditions, Windows will display only the first line of the blue screen. This can occur if the vital services needed for the display have been affected by the error.

Bug Check Symbolic Names

Each bug check code also has an associated symbolic name. These names usually do not appear on the blue screen. In these examples, the first screen shows bug check 0x79 (MISMATCHED_HAL), while the second shows bug check 0xC000021A (STATUS_SYSTEM_PROCESS_TERMINATED).

To deliberately cause a bug check from a kernel-mode driver, you need to pass the bug check's symbolic name to the KeBugCheck or KeBugCheckEx function. This should only be done in circumstances where no other option is available. For more details on these functions, see the Windows Driver Kit.

Reading Bug Check Information from the Debugger

If a debugger is attached, a bug check will cause the target computer to break into the debugger. In this case, the blue screen might not appear, or might appear with less text; 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.

The debugger will also display additional information regarding the current problem. To see this information a second time, use the !analyze extension command.

Tips for Software Engineers

When a bug check occurs as a result of code you have 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 are not caused by your own code. In this case, you probably will not be able to fix the actual cause of the problem, so your goal should be to work around the problem, and if possible isolate and remove the hardware or software component that is at fault.

Many problems can be resolved through basic troubleshooting procedures, such as verifying instructions, reinstalling key components, and verifying file dates. Also, diagnostic tools such as Winmsd, Network General Sniffer, and Microsoft Windows Resource Kit Tools Help might isolate and resolve these issues.

For general troubleshooting of Windows bug check codes, follow these suggestions:

  • If you recently added hardware to the system, try removing or replacing it. Or check with the manufacturer to see if any patches are available.

  • You can try running the hardware diagnostics supplied by the system manufacturer.

  • Check with the manufacturer to see if an updated system BIOS or firmware is available.

  • Make sure that any expansion board is properly seated and all cables are completely connected.

  • Confirm that any new hardware that is installed is compatible with the installed version of Windows. For example, you can get information about compatibility with Windows 7 at the Windows 7 Compatibility Center.

  • If new device drivers or system services have been added recently, try removing or updating them.

    Note  Use Safe Mode when removing or disabling components. Using Safe Mode loads only the minimum required drivers and system services during the Windows startup. To enter Safe Mode, restart your computer, and press F8 at the character-mode menu that displays the operating system choices. At the resulting Windows Advanced Options menu, choose Safe Mode.

  • Run a virus detection program. Viruses can infect all types of hard disks formatted for Windows, and resulting disk corruption can generate system bug check codes. Make sure the virus detection program checks the Master Boot Record for infections.

  • Verify that the system has the latest Service Pack installed. To detect which Service Pack, if any, is installed on your system, click Start, click Run, type winver, and then press ENTER. The About Windows dialog box displays the Windows version number and the version number of the Service Pack, if one has been installed.

  • Disable BIOS memory options such as caching or shadowing.

  • Check the System Log and Application Log in Event Viewer to see if any additional error messages have been logged recently. These might pinpoint the cause of the error.

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 or a program replacement, you must record the exact actions that lead to the failure.

 

 

Send comments about this topic to Microsoft

Show:
© 2014 Microsoft