Why Does Windows Crash?

Windows crashes (stops execution and displays the blue screen) for the following reasons:

• A device driver or an operating system function running in kernel mode incurs an unhandled exception, such as a memory access violation (which is caused either by attempting to write to a read-only page or attempting to read an address that isn't currently mapped and therefore is not a valid memory location).

• A call to a kernel support routine results in a reschedule, such as waiting for an unsignaled dispatcher object when the interrupt request level (IRQL) is DPC/dispatch level or higher. (See Chapter 3 for details on IRQLs.)

• A page fault on memory backed by data in a paging file or a memory mapped file occurs at an IRQL of DPC/dispatch level or above (which would require the memory manager to have to wait for an I/O operation to occur and, as just stated, waits can't occur at DPC/dispatch level or higher because that would require a reschedule).

• A device driver or operating system function explicitly crashes the system (by calling the system function KeBugCheckEx) because it detects an internal condition that indicates either a corruption or some other situation that indicates the system can't continue execution without risking data corruption.

• A hardware error, such as a machine check or a nonmaskable interrupt (NMI), occurs.

Microsoft's analysis of the crash dumps that Windows XP users have submitted to the Microsoft Online Crash Analysis (OCA, which is described later in this chapter) Web site reveals the breakdown of crash causes as shown in Figure 14-1. (The data shown was generated in April 2004.)

Figure 14-1. Causes of OCA-submitted crashes

When a kernel-mode device driver or subsystem causes an illegal exception, Windows faces a difficult dilemma. It has detected that a part of the operating system with the ability to access any hardware device and any valid memory has done something it wasn't supposed to do.

But why does that mean Windows has to crash? Couldn't it just ignore the exception and let the device driver or subsystem continue as if nothing had happened? The possibility exists that the error was isolated and that the component will somehow recover. But what's more likely is that the detected exception resulted from deeper problems for example, from a general corruption of memory or from a hardware device that's not functioning properly. Permitting the system to continue operating would probably result in more exceptions, and data stored on disk or other peripherals could become corrupt a risk that's too high to take.