When a core dump occurs, a blue screen with white text similar to the text shown in Listing 14.1 will appear. The core dump message shown in Listing 14.1 occurred on a portable computer. I forced this error to occur by physically removing the hard disk drive while trying to delete several megabytes of files. This is not something that would normally occur in a working system unless you accidentally pull a disk drive cable out while working on your system (which, of course, is never a good idea, but accidents happen).

Listing 14.1 The contents of a forced core dump.

*** STOP: 0x00000077 (0x00000103, 0xC000016B, 0x00000000, 0x01666000)
KERNEL_STACK_INPAGE_ERROR

CPUID:GenuineIntel 5.2.c irql:1f   SYSVER 0xf0000565

Dll Base    DateStmp - Name            Dll Base    DateStmp - Name
8010000     3202c07e - ntoskrnl.exe    8010000     31ee6c52 - hal.dll
8001000     31f8ff94 - Pcmcia.sys      802c0000    31ec6c8f - Atdisk.sys
8000b000    31ed237c - Disk.sys        802c7000    31ec6c7a - CLASS2.SYS
802cb000    31eedd07 - Fastfat.sys     fdb20000    31ec6c8d - Floppy.sys
fdd10000    31ec6df7 - Fs_rec.SYS      fde0f000    00000000 - Null.SYS
fdc78000    31ed868b - KsecDD.SYS      fde14000    00000000 - Beep.SYS
fdb50000    31ec6c90 - i8042prt.sys    fdc88000    31ec6c8d - mouclass.sys
fdc90000    31ec6c94 - kbdclass,sys    fdb60000    31f50722 - VIDEOPRT.SYS
fdca4000    31ec6c6d - vga.sys         fdb70000    31ec6ccb - Msfs.SYS
fd810000    31ec6cc7 - Npfs.sys        ff61d000    31eed262 - NDIS.SYS
a0000000    31f954f7 - win32k.sys      ff61d000    31ee8583 - vga.dll
ff57b0000   31ec6e6c - TDI.SYS         ff54e000    31f130a7 - tcpip.sys
ff5320000   31f50a65 - netbt.sys       fd850000    31f8f864 - afd.sys
fdaa8000    31ec6e7a - netbios.sys     ff59b000    00000000 - Paraport.SYS
fdc94000    00000000 - Parallel.SYS    fdd3a000    00000000 - ParVdm.SYS
fd8f0000    31ec6cb1 - Serial.SYS      ff4cb000    31f5003b - rdr.sys
ff4ba0000   31f7a1ba - mup.sys         ff459000    32031abe - srv.sys

Address dword dump Build [1381]                                      - Name
fdc3fef4  801232b5  801232b5  c0301408  fdc3ff1c  00000000  00000979 - ntoskrnl.exe
fdc3ff2c  8013a229  8013a229  ff6a4e00  00000000  00000000  00000000 - ntoskrnl.exe
fdc3ff40  8013a189  8013a189  00000000  00000000  00000000  8013471a - ntoskrnl.exe
fdc3ff50  8013471a  8013471a  00000000  00000000  00000000  00000000 - ntoskrnl.exe
fdc3ff70  801382b4  801382b4  80142840  00000000  00000000  8013f9ca - ntoskrnl.exe
fdc3ff74  80142840  80142840  00000000  00000000  8013f9ca  8013a106 - ntoskrnl.exe
fdc3ff80  8013f9ca  8013f9ca  8013a106  00000000  00000000  0000027f - ntoskrnl.exe
fdc3ff84  8013a106  8013a106  00000000  00000000  0000027f           - ntoskrnl.exe

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

A core dump, such as that shown in Listing 14.1, is basically composed of three parts. These three part include the following:

•  The first part of the core dump is the stop error code. This is the most important part of the core dump. If you enabled the recovery option to write a system event when a stop error occurs, it will include this first part of the core dump. Even if you enable the recovery option to write a system event, however, you should always write down the stop error code, its parameters, and, if available, the base address and driver that caused the problem.

---

Note:  Just in case you are curious, the error indicated in Listing 14.1 by the STOP: 0x00000077 (0x00000103, 0xC000016B, 0x00000000, 0x01666000) KERNEL_STACK_INPAGE_ERROR is a kernel stack in page error that indicates that the kernel attempted to read a page from the paging file but did not succeed. This is not surprising, because there was no hard disk in the computer at the time. The first parameter is a status code. The second is an I/O status code. To interpret either code requires a copy of the Windows NT DDK. The third parameter specifies the paging file that the kernel tried to access. In this case, it tried to access the first paging file (the first paging file is zero, the second is one, and so on). The fourth parameter is an offset into the paging file that indicates the page that was trying to be read.

---

•  The second part of the core dump is a one-line list that includes the CPU model, the IRQL (internal request level), the operating system version in hexadecimal, and a two-column display of all the drivers loaded on the computer when the stop error occurred. This two-column list is important as it includes the base address where the driver was loaded and a date time-stamp for the driver file. The base address can be used to help isolate the cause of the error because some stop errors list an address that caused the error to occur. If this address falls within the base address of a driver, that driver might be the cause of the error. The date time-stamp is important because it can point out a version conflict that might have caused the error to occur.

•  The third part of the core dump is a stack dump of some of the calls on the system stack that led to the problem. For the most part, a stack dump is only useful to a very experienced technician. This doesn’t mean, however, that you can’t get anything useful from this information. I often use the stack dump’s list of drivers to help isolate a problem.