Windows® Internals, Sixth Edition, Part 2

Analysis reveals that the address in the ecx register was written to by an instruction that read the value pointed to by the esi register. Using the dc command with the address stored in the esi register of the trap frame shows from where the value 4f4f4f4f originated. What is of interest in the output of the command is that each of the addresses listed appears as a pair and that the first value—the one that contains the invalid address—doesn’t match the value adjacent to it:0: kd> dc 82939da8 82939da8 4f4f4f4f 85045810 82939db0 82939db0 OOOO.X.......... 82939db8 82939db8 82939db8 86f749f8 86f749f8 .........I...I.. 82939dc8 82939dc8 82939dc8 82939dd0 82939dd0 ................ 82939dd8 82939dd8 82939dd8 82939de0 82939de0 ................ 82939de8 82939de8 82939de8 82939df0 82939df0 ................ ...

Following the suspicion that these values are address pairs and that the first value is invalid, displaying the address next to the corrupted value leads toward determining the cause of the corruption. The value 4f4f4f4f is OOOO in ASCII, which is apparent in the output shown here:0: kd> dc 85045810 85045810 4f4f4f4f 4f4f4f4f 4f4f4f4f 4f4f4f4f OOOOOOOOOOOOOOOO 85045820 4f4f4f4f 4f4f4f4f 4f4f4f4f 4f4f4f4f OOOOOOOOOOOOOOOO 85045830 46524556 00574f4c 00000000 00000000 VERFLOW......... 85045840 00000000 00000000 00000000 00000000 ................ 85045850 00000000 00000000 00000000 00000000 ................ ...

Checking the pool allocation with the !pool command confirms that the allocation, along with its pool headers, have been corrupted:0: kd> !pool 85045810 Pool page 85045810 region is Nonpaged pool 85045000 size: 808 previous size: 0 (Allocated) None 85045808 is not a valid large pool allocation, checking large session pool... 85045808 is freed (or corrupt) pool Bad previous allocation size @85045808, last size was 101

It’s important to note that although corruption has been identified, it may or may not have directly caused the crash currently being analyzed. Any pool corruption that has been discovered requires further investigation. Pool corruption left undiagnosed risks further crashes to the system or corruption of data stored on disk.

Of further interest in the output of the corrupted pool allocation is a reference to the string OVERFLOW . Using the !for_each_module command, it’s possible to search each loaded module for any occurrences of the suspect string. The following debugger command displays the name of any loaded drivers that contain a match for the search phrase:0: kd> !for_each_module .foreach (address {s -[1]a @#Base @#End "OVERFLOW"}) {lm 1m a a ddress} BTHUSB CLASSPNP CLASSPNP rfcomm rfcomm rfcomm ... myfault

Further analysis of a crash dump that appears at first to be virtually impossible to diagnose has narrowed down the list of suspect drivers. The next step would be to enable the special pool option of Driver Verifier with the device drivers listed.

Hardware Malfunctions

Another type of stop message is the hardware malfunction screen. This type of screen is displayed when the processor detects a hardware condition. Figure 14-10 shows a sample hardware malfunction screen. Depending on the type of condition that generated the hardware malfunction, the system might display additional information indicating the cause of the error. When displaying the hardware malfunction screen, the system ignores the AutoReboot value of the HKLM\SYSTEM\CurrentControlSet\Control\CrashControl registry key and will display the screen indefinitely.

Figure 14-10. Example of a hardware malfunction screen

As you should with any stop messages that are suspected to be caused by hardware failures, run any manufacturer-supplied hardware-diagnostic tools to determine which components, if any, may have failed. If you recently added new hardware to the computer, try removing it to see whether the problem no longer occurs. Remove any existing hardware that may have failed, and have it replaced.

Signaling the nonmaskable interrupt (NMI) pin of the system’s motherboard when the HKLM\SYSTEM\CurrentControlSet\Control\CrashControl\NMICrashDump registry value isn’t set will also generate a hardware malfunction screen. If the intention was to generate a manual crash dump using an NMI button for offline analysis, verify that the NMICrashDump value is configured correctly.

EXPERIMENT: The Blue Screen Screen Saver