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.