蓝屏内幕4

Interpreting Stop Codes

In most cases the most useful information provided by a Blue Screen is the stop code and the 4 parameters printed with it. As I stated earlier, these parameters must be interpreted on a per-stop code basis. In this section I’ll provide a mini-stop code reference, covering the ones most commonly encountered, their causes, and how to interpret the parameters listed with them. Note that most of the time only a subset of KeBugCheckEx(...) parameters is used to convey information about a crash.

IRQL_NOT_LESS_OR_EQUAL (0xA)

This is one of my favorites, as I seem to encounter it more often than other types. It is thrown when the kernel or a driver determines that the current IRQL is higher than it’s supposed to be. The epicenter for most of these Bug Checks is in MmAccessFault(...), the Memory Manager’s fault handler. This function is responsible for handling page faults, and it will typically do so silently. But when the IRQL is DISPATCH_LEVEL or higher when it is invoked, it returns a STATUS_IN_PAGE_ERROR to the system page fault dispatcher. The system page fault dispatcher then promptly calls KeBugCheckEx(...) with an IRQL_NOT_LESS_OR_EQUAL.

Another place these Bug Checks can be generated is from the kernel’s worker thread dispatch function, ExpWorkerThread(...). ExpWorkerThread(...) pulls work items off a queue and calls the work routines associated with them. Upon returning from a work routine, it checks the IRQL to make sure it’s PASSIVE_LEVEL (the level it was before the work item was called). If it’s not, it throws an IRQL_NOT_LESS_OR_EQUAL. The parameters for this bug check are shown in Table 1.

IRQL_NOT_LESS_OR_EQUAL (0xA) (from worker thread)
 
Param1 Address of work routine that was called
Param2 IRQL that was invalid
Param3 A copy of Param1  
Param4 Pointer to work item data structure  
IRQL_NOT_LESS_OR_EQUAL (0xA) (from MmAccessFault)
 
Param1 Address that was referenced
Param2 IRQL that was invalid
Param3 Type of access (0 == read, 1 == write)
Param4 Address where reference occurred

Table 1.

KMODE_EXCEPTION_NOT_HANDLED (0x1E)

This code is generated from several places in the kernel, including the system’s exception handler. It occurs when an exception has occurred that the system was not expecting, and not able to handle via any exception handling mechanisms. One example of this occurs when MmAccessFault(...) gets a fault due to an invalid reference to a protected page. For instance, a driver that writes to a read-only page will generate it. Its parameters are shown in Table 2.

KMODE_EXCEPTION_NOT_HANDLED (0x1E)
 
Param1 The exception code (see NTSTATUS.H for more):
0x800000003 Breakpoint hit with no debugger active

0xC00000005 Access violation