The STOP Message Screen

Character-mode STOP messages are always displayed on a full character-mode screen rather than in a Windows-mode message box. They are also uniquely identified by a hexadecimal number and a symbolic string, as in the following example:

*** STOP: 0x00000001 APC_INDEX_MISMATCH

The content of the symbolic string may suggest, to a trained technician, the part of the Kernel that detected the condition from which there was no recourse but to stop. However, keep in mind that the cause may actually be in another part of the system.

The following is an example of a complete STOP message screen generated by the Windows NT Kernel.

*** STOP: 0x0000001E (0x80000003,0x80106fc0,0x8025ea21,0xfd6829e8) Unhandled Kernel exception c0000047 from fa8418b4 (8025ea21,fd6829e8) Dll Base Date Stamp - Name Dll Base Date Stamp - Name 80100000 2be154c9 - ntoskrnl.exe 80400000 2bc153b0 - hal.dll 80258000 2bd49628 - ncrc710.sys 8025c000 2bd49688 - SCSIPORT.SYS 80267000 2bd49683 - scsidisk.sys 802a6000 2bd496b9 - Fastfat.sys fa800000 2bd49666 - Floppy.SYS fa810000 2bd496db - Hpfs_Rec.SYS fa820000 2bd49676 - Null.SYS fa830000 2bd4965a - Beep.SYS fa840000 2bdaab00 - i8042prt.SYS fa850000 2bd5a020 - SERMOUSE.SYS fa860000 2bd4966f - kbdclass.SYS fa870000 2bd49671 - MOUCLASS.SYS fa880000 2bd9c0be - Videoprt.SYS fa890000 2bd49638 - NCR77C22.SYS fa8a0000 2bd4a4ce - Vga.SYS fa8b0000 2bd496d0 - Msfs.SYS fa8c0000 2bd496c3 - Npfs.SYS fa8e0000 2bd496c9 - Ntfs.SYS fa940000 2bd496df - NDIS.SYS fa930000 2bd49707 - wdlan.sys fa970000 2bd49712 - TDI.SYS fa950000 2bd5a7fb - nbf.sys fa980000 2bd72406 - streams.sys fa9b0000 2bd4975f - ubnb.sys fa9c0000 2bd5bfd7 - mcsxns.sys fa9d0000 2bd4971d - netbios.sys fa9e0000 2bd49678 - Parallel.sys fa9f0000 2bd4969f - serial.SYS faa00000 2bd49739 - mup.sys faa40000 2bd4971f - SMBTRSUP.SYS faa10000 2bd6f2a2 - srv.sys faa50000 2bd4971a - afd.sys faa60000 2bd6fd80 - rdr.sys faaa0000 2bd49735 - bowser.sys Address dword dump Dll Base - Name 801afc20 80106fc0 80106fc0 00000000 00000000 80149905 : fa840000 - i8042prt.SYS 801afc24 80149905 80149905 ff8e6b8c 80129c2c ff8e6b94 : 8025c000 - SCSIPORT.SYS 801afc2c 80129c2c 80129c2c ff8e6b94 00000000 ff8e6b94 : 80100000 - ntoskrnl.exe 801afc34 801240f2 80124f02 ff8e6df4 ff8e6f60 ff8e6c58 : 80100000 - ntoskrnl.exe 801afc54 80124f16 80124f16 ff8e6f60 ff8e6c3c 8015ac7e : 80100000 - ntoskrnl.exe 801afc64 8015ac7e 8015ac7e ff8e6df4 ff8e6f60 ff8e6c58 : 80100000 - ntoskrnl.exe 801afc70 80129bda 80129bda 00000000 80088000 80106fc0 : 80100000 - ntoskrnl.exe Kernel Debugger Using: COM2 (Port 0x2f8, Baud Rate 19200) Restart and set the recovery options in the system control panel or the /CRASHDEBUG system start option. If this message reappears, contact your system administrator or technical support group.

As shown in the preceding example, STOP messages are presented in four parts:

The first part contains the most important error diagnostic information. In the preceding example, that diagnostic information is contained in the first two lines. These lines contain the STOP error code, its four parameters, and the text of the STOP error message.
You should always record, at least, those first few lines before trying to restart your computer. While those lines are important and a knowledgeable technician can often diagnose the source of a STOP condition with that information alone, they can be used best when combined with the information in the rest of the STOP screen.

Note

Under some conditions, the Kernel will be able to display only the top line of the STOP message. The services it needs to display the rest of the information may not be available.

The second part is a two-column display of the names of all the drivers loaded on the computer at the time the STOP message occurred, along with their base addresses in memory and a date-stamp that indicates the driver's file date. This section is important because many STOP messages contain in their parameter list the address of the instruction that caused the error. If the address falls within the base address of one of the drivers on this list, then that driver may be the cause of this error.
The third part is a dump of some of the calls on the stack that led up to the STOP message. Sometimes, the first few lines can tell an experienced support technician what component or driver caused the error. However, the last calls on the stack are not always the cause of the problem.
The fourth part provides confirmation of the communications parameters used by the Kernel debugger on the target computer, if enabled, and the following standard user response to a STOP message:
Restart and set the recovery options in the system control panel or the/CRASHDEBUG system start option. If this message reappears, contact your system administrator or technical support group.

The user response in the fourth part of the STOP message implies the following:

If you restart your computer, the STOP condition may not happen again. If the error does persist, you need to enable the Kernel debugger in either DEBUG or CRASHDEBUG mode on this computer. Instructions on configuring the computer for debugging can be found in the "Windows NT Debugger" section at the end of this chapter.
In general, debugging requires a trained technician, who will need all the information displayed in the STOP message to determine the cause of the error. The technician may also have to connect to the computer either locally or remotely using a modem to resolve the STOP condition.
Trained technicians are often available within one's own organization. Even if they cannot diagnose the condition, they are probably the people best able to talk with a technical support group about the contents of the STOP message.

Sample STOP Messages

The following two messages are typical examples of STOP messages.

Message ID	Text string

0x0000000A	Memory at <address> was referenced at IRQL <number> for <number> access from <address>
0x0000001E	Unhandled Kernel exception <code> from <address> (<parameter>, <parameter>)

The top two lines of the STOP message screen might look like the following ones for the STOP message uniquely identified by the hexadecimal number 0x0A.

*** STOP: 0x0000000A (0x0019524C,0x00000002,0x00000000,0x801122E5) Memory at 19524c was referenced at IRQL 2 for 0 access from 801122e5.

The four most important pieces of diagnostic information are shown here twice: once as a parameter list on the top line, and then again embedded in the message text on the second line. The second and third parameters in this STOP message give the IRQL level (in this case, 2) and the access mode (where 0 = Read, and 1 = Write).

The fourth parameter, from address, identifies the location in memory of the instruction that caused the STOP error. This address can be used to identify the program module that was running at the time of the error. In the example of a complete STOP message given in the preceding section, the module I8042PRT.SYS has a base address at FA840000, which is the closest base address to FA8418B4.

The top two lines of the STOP message screen might look like the following ones for the STOP message uniquely identified by the hexadecimal number 0x1E.

*** STOP: 0x0000001E (0x80000003,0x80106FD0,0x00000000,0x00000000) Unhandled Kernel exception 80000003 from 80106fd0 (0,0).

In this case, the second parameter identifies the module that was running at the time of the error.

The third and fourth parameters may be zero or nonzero. In the preceding example, they are both zero. The content of these two parameters is specific to the exception code generated. In other words, the value of the first parameter determines the values of the third and fourth parameters. Also, the third and fourth parameter values can only be interpreted in the context of the first parameter value.