Chapter 38 - Windows NT Executive Messages

There are three types of Windows NT Executive messages:

• Character-mode STOP messages

• Character-mode hardware-malfunction messages

• Windows-mode STATUS messages

For help with hardware-malfunction messages, first contact a technician within your own organization to run hardware diagnostics on your computer. If you then need to find help outside your organization, contact the hardware vendor for your specific brand of computer, adapter, or peripheral device.

Most users also need to ask for help with the STOP messages from a technical support person who has been trained to support Windows NT. For more information on what you can do to help that trained technician use the Windows NT debugger application (Windbg.exe), see Chapter 39, "Windows NT Debugger."

The Executive is the part of the Windows NT operating system that runs in Kernel mode. Kernel mode is a privileged processor mode in which a thread has access to system memory and to hardware. (User mode is a nonprivileged processor mode in which a thread can only access system resources by calling system services.) The Windows NT Executive provides process structure, thread scheduling, interprocess communication, memory management, object management, object security, interrupt processing, I/O capabilities, and networking.

The Windows NT Kernel is the part of the Windows NT Executive that manages the processor. It performs thread scheduling and dispatching, interrupt and exception handling, and multiprocessor synchronization. It also provides primitive objects to the Windows NT Executive, which uses them to create user-mode objects.

These messages were created to cover everything that could possibly happen, so you might never see some of them. For example, one of the STOP messages is "Unhandled Kernel exception." This message is displayed only after the Kernel exception dispatcher has exhausted its search of the Kernel call stack for exception-handling code. Similarly, a STATUS message announces the termination of a thread only after the Executive has searched the entire user call stack and the subsystem associated with the application for exception-handling code.

Character-Mode Messages

Two types of character-mode messages occur when the Windows NT Kernel detects an inconsistent condition from which it cannot recover: STOP messages and hardware-malfunction messages. You can organize these messages into the following groups:

• STOP messages that can appear only during the relatively short Windows NT startup period, which is Phase 4 of the Windows NT boot sequence.

• STOP messages that can be traced to a software condition detected by the processor.

• Hardware-malfunction messages that can be traced to a hardware condition detected by the processor.

• All the rest of the STOP messages.

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, which part of the Kernel detected the condition that left no recourse but to stop. However, keep in mind that the cause may actually be in another part of the system.

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

Section 1: Debug Port Status Indicators

DSR CTS SND 

Section 2: BugCheck Information

*** STOP: 0x0000000A (0x00000000,0x0000001A,0x00000000,0xFC873D6C)
IRQL_NOT_LESS_OR_EQUAL*** Address fc873d6c has base at fc870000 - i8042prt.SYS
CPUID:GenuineIntel 5.1.5 irql:1f SYSVER 0Xf0000421

Section 3: Driver Information

Dll Base DateStmp - Name Dll Base DateStmp - Name
80100000 2fc653bc - ntoskrnl.exe 80400000 2fb24f4a - hal.dll
80010000 2faae87f - ncrc810.sys 80013000 2faae8ca - SCSIPORT.SYS
8001b000 2faae8c5 - Scsidisk.sys 8029e000 2fc15d19 - Fastfat.sys
fc820000 2faae8af - Floppy.sys fc830000 2fb16eef - Scsicdrm.SYS
fc840000 2faae8ff - FS_Rec.SYSfc850000 2faae8b7 - Null.SYS
fc860000 2faae8a1 - Beep.SYS fc870000 31167860 - i8042prt.SYS
fc880000 2faae8b5 - Mouclass.SYS fc890000 2faae8b4 - Kbdclass.SYS
fc8b0000 2faae88d - VIDEOPRT.SYS fc8c0000 2fb67626 - ati.SYS
fc8a0000 2faae892 - vga.sys fc8e0000 2faae8fd - Msfs.SYS
fc8f0000 2faae8ec - npfs.SYS fc900000 2faae91a - ndistapi.sys
fc910000 2fc4f4b2 - ntfs.SYS fc980000 2fc12af6 - NDIS.SYS
fc970000 2faaee1e - asyncmac.sys fc9a0000 2dd47963 - epront.sys
fc9b0000 2fb52712 - ndiswan.sys fc9e0000 2faae945 - TDI.SYS
fc9c0000 2fae6a5f - nbf.sys fc9f0000 2faec8b1 - afd.sys
fca00000 2faaee1f - rasarp.sys fca10000 2fbf9993 - streams.sys
fca30000 2fc1557b - tcpip.sys fca50000 2e6ce2d3 - ubnb.sys
fca60000 2e64646c - mcsxns.sys fca70000 2fc0daf7 - netbt.sys

Section 4: Kernel Build Number and Stack Dump

Address dword dump Build [1057] - Name 
8014004c fc873d6c fc873d6c ff05e051 00000000 ff05e04b 0000002f - i8042prt.SYS
8014007c 801400c4 801400c4 00000000 00000023 00000023 00000037 - ntoskrnl.exe
80140098 fc87258e fc87258e 801400e8 00000030 ff0d141c ff0d1598 - i8042prt.SYS
8014009c 801400e8 801400e8 00000030 ff0d141c ff0d1598 00000002 - ntoskrnl.exe
801400b0 801400f8 801400f8 00000000 fc873d6c 00000008 00010202 - ntoskrnl.exe
801400b8 fc873d6c fc873d6c 00000008 00010202 ff0ced88 ff0d1598 - i8042prt.SYS
801400e0 801400c4 801400c4 fca460f4 ffffffff fc874f78 fc870418 - ntoskrnl.exe 
801400e4 fca460f4 fca460f4 ffffffff fc874f78 fc870418 ffffffff - tcpip.sys
801400ec fc874f78 fc874f78 fc870418 ffffffff 80140110 8013be2a - i8042prt.SYS
801400f0 fc870418 fc870418 ffffffff 80140110 8013be2a ff0ced88 - i8042prt.SYS
801400f8 80140110 80140110 8013be2a ff0ced88 ff0d1350 80137502 - ntoskrnl.exe
801400fc 8013be2a 8013be2a ff0ced88 ff0d1350 80137052 00000031 - ntoskrnl.exe

Section 5: Debug Port Information

Kernel Debugger Using: COM2 (Port 0x2f8, Baud Rate 19200)
Beginning dump of physical memory
Physical memory dump complete. Contact your system administrator or
technical support group.

Figure 38.1 STOP Message Screen 

STOP Screen Sections

A Windows NT STOP screen contains five major sections, as shown in Figure 38.1. Whenever a STOP error occurs, you should examine at least the BugCheck Information section for analysis when troubleshooting the problem. The next most useful information is the filenames listed on the right side of the stack dump (Section 4).

Section 1: Debug Port Status Indicators

These indicators provide serial communication information, much like the indicators on a modem. This area shows DSR and CTS. Also, the text "SND" flashes to indicate that data is being sent to the COM port. The COM port being used is detailed in Section 5: Debug Port Information.

Section 2: BugCheck Information

This section contains the error code—up to four developer-defined parameters — and an interpretation of the error. In Figure 38.1, the error code is 0x0000000A. The error code can also be called a BugCheck code.

Under some conditions, the Kernel displays only the top line of the STOP message. This can occur if vital services needed for the display have been affected by the trap condition.

Section 3: Driver Information

This section lists driver information in three columns. The first two columns list the preferred load address (base address in memory) and the link time stamp (dated created) for each loaded driver. The third column displays the names of all drivers loaded on the computer at the time the STOP message occurred. This information is important because many STOP messages contain in their parameter list the address of the instruction that caused the error. The date-stamp (seconds since 1970) can be converted to the common date/time format by using Cvtime.exe.

Section 4: Kernel Build Number and Stack Dump

This is the build number of the kernel, Ntoskrnl.exe (Build 1057 in Figure 38.1). The presence of service packs and third-party device drivers is not indicated because this is the base build number only.

The dump portion is a stack dump. Rather than showing the name of specific functions, it shows the range of addresses that pertain to the module that failed. A true stack trace requires the kernel debugger.

Sometimes, the top few lines can tell what component or driver caused the error. For example:

Section 4: Kernel Build Number and Stack Dump
Address dword dump Build [1057] - Name 
8014004c fc873d6c fc873d6c ff05e051 00000000 ff05e04b 0000002f - i8042prt.SYS <-
8014007c 801400c4 801400c4 00000000 00000023 00000023 00000037 - ntoskrnl.exe
80140098 fc87258e fc87258e 801400e8 00000030 ff0d141c ff0d1598 - i8042prt.SYS
8014009c 801400e8 801400e8 00000030 ff0d141c ff0d1598 00000002 - ntoskrnl.exe

The topmost routines on the stack do not always represent the failing code. The code for various kernel trap handlers might execute last as the error information is preserved. This depends on the particular trap error.

Section 5: Debug Port Information

This section provides confirmation of the communications parameters (COM port and baud rate) used by the Kernel debugger on the target computer, if enabled. It also confirms whether a dump file was created.

Key Screen Details to Examine

It is possible, in some cases, to determine the cause of a STOP screen by closely examining STOP screen data before rebooting. Under Windows NT 4.0, the screen divides into the five logical sections. (Processor Register Dump from Windows NT 3.1 is not included in current versions of Windows NT.)

The failing module can sometimes be identified by comparing the data in BugCheck Information with that in Driver Information and Stack Dump.

The Bugcheck Information shown is:

*** STOP: 0x0000000A (0x00000000,0x0000001A,0x00000000,0xFC873D6C)
IRQL_NOT_LESS_OR_EQUAL*** Address fc873d6c has base at fc870000 - i8042prt.SYS
CPUID:GenuineIntel 5.1.5 irql:1f SYSVER 0Xf0000421

Notice that the first four digits of the code address shown (0xFC873D6C) are FC87. This identifies the base, which is shown as FC870000. In this case the description specifies that the address is located in i8042prt.sys:

*** Address fc873d6c has base at fc870000 - i8042prt.SYS 

If this description is not given, you can obtain it by searching Driver Information to find a match on the following line:

Section 3: Driver Information
Dll Base Date Stamp - Name Dll Base Date Stamp - Name
fc860000 2faae8a1 - Beep.SYS fc870000 31167860 - i8042prt.SYS

The 0xFC870000 base matches the i8042prt.sys driver (the keyboard driver). Also, the stack dump can sometimes identify the failing driver, as it does in this case:

Section 4: Kernel Build Number and Stack Dump
Address dword dump Build [1057] - Name
8014004c fc873d6c fc873d6c ff05e051 00000000 ff05e04b 0000002f - i8042prt.SYS <-
8014007c 801400c4 801400c4 00000000 00000023 00000023 00000037 - ntoskrnl.exe

Often, this points to kernel code 0x80140000 because a trap handler in the kernel processes the failure. The BugCheck data and stack trace in these cases points to the kernel trap handler code. You can always compare this address information to narrow the list of problem driver components. In this case, the i8042prt.sys driver is a candidate for close scrutiny. Be sure this driver is the most current version available. Also, it is important to write down the first four lines of trap information for future reference (in case another trap occurs) and to provide this information to your technical support person as part of the problem description details.

STOP Messages That Occur Only at Executive Initialization

One group of STOP messages comes up only during the relatively short Windows NT startup period, which is Phase 4 of the Windows NT boot sequence. Executive initialization is one step during Phase 4. That step can be further broken down into two phases: Phase 0 and Phase 1. During Phase 0 initialization, interrupts are disabled and only a few Executive components, such as the hardware abstraction layer (HAL), are initialized. During Phase 1 initialization, the system is fully operational, and the Windows NT subcomponents do a full initialization.

If you get one of the following Phase 0 initialization STOP messages, run the hardware diagnostics. If no hardware problems are found, reinstall Windows NT and try to initialize it again. If you get the same message again, contact a trained technician.

If you get one of the following Phase 1 initialization STOP messages, reinstall Windows NT and try to initialize it again. If you still get the same message, contact a trained technician.

STOP Messages Caused by a Software Trap

Another group of STOP messages is caused by a software condition detected by the processor. This condition, called a software trap, happens when a processor detects a problem in an executing instruction from which the processor will not continue. For instance, a processor will not carry out an instruction that contains invalid operands.

When you get a STOP message that is caused by a software trap, follow the steps given in "Remaining STOP Messages," later in this chapter.

The following is an example of the first line of the STOP message that is displayed for all software traps:

*** STOP: 0x0000007F (0x0000000n, 00000000, 00000000, 00000000)
UNEXPECTED_KERNEL_MODE_TRAP

The first parameter (shown as 0x0000000n in the example) in the message parameter list indicates which of twelve possible traps has occurred. For instance, in the case of an instruction that contains invalid operands, the message appears as follows:

*** STOP: 0x0000007F (0x00000006, 00000000, 00000000, 00000000)
UNEXPECTED_KERNEL_MODE_TRAP

Table 38.3 shows the possible values and their meanings for that first parameter.

STOP Screens During Installation

When you attempt to install Windows NT on a new computer, an unsuccessful installation can result in a STOP screen. When a STOP screen appears, first check the compatibility of the computer and its peripheral hardware. To do this, refer to the latest Windows NT Hardware Compatibility List (HCL). Computers and associated hardware that appear in the HCL were tested to determine how well they work with Windows NT. These computers have gone through rigorous component and compatibility testing by Microsoft. The HCL is available in the Windows NT Resource Kit and is updated frequently with newly tested hardware.

If the hardware you are using is not included on the Windows NT HCL, contact the hardware manufacturer as a first-line resource for available information, newly tested hardware, and/or BIOS and firmware revisions. It may also help to reduce hardware components to a minimum to pinpoint installation conflicts.

STOP Screens After Installation

Even in a complex and robust operating system such as Windows NT, catastrophic problems sometimes cause the system to stop responding or trap (display a STOP screen). In Windows NT, a driver or file system can generate a kernel STOP message by introducing an unhandled error (exception) in the code or by performing some illegal operation.

Some problems can be resolved through troubleshooting procedures such as verifying instructions, reinstalling key components, and verifying file dates. Diagnostic tools—such as Winmsdp, Microsoft Network Monitor, Network General Sniffer, and Microsoft Resource Kit utilities—may help isolate and resolve issues.

Debugging is especially helpful when a specific message is displayed or when a problem repeats often. In these cases, it is possible to pinpoint the failing code in a driver or application by using a debugger. For debugging, it is important to capture the exact text of the message. Also, it is critically important to record the exact steps involved in repeating the failure. This information can help you isolate a complex problem and help to develop a viable workaround or a program replacement. For problems occurring within Windows NT code, contact the Microsoft Support Network to find out if a service pack is available to correct the problem.

Hardware-Malfunction Messages

Hardware-malfunction messages are caused by a hardware condition detected by the processor. The first one or two lines of a hardware-malfunction message may differ depending on which company manufactured the computer. However, these lines always convey the same idea, as shown in the following example for an Intel-based computer:

Hardware malfunction.
Call your hardware vendor for support.

The additional lines in each manufacturer's message screen also differ in format and content. Therefore, before doing what the sample message recommends, contact a technician within your own organization to run hardware diagnostics on your computer. The information provided below the first two lines helps your technician decide which hardware diagnostics to run. For example, for Intel-based ISA bus computers, information is displayed that indicates whether this is a memory-parity error or a bus-data error. On Intel-based EISA computers, if the hardware problem is in an adapter, the adapter slot number on the system board is displayed.

If you still need to find help from outside your organization to interpret the information on the screen, contact the hardware vendor for your specific brand of computer, adapter, or peripheral device.

Remaining STOP Messages

A typical user cannot diagnose the cause of any of the remaining STOP messages. When you get one of these messages, first record the top few lines of the STOP message and then restart the computer. If the STOP message occurs again, you have four options for diagnosing the STOP condition, all of which should be handled by a trained technician at your own site:

• Diagnose the problem by using the information displayed in the STOP message and any pertinent information from the Microsoft Web site (www.microsoft.com), where Microsoft maintains an up-to-date list of causes for these STOP messages.

• Use the Windows NT debugger to get more information about the problem.

  If you use this option or the next one, be sure to switch Windows NT to debug mode before you restart your computer. For information on how to prepare your computer for debugging, see Chapter 39, "Windows NT Debugger."

• Contact your own or another technical support group for assistance in using the Windows NT debugger remotely.

• Contact your own or another technical support group to discuss the information in the STOP message. They might see a familiar pattern in the information.

The following list provides the ranges of unique hexadecimal numbers for the STOP messages that are least likely to appear. If you do see one, you will see it after Windows NT Executive startup is complete. These message are not caused by hardware or software traps in a processor.

0x00000001 through 0x00000009
0x0000000B through 0x0000001D
0x0000001F through 0x00000030
0x00000033 through 0x0000005B
0x00000072 through 0x0000007B

Windows-Mode STATUS Messages

The Executive displays a Windows-mode STATUS message box when it detects conditions within a process (such as an application) that you need to know about. STATUS messages can be divided into three types:

• System-information messages. All you can do is read the information in the message box and click OK. The Kernel continues to run the process or thread.

• Warning messages. Some advise you to take an action that enables the Kernel to keep running the process or thread. Others warn you that, although the process or thread continues to run, the results might not be correct.

• Application-termination messages. These warn you that the Kernel is about to terminate either a process or a thread.

System-Information Messages

System-information messages from the Executive provide status information on conditions within a process that should be noted but that do not stop the application from running. All that you can do is read the information in these messages and click OK.

If one of the following messages appears frequently while you are working in the same application, contact either the supplier of the application or your system administrator to adjust the configuration of your Windows NT–based computer:

Warning Messages

Warning messages from the Executive provide status information on more serious conditions within a process that can stop the application or cause damage to your data. Some warning messages prompt you indirectly for a user action, as in the following example:

Out of Paper: The printer is out of paper.

If one of the following messages appears frequently while you are working in the same application, contact either the supplier of the application or your system administrator to adjust the configuration of your Windows NT–based computer:

Application-Termination Messages

Application-termination messages from the Executive appear when the Kernel is about to terminate either the process in which an application is running or the thread of an application. Some of these messages advise you to perform an action before restarting the application, as in the following example:

The application or DLL <filename> is not a valid Windows NT image.
Please check this against your installation disk.

In other cases, the user action is strongly implied. The following example implies that you should make sure that the dynamic-link library is in the path before you restart the application:

The dynamic-link library <filename> could not be found in the specific path <path>

In yet other cases, you can only restart the application. If one of the messages listed in Table 38.4 reappears, contact the supplier of the application.