Reading Crash Screens

< BACK  NEXT >

[oR]

System crashes, which Microsoft euphemistically terms "STOP messages," are a dramatic sign that a driver has failed. This section describes how STOP messages are generated and explains how they provide useful information.

What Happens When the System Crashes

Despite its name, a system crash is quite orderly. The OS is reporting that it has detected an internal state that is inconsistent with continued operation. As a result, the OS believes it is better to shutdown now rather than continue operation with the illegal state. This is appropriate in many cases since the illegal state could cause real damage, perhaps to the file system. Continuing operation under such circumstances could also breach security.

Two different sequences of events can lead to a system crash. First, some kernel-mode component can be the detector of an illegal state and elect to force a system STOP. For example, if the I/O Manager discovers that a driver is passing an already completed IRP to IoCompleteRequest, the I/O Manager forces a system STOP.

The second scenario is more indirect. A kernel-mode component is the direct source of the failure, generating an exception within its code operation. For example, a memory access violation or integer division by zero result in an exception being generated. Referencing paged memory at an elevated IRQL level is also an exception. If the kernel-mode routine that performs the illegal operation does not trap the exception directly, the result is an unhandled exception within kernel mode.

When this occurs, a standard exception handler within the kernel responds and initiates a system STOP.

Regardless of which kernel subsystem initiates the system STOP, one of two calls actually performs the operation.

 VOID KeBugCheck( Code ); VOID KeBugCheckEx( Code, Arg1, Arg2, Arg3, Arg4 ); 

Either function generates the STOP screen and optionally saves a crash dump file to disk. Depending on the system administrator's choice, the system either halts, reboots, or starts the kernel's debug client.

The Code argument to the KeBugCheck routines specifies the cause of the crash as a simple DWORD value. It is also known as a bugcheck code. The additional four arguments to KeBugCheckEx appear within the STOP message screen as further information for the user to report (and hopefully assist in isolating the source of the STOP).

Bugcheck codes are either defined by Microsoft (see BUGCODES.h within the DDK and Appendix B of this book) or are driver-specific.

Calls to either KeBugCheck function can be made from a driver. In fact, it is common for a debug version of a driver to force system STOPs at various points of interest.

The Blue Screen of Death

A system STOP message appears on an entire screen of blue background, earning it the name Blue Screen of Death, or BSOD. In versions of NT prior to Windows 2000, the STOP message filled the screen with information of questionable value. In Windows 2000, the STOP message is simplified, containing the most relevant information about the cause and location of the crash. A sample BSOD is illustrated in Figure 17.1.

Figure 17.1. The STOP message screen (Blue Screen of Death).

The STOP message contains three lines of information. The bugcheck code, along with the four arguments passed to KeBugCheckEx if it initiated the STOP, is supplied on the first line. Depending on the bugcheck code, the four extra arguments contain meaningful information (see Appendix B for a description).

The second line identifies the bugcheck code symbolically. In this case, the bugcheck code of 0xD1 specifies DRIVER_IRQL_NOT_LESS_OR_EQUAL. Appendix B states that code 0xD1 indicates that a driver caused a page fault at or above DISPATCH_LEVEL IRQL. Also, the four KeBugCheckEx arguments for this code specify

 Arg1: The paged address referenced: 0 Arg2: IRQL level at the time of the reference: 2 Arg3: Type of access: 0 means "read" Arg4: Address of instruction that caused the fault: 0xFCE10796. 

Thoughtfully, the third line of the STOP message information looks up the failing instruction address and specifies the module that contains the instruction. In this example, Driver.sys was responsible for the page fault.

< BACK  NEXT >