Advanced Troubleshooting Windows NT Server

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

First Presented at TechEd 1996

Troubleshooting Windows NT Server


It's 4 P.M. Friday and the mail server is down. You need to send a critical piece of electronic mail to your manager. Suddenly you appreciate the necessity of quickly getting the mail server up and running.

Windows NT Server troubleshooting can be a simple or complex process. It can be as simple as reattaching a loose power cord, or as complex as a series of stress tests, data-collection procedures, and trend analysis.

No matter how simple or complex, troubleshooting involves problem identification, problem diagnosis, solution implementation, and solution verification.

The goal of this session is to provide the skills and experiences needed to identify and isolate Windows NT Server problems on mission-critical systems at an architectural level, and then to solve these problems by analyzing and configuring the Registry and verifying the operating system file structure. Expertise in these areas provides both a broad and detailed approach to solving problems within the Windows NT Server operating system.

Troubleshooting Resources


Troubleshooters do not have to rely completely on innate abilities, prior experiences, or luck. There are many troubleshooting resources available, too. They range from general to specific.

General Knowledge

Building general knowledge of Windows NT Server includes gaining experience with the product, training, and reading books:

  • Available training includes:

    • Instructor-led classes.

    • MOLI (Microsoft Online Institute).

    • Windows NT Self-Paced Training Kit.

  • Recommended reading includes:

    • Inside Windows NT by Helen Custer — Covers basic Windows NT architecture.

    • Windows NT Server Installation Guide— Chapter 2, "Troubleshooting."

    • Windows NT technical documentation — Concepts and Planning Guide and the Systems Guide.

    • Windows NT Resource Kit — Chapter 18 in the Resource Guide and Chapter 6 in the 3.51 Update book are devoted to troubleshooting. Each provides in-depth knowledge of Windows NT architecture, security, file structure, the Registry, and networking for experienced administrators..

Resources for Specific Problems

When you are looking for help on specific problems, there are multiple sources for support:

  • Microsoft TechNet CDs — Contain the Microsoft Knowledge Base (the same library used by Microsoft Product Support Specialists), resource kits, educational materials, and the Software Library, which contains drivers, utilities, macros, and patches.

  • Microsoft Network (MSN) — This has several Microsoft forums where you can post questions and answers, download files, and interact in online conferences.

  • The Microsoft Internet site — This site contains product information, drivers, service packs, and more: or If you don't have Internet access, call Support Sales at 1-800-936-3500.

    Technical experts

    • Solution Providers

    • Microsoft Consulting Services

    • Contacts from training courses, trade shows, and conferences

    • Contacts from professional organizations

    • Microsoft Product Support Specialists

Troubleshooting Tools

Windows NT provides many system tools that can be used in troubleshooting situations. These tools are found in both the Windows NT Server and Microsoft System Management Server products, and also the Windows NT Resource Kit. Tools for these products will be covered and demonstrated in the upcoming sections.

Session Strategy


Customers today require confidence in an operating system to implement and maintain mission-critical applications and services within their organization. They are seeking the skills necessary to successfully isolate and solve problems within their Windows NT Server environment. As a result, support professionals must have the ability to perform the following tasks:

  • Identify and isolate problems using knowledge of the Windows NT Server architecture to recognize related errors, and determine effects rather than causes.

  • Navigate the Windows NT Server Registry to track driver and service start values and dependencies.

  • Relate the Windows NT Server operating system file structure to the overall picture of the Windows NT Server architecture, and track the basic load sequence, including identifying a failure.

  • Identify blue screen messages that can be resolved immediately, and those that require the assistance of Microsoft PSS using a Kernel debugger or the Windows NT Server Crash Dump facility.

This session examines how the architecture, the Registry, and the operating system file structure provide strategic insight to efficiently identify and resolve problems that may occur in the Windows NT Server environment.

Section 1 Overview



At the end of this section, you will be able to:

  • Contrast the two major layers in the Windows NT architecture.

  • Define the function of each component in the networking architecture.

  • Identify potential troubleshooting issues for each privileged processor mode networking component in the I/O Manager.

  • List the networking user mode services and trace the flow of control when a client computer makes a request to a server computer.

  • Describe the methods used in troubleshooting problems from an architectural perspective.

Windows NT Architecture Overview


The initial challenges of correcting a system failure are determining where to begin and choosing the best problem-solving approach. Most system problem analysis begins with an examination of the architecture. This gives the broadest outlook of the problem, providing a high-level view to help isolate the areas in the system that are affected by a failure.

The modular components that make up Windows NT Server are organized into several architectural layers. These components are the building blocks that make up the system. Therefore, troubleshooting at the architectural level is done at the major building-block level.

Architectural components are dependent upon each other. Problems in lower layer components affect the components in the layers above them. Therefore, it is important to identify the component where the problem began.

The two major layers in the Windows NT architecture are:

  • Privileged processor mode components — Collectively referred to as the Executive, this major layer consists of the Hardware Abstraction Layer (HAL), Kernel, and Executive Services. These components are protected from direct user access.

  • User mode components — This major layer consists of the Windows NT Environment subsystems and the applications that run in the subsystems. Components in this level provide the environments in which all user applications run. Applications are not typically run on a Windows NT Server computer; therefore, user mode components will be examined in the second part of this section.

Most Windows NT Server problems are associated with networking components. These are part of the I/O Manager and this is what we will concentrate on.

Windows NT Networking Architecture Overview


Like the operating system architecture, the networking architecture is also modular and consists of components in both user mode and privileged processor modes. However, most problems that can be traced through the architecture occur at the networking architecture level.

In troubleshooting, it is very important to track down the component where the original error occurred. As mentioned earlier in this section, problems outside the networking area that occur in a lower level component will prevent higher level components from starting. With networking components, however, higher level components may start but each will have a different error message. Once you solve the problem in the lowest level component, the other errors are usually resolved.

This section examines the networking architecture, and provides background and experiences needed to identify and isolate problems that occur at this level.

Network Adapter Card Drivers


The component at the lowest software level in the networking architecture is the NDIS network adapter card driver. There is one network adapter card driver for each type of network adapter card. In order for these drivers to run on Windows NT, they must comply with the NDIS 3.0 standard.

Typical errors in this level include missing, corrupt, or down-level network adapter card drivers. Current drivers are available from MSN, the Internet, or TechNet CDs.

Microsoft typically does not write network adapter card device drivers; the manufacturers of the network adapter cards are responsible for writing the device drivers. Microsoft tests and certifies all device drivers that are provided on the Windows NT CD or that are available from any of the online sources listed above. If an adapter does not appear on the HCL, contact the manufacturer to see if they are writing a Windows NT NDIS 3.0 device driver for the adapter.



NDIS 3.0 is both an industry standard and software (NDIS wrapper code) that allows multiple network adapter cards and multiple protocols to coexist in a single computer. NDIS-compliant network adapter card drivers can communicate with any NDIS-compliant transport protocol through the NDIS wrapper code. The NDIS wrapper controls communication between all transport protocols and network adapter card drivers.

Therefore, the transport protocols are dependent on NDIS. If a transport protocol issues an error message, check Event Viewer to see if there is an underlying problem within the NDIS layer.

Transport Protocols


Transport protocols define the rules governing communication between two computers. Windows NT includes the following NDIS-compliant transport protocols: TCP/IP, NWLink, NetBEUI, and DLC. TCP/IP, NWLink, and NetBEUI support both TDI and NetBIOS applications and services.

In a multi-protocol environment, it is possible for computer A to be able to communicate to computer B, but not computer C, even though computer B can talk to C. This is because computers A and B are running a common protocol such as TCP/IP, while computers B and C are running a common protocol such as NWLink (computer B is running both protocols). Computers need to be running the same protocols in order to communicate with each other.

TCP/IP (Transmission Control Protocol/Internet Protocol)

TCP/IP provides communication across interconnected networks made up of computers with diverse hardware architectures. TCP/IP is the transport protocol used on the worldwide Internet. Windows NT TCP/IP supports Dynamic Host Configuration Protocol (DHCP), which provides centralized management of address allocation and protocol configuration. If your organization is experiencing problems with TCP/IP being incorrectly configured on user computers, consider implementing DHCP.

DHCP uses a client-server model. The DHCP server can dynamically assign an IP address to a DHCP client when it starts up, or an address can be reserved for a particular host. You can define configuration parameters and limit the time an address can be used by defining a duration for the address lease. This simplifies the installation of TCP/IP on the host side, because all you have to do is install TCP/IP and select "Enable Automatic DHCP Configuration."

In troubleshooting situations, make sure the DHCP servers are running the DHCP Server service (automatically configured to start on a DHCP server), and the DHCP clients are running the DHCP Client service (automatically starts on a DHCP client).

If you are using multiple DHCP servers to provide for redundancy, make sure the DHCP servers do not overlap in their address pools. If this occurs, it is possible that two DHCP clients would be assigned the same IP address. To verify that only authorized DHCP servers exist on the network, use the DHCP Server Locator utility.

If a DHCP server database becomes corrupt, restore it from the automatic backup files.

NWLink IPX/SPX–Compatible Transport

NWLink is Microsoft's implementation of the IPX/SPX protocol. Internetwork Packet Exchange/Sequence Packet Exchange (IPX/SPX) is the primary protocol for Novell® networks. Used in conjunction with GSNW (Gateway Service for NetWare®), Windows NT Server computers can access file and print resources on Novell NetWare servers.

NWLink also supports communication between Windows NT and MS-DOS, OS/2®, Windows, or other Windows NT computers. However it is most often used in mixed NetWare and Microsoft environments.

When troubleshooting in an environment with NetWare servers, make sure that NWLink is configured with the same frame type as the frame type of the NetWare server. As always, check that the appropriate services are running on the servers and clients, such as Client Service for NetWare or Gateway Service for NetWare.

NetBEUI (NetBIOS Frame)

NetBEUI provides compatibility with earlier LANs, such as LAN Manager and LAN Server, using the NetBIOS protocol. NetBEUI 3.0 breaks the 254-session limitation of earlier implementations of NetBEUI that were written directly to NetBIOS, and provides better performance. It was designed to be a local area network transport that does not need to interoperate with a variety of other hosts.

The Windows NT version of NetBEUI 3.0 is also referred to as NBF (NetBIOS Frame). In the Registry, NetBEUI is labeled Nbf.

DLC (Data Link Control)

DLC is primarily used for gaining access to IBM® mainframes and for servers supporting Hewlett Packard® network–connected printers. It is not generally used for communications between personal computers.



Each of the transport protocols communicates with the redirectors and servers above it using the Transport Driver Interface protocol specification. TDI allows all of these components to be mixed and matched without reprogramming.

Therefore, the redirector and server file system drivers are dependent on TDI. If one of these file system drivers issues an error message, check Event Viewer to see if there is an underlying problem in the TDI layer or below.

Redirectors and Server File System Drivers


Windows NT supports peer-to-peer networking, in which each computer on the network can act as both a client workstation and a server. The Windows NT redirector file system driver (RDR.SYS) allows a computer to gain access to resources on other Windows NT computers as if they were local resources. The redirector driver has a companion user mode service called LanmanWorkstation.

Another example of a redirector is the Microsoft Gateway Service for NetWare (GSNW). It enables a client to gain access to files or printers on a NetWare server.

The Server file system driver (SRV.SYS) handles incoming requests for resources on its computer and makes the resource appear as a local resource to the requesting computer. The companion user mode service is called LanmanServer.

If connecting to another computer is unsuccessful, it may be necessary to verify that the Workstation service (LanmanWorkstation) has properly started, and all of its dependent services and drivers have started properly.

User Mode Networking Components


The user mode network architectural layer includes LanmanWorkstation, and LanmanServer services. These services work in conjunction with privileged processor mode file system drivers to provide networking connectivity for users and servers. For example, the LanmanWorkstation service works in conjunction with RDR.SYS to provide clients with access to network resources.

The LanmanWorkstation, and LanmanServer services can be paged to disk if the computer is running out of physical memory. They can be pre-empted by higher priority processes needing access to the processor. Most will run in shared memory with other services, and are started by SERVICES.EXE. Most of these services are dependent on underlying services in order to start and run.

Workstation and Server Services


Every Windows NT computer has both workstation and server components. A user can issue a net use command to connect to a remote computer. The request is passed from the application to the redirector (RDR.SYS) through TDI and the appropriate protocol, down to the NDIS layer and network adapter, and out the network.

On the server side, the request comes in from the network up through the network adapter and NDIS layer, through the protocol to the TDI layer, and up to the Server (SRV.SYS). The I/O Manager takes the request and passes it to the appropriate file system driver for the requested file. The response to the requesting computer takes the same path back to the requesting client.

The user mode Server service provides the user interface to SRV.SYS running in privileged processor mode. For example, File Manager attempting to create a shared resource, User Manager for Domains, and Server Manager require the Server service to be running.

Isolating Problems from an Architectural Perspective


Section 1, "Advanced Troubleshooting Overview," introduced several tools that can be helpful when troubleshooting. The following tools can be used to identify and isolate a problem in the Windows NT architecture.

Event Viewer

Event Viewer is an important tool to use when isolating problems. A problem in an architectural layer can cause errors in the layers above it. The challenge is to get to the root of the problem and not be misled by the error messages from higher layers.

Server Manager

Because every computer on the network can act as a client or a server, networking problems are often related either to inbound or outbound requests. Server Manager will verify that the Net Logon, Workstation, and Server services are running.

Windows NT Diagnostics

Windows NT Diagnostics can be a very helpful tool in looking at the status of the network adapter cards, drivers, IRQs, network services, and transport protocols. If you have recently added a processor, the Hardware option will report the number of processors that Windows NT recognizes. Information in Windows NT Diagnostics can be viewed but not modified.

Control Panel-Network

Use the Network option from Control Panel to identify the network cards and protocols running on a computer. If two computers are not communicating with each other but they can communicate with a third computer, check to see if the first two computers are running a common protocol. If they are, the next step is to make sure the protocol is configured correctly on both computers.

PING, IPCONFIG, DHCP Locator Utility

In a TCP/IP environment, use the PING command to find out which hosts a computer can communicate with, if any. The IPCONFIG command will identify the current IP address, subnet mask, and gateway address the computer is using.

In a TCP/IP DHCP environment, if network connectivity is not available or network errors occur, check to see that the DHCP Client service is running on the client and that the DHCP Server service is running on the DHCP server. IPCONFIG /ALL displays the TCP/IP configuration of the host—not only its IP address, subnet mask and default gateway, but also its DHCP Server address, WINS Server address(es) and other useful information. If the IP address and DHCP Server address are not as expected, the DHCP Server Locator Utility can be used to identify any unauthorized DHCP servers on the network.

Domain Monitor

In a multiple domain environment, the Domain Monitor utility will track the status of all servers in a domain and domain controllers in trusted domains. The management of trust relationships is another key area for troubleshooting. If a computer is unable to gain access to resources in a trusting domain, make sure there is an active domain controller in that domain.

Microsoft SMS Network Monitor

Microsoft SMS Network Monitor, which is part of Microsoft's Systems Management Server product, is a software-based network traffic and protocol analysis tool. It can be used to view the conversation between two specific hosts on the network, or the entire network as a whole. Individual packets can be viewed in an attempt to determine the root cause of a problem that exists.

Section 2 Overview



At the end of this section, you will be able to:

  • Use the Microsoft® Windows NT™ Registry to troubleshoot problems with Windows NT.

  • Explain the organizational structure of the Registry.

  • Examine the Registry using the Registry Editor.

  • Examine the Registry using the Registry Help File, command-line Windows NT Diagnostics, and Remote Command utility.



Registry Structure


The Registry is structured as a set of four subtrees of keys that contain per-computer and per-user databases. Each individual key can contain value entries and additional subkeys. The following table identifies the four subtrees.

Root Key Name



Contains information about the local computer, such as system memory, device drivers, and startup control data.


Contains object linking and embedding (OLE) and file-class association data.


Contains the user profile for the user who is currently logged on, including environment variables, personal program groups, desktop settings, network connections, printers, and application preferences.


Contains all actively loaded user profiles and the default profile.

A subtree may be further divided into hives, which are discrete sets of keys, subkeys, and values. A hive is backed by a single file and a .LOG file, which facilitates recoverability. However, you cannot simply copy these files in order to back them up when Windows NT is running. This is because the operating system opens them with a write handle. Instead, use one of the methods described on the following page to back up the Registry.

Typically only the HKEY_LOCAL_MACHINE and the HKEY_CURRENT_USER subtrees are referenced during troubleshooting.

Registry Editor


Different tools are available to view and change Registry entries. For example, Windows NT Diagnostics provides a graphical display of Registry hardware information, and Control Panel contains options to view and change Registry information such as drivers and protocols.

Some entries can only be changed using the Registry Editor (REGEDT32.EXE), such as certain TCP/IP parameter settings. If entries are changed with the Registry Editor, syntax errors are not recognized, so there is no error warning if an error occurs as a result of a change. Make sure to back up the Registry before making changes using the Registry Editor, and use Read Only Mode when not making changes.

Read Only Mode

When using Registry Editor to view, but not edit registry entries, consider activating Read Only Mode. This built-in safety precaution does not allow any part of the Registry to be accidentally changed or deleted. Activate this option through the Registry Editor Options menu.

Backing Up the Registry

There are four methods of backing up Registry entries:

  • From the Windows NT dialog box, select the Save Registry option in Windows NT Backup. This is the recommended way as long as you have a tape backup. The Windows NT Backup and Restore program can access Registry hives while Windows NT is running.

  • Use the REGBACK.EXE and REGREST.EXE utilities to back up and restore Registry hives while Windows NT is running. These utilities are included with the Windows NT Resource Kit.

  • From the Registry menu of the Registry Editor, select the Save Key option. This option saves a single key and everything beneath it in the hierarchy in a specified file name. However, online restores are not guaranteed, so it is recommended to use Windows NT Backup or REGBACK to back up the Registry.

  • Create/update the Emergency Repair disk. Be aware that RDISK.EXE does not back up all of the Registry. RDISK is intended as a last resort for making a system bootable, but not necessarily to restore the system to the way it was.

Gaining Access to a Remote Computer's Registry

The Registry Editor contains a troubleshooting option to edit the HKEY_LOCAL_MACHINE and HKEY_USERS keys of a remote computer. This is helpful when there appears to be a problem in the remote computer's Registry, such as a misconfigured service or device. To gain access to a remote computer's Registry, choose "Select Computer" from the Registry menu of the Registry Editor. There is no unique interface for closing the remote Registry; it is closed through Registry Exit, just like the local one. Because of this, when exiting the remote Registry, be sure it is the is the active one. If you forget to close the remote Registry when you exit the Registry Editor, or inadvertently close the local one, the next time you start the Registry Editor the remote Registry will appear.

Warning: Using the Registry Editor incorrectly can cause serious, system wide problems that may require you to reinstall Windows NT. Microsoft cannot guarantee that any problems resulting from the use of the Registry Editor can be solved. Use this tool at your own risk.

Troubleshooting Using HKEY_LOCAL_MACHINE


Problem situations can often be traced to services, device drivers, or startup control data. HKEY_LOCAL_MACHINE contains this configuration information, so it is the logical starting point in the Registry for solving these types of problems.

HKEY_LOCAL_MACHINE contains five subtree keys, as described in the following table:

Subtree Key



This is a database that describes the physical hardware in the computer, the way device drivers use that hardware, and mappings and related data that link Kernel-mode drivers with various user-mode code. All data in this subtree is re-created by Windows NT Detect each time the system is started. Therefore, it is useless to make changes to this data, most of which is stored in binary form. Use Windows NT Diagnostics to view the data.


This contains security information for user and group accounts, and for domains in a Windows NT Server.


This database contains the local security policy, such as specific user rights.


This database describes the per-computer software.


This database controls system startup, device driver loading, Windows NT services, and operating system behavior.

Of these subtrees, HARDWARE and SYSTEM are involved in troubleshooting most often.



As noted earlier, this database describes the physical hardware in the computer. Since the data in the HARDWARE subtree key is stored in binary form, the best way to view the data is through Windows NT Diagnostics.

Following are the Windows NT Diagnostics options:

OS Version

Shows operating system information, such as build number.


Shows hardware information, such as the number and type of processors.


Displays memory information, including a Memory Load index.


Shows path of driver and its service and group dependencies.


Shows path of driver and its service and group dependencies.


Displays status of devices such as the network adapter card.

IRQ/Port Status

Displays interrupt and I/O base address information.


Displays DMA addresses.


Displays process, system, and user environment settings.


Displays network information, such as loaded protocols.


Displays driver information of logical partitions, including total size, free space, and file system.



The System hive is a database that controls system startup, device driver loading, Windows NT services, and operating system behavior. Information in the System hive can be modified by choosing the Devices, Network, Server, or Services icons in Control Panel, or by using Server Manager. All startup-related data that must be stored (rather than computed during startup) is saved in the System hive.

Rather than having just one copy of the startup data, the database organizes the information into control sets. Each control set contains a complete set of parameters for devices and services. There are usually two control sets, although as many as four can appear. The purpose of having multiple control sets is to provide a backup copy if for any reason the current control set fails. The Select subkey identifies how the control sets are used:

  • Current — The control set containing the startup data used to start the system.

  • LastKnownGood — A clean copy of the last successful control set. After a successful logon, the current control set is copied to LastKnownGood.

  • Default — The control set that will be used the next time the system boots.

  • Failed — The control set that was replaced if LastKnownGood had to be used to start the system.

Each control set has two subkeys:

  • Control — Contains startup parameters for the system, including the maximum size of the Registry.

  • Services — Lists all Kernel device drivers, file system drivers, and Win32 service drivers that can be loaded by the Boot Loader, the I/O Manager, and the Service Control Manager. It also contains subkeys describing which drivers are attached to which hardware devices as well as the services that are installed on the system.



The subkeys under Services include most of the networking components, such as the adapter cards and their drivers, protocol drivers, Redirector, Server, and so on. The information for a driver under the Services key is more easily decipherable in the Windows NT Diagnostics-Drivers window. However, since Windows NT Diagnostics is a view-only tool, to make changes you must use the appropriate Control Panel tool or the Registry Editor. If you are using the Registry Editor, make the changes in the control set identified as Default so that the new values will be used during the next system startup.

Useful troubleshooting values include:

  • DependOnGroup — At least one service from this group must be loaded before this service is loaded.

  • DependOnService —Provides specific services that must be loaded before this service is loaded.

  • Error Control — Controls whether an error during the startup of this driver will require the system to switch to the LastKnownGood control set. If the value is 0 (Ignore, no error is reported) or 1 (Normal, error reported), startup proceeds. If the value is 2 (Severe) or 3 (Critical), an error is reported and LastKnownGood is used.

  • ImagePath — Identifies the path and file name of the driver. Use File Manager to verify the existence of the named file.

    Start — Determines when the driver is loaded during system startup. If a service is not starting, you need to know when and how it should be starting. Then look for the services and drivers that should have been loaded prior to this driver. The values are described as follows:

    • 0 (Boot) — Loaded by the Boot Loader (NTLDR) during the boot sequence.

    • 1 (System) — Loaded at Kernel initialization during the load. sequence.

    • 2 (Auto Load) — Loaded or started automatically at system startup.

    • 3 (Load On Demand) — Driver is manually started by the user or another process. For example, TCP/IP is started by NDIS.

    • 4 (Disabled) — Driver is not to be started under any condition. If a driver is accidentally disabled, reset this value through Server Manager or the Control Panel Services tool.

    Type — Determines the type of driver or service. Values are as follows:

    • 1 — Kernel device driver.

    • 2 — File system driver, which is also a Kernel device driver.

    • 4 — Set of arguments for an adapter.

    • 10 — A Win32 program that can be started by the Service Controller and that obeys the service control protocol. This type of Win32 service runs in a process by itself.

    • 20— A Win32 service that can share a process with other Win32 services.

    Knowing the Type value will help you know where it fits in the architecture. An example is the Alerter service. It is a type 20, which means it is a shared process. It is started by SERVICES.EXE.

Note: For more information, see Standard Entries for CurrentControlSet\Services Subkeys under Overview Topics in Registry Entries Help.



Under the subkey for a service (for example, Tcpip), the Linkage subkey can also reveal troubleshooting information. The Linkage subkey specifies the binding options for the driver.

In this example, TCP/IP is bound to the EPRO1 network adapter card. The name of the network adapter driver is EPRO. The name of the adapter card is always formed using the name of the driver plus an instance number. If the example computer had a second adapter card of the same make and model (for example, a second Intel Ethernet Express Pro), then it would be named EPRO2.

When a service has been disabled, the values are moved to the Disabled subkey. In this example, TCP/IP is enabled, as the values appear in the Linkage subkey. In Control Panel, use Network Settings and then choose the Binding option to enable and disable the bindings of devices and services.



In addition to Linkage, the Parameters subkey should also be checked for abnormalities. Any configurations for the network adapter such as interrupt, I/O address, or transceiver will be located under the Parameters subkey. To ensure TCP/IP is configured correctly, refer to the Tcpip subkey under Parameters for the network adapter card. Located here are the IP address, default gateway, if DHCP is enabled, and any other TCP/IP configuration.

Some of the values in this example are configurable in Control Panel-Network, such as whether DHCP is enabled. Others, such as UseZeroBroadcast, can only be changed through the Registry Editor.

Parameters can also be added, as well as changed. An example of a parameter you may need to add to Services\Tcpip\Parameters is TcpWindowSize, to reduce the amount of data in a TCP/IP packet.

Note: When the parameters for LanmanServer or LanmanWorkstation are first displayed in Registry Editor, only a few parameters, or none at all, will appear. After you run the NET CONFIG command with an option specified, all of the parameters will appear. If users are having trouble connecting to a server, check the autodisconnect, sesscons, sessopens, and sessusers parameters. These parameters will only appear after a NET CONFIG SERVER /option command has been issued.

Troubleshooting Using HKEY_CURRENT_USER


HKEY_CURRENT_USER contains the database that describes the user profile for the user who is currently logged on to the local computer. Included here is information such as program groups, application preferences, security rights, screen colors, and other personal preferences.

HKEY_CURRENT_USER is a copy of a subkey in HKEY_USERS that is the security ID of the account that is logged on (for example, S-1-5-21...). The other HKEY_USERS subkey is Default, which is utilized by first-time users.

If the current user is unable to access applications that another user can access, view HKEY_CURRENT_USER looking for information relevant to the applications, such as Program Group information.

Section 3 Overview



At the end of this section, you will be able to:

  • Identify the files most often checked when troubleshooting.

  • Identify the files used in the boot and load sequences.

  • Verify which drivers were successfully loaded.

  • Replace missing or damaged files.

  • Reference the file dependencies that exist within Microsoft® Windows NT™ Server.

Examining the Operating System File Structure


What symptoms indicate that Windows NT Server files are missing or corrupted? How are these files identified and isolated? How can clean files be added or corrupted files replaced? Manipulating the Windows NT files is like repairing a bridge. Correctly repaired, it can hold up under the heaviest load; incorrectly repaired, the slightest stress can take it down. Knowing the Windows NT file system, particularly the system's file dependencies, addresses these tough questions—they must be answered if reinstalling the operating system is not a feasible option.

If a file becomes corrupted or is deleted, an error message appears, giving the specific file that is missing or corrupt. However, not all executables or dynamic link libraries properly report missing or corrupt files, and the symptoms can be unpredictable with a file missing.

After you isolate the failing component, check to see if all the known files for that component exist and appear to be uncorrupted. Symptoms of file corruption include a file being an unusual size (for example, zero bytes or larger than its original size), or having a date or time that does not reflect the Windows NT installation date or subsequent service packs.

Registry entries will identify the specific driver or executable file for each component or service.

The following table identifies files most often checked when troubleshooting.

File Extension



Driver files


Dynamic link library files


Executable files

Boot Sequence Files


Windows NT Server starts with a the pre-boot sequence. This sequence, initializes the computer and locates the boot portion of the hard disk. The bootstrap portion of NTLDR (the Loader) is then loaded and initialized from the boot sector. When the pre-boot sequence is complete, the boot sequence begins.

During the boot sequence, Windows NT uses several programs to gather information about the computer's installed hardware and drivers. This takes place before the Kernel is loaded. The files for these programs include:

  • NTLDR — The operating system loader. Must be in the root directory.

  • BOOT.INI — The file that builds the Boot Loader Operating System Selection menu.

  • NTDETECT.COM — The file that passes information on the hardware configuration to NTLDR.

  • NTOSKRNL.EXE — The operating system Kernel.

  • NTBOOTDD.SYS — The device driver used to access devices attached to a SCSI hard disk whose adapter is not using BIOS.


  • Various device drivers specific to the computer—for example, SCSI drivers, video drivers, and so on.

Following are the steps in the boot sequence that reference files. Knowing the boot sequence events, and recognizing which files are used, can help identify problems in the boot sequence of a Windows NT computer.

  1. NTLDR loads and initializes the remainder of itself in 32-bit protected memory.

  2. NTLDR reads BOOT.INI and displays the Operating System Selection menu.

  3. If "Windows NT" is selected, NTLDR runs NTDETECT.COM.

  4. NTDETECT.COM scans the hardware in the computer and reports the list back to NTLDR for later inclusion in the HKEY_LOCAL_MACHINE \HARDWARE hive.

  5. NTLDR loads NTOSKRNL.EXE (the Kernel).

  6. NTLDR loads HAL.DLL.

  7. NTLDR loads the SYSTEM hive into RAM.

  8. NTLDR loads the drivers that are configured to load at boot time (Start value of 0). These drivers are loaded into memory, but not initialized, in the order they appear in HKEY_LOCAL_MACHINE \SYSTEM CurrentControlSet\Control\ServiceGroupOrder. During this phase, the screen is cleared and progress dots (...) are displayed across the top of the screen.

  9. NTLDR passes control to NTOSKRNL.EXE.

At this point, Windows NT enters the load sequence.

Load Sequence Files


The boot sequence concludes when NTLDR passes control to NTOSKRNL.EXE. At this point, Windows NT begins to load and initialize in three phases: the Kernel initialization phase, the services load phase, and the Windows system start phase. The process is completed when the user logs on.

Kernel Initialization Phase

During this phase the Kernel and device drivers are initialized. When the phase occurs, the screen is painted blue. After the Kernel finishes initializing itself, it initializes the drivers loaded during the boot sequence by NTLDR (Start=0). Next, the Kernel copies the CurrentControlSet to the CLONE control set. Then it creates the HARDWARE hive using the information from NTDETECT.COM.

Last, the Kernel loads and initializes drivers that are configured to start during system initialization (Start=1, such as the keyboard, mouse, video, and so on).

Services Load Phase

During the services load phase, the session manager (SMSS.EXE) is started. The session manager continues preparing the hard disk and Windows NT shell. It immediately reads and runs the list of programs in HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ BootExecute. By default, this list includes AUTOCHK.EXE, which performs a check on each disk partition.

After all the hard drive checks have been successfully performed, Session Manager sets up the pagefiles defined in HKEY_LOCAL_MACHINE SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management.

The next step of the Session Manager is to load the SOFTWARE hive of the Registry. Then it loads the required subsystems, as defined in HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ SubSystems\Required. By default, only the Win32 subsystem is required.

Last, it loads and initializes all drivers with a Start value of 2 in the Registry.

Windows Subsystem Start Phase

When the Win32 subsystem starts, it automatically starts WINLOGON.EXE, which starts the Local Security Authority (LSASS.EXE). The LSA is the central component of the Windows NT security system, and displays the CTRL+ALT+DEL logon dialog box.

Next, the Service Controller (SCREG.EXE) runs. It makes a final pass through the Registry looking for services that are marked to load automatically, such as SERVICES.EXE, which starts the Workstation and Server services. These services are loaded in the order determined by their dependencies (their DependOnGroup and/or DependOnService entries).

User Logs On

After a successful logon, the Kernel copies the CLONE control set to LastKnownGood. If a successful logon is not completed, the CLONE control set is not copied to LastKnownGood.

Note: The system does not consider the boot "good" until the CLONE control set is copied to LastKnownGood.

This is beneficial if a problem was created because of a change in the Registry, such as a manual parameter update or the addition of a faulty device driver. The user can restart the computer without logging on, and select Last Known Good during the boot sequence. This will load the previously known good control set, thus bypassing the invalid parameter or conflicting device driver.

Verifying Loaded Drivers


One method of troubleshooting a Windows NT Server computer that does not initialize all services successfully is to verify that the files required for each service are successfully loaded. Drivers are loaded in many phases of the Windows NT system initialization.

NTLDR attempts to load all drivers with a Start value of 0 during the boot sequence. During the load sequence, the Kernel attempts to initialize those drivers loaded by NTLDR, and then load all drivers with a Start value of 1. The Session Manager loads all drivers with a Start value of 2 during its processing. Device drivers with a Start value of 3 are loaded as required by services as they are initializing.

The DRIVERS Resource Kit utility verifies that these drivers were successfully loaded. One method of determining if there are drivers missing from the list is to run DRIVERS.EXE on a similar computer and compare the results.

To display the list of Kernel mode drivers loaded, run DRIVERS.EXE. Following is a description of the output from running DRIVERS. The most important field is ModuleName, which is the name of the loaded driver.




The driver's file name.


The non-paged code in the image.


The initialized static data in the image.


The uninitialized static data in the image. This is data that is initialized to 0.


The size of the data that is paged.


Data not needed after initialization.


The date that the driver was linked.

The image name identifies the executable file name or process associated with the particular item.

Replacing Damaged or Missing Files


Once a missing or corrupt file such as a driver has been identified, there are three methods to replace it. Both EXPAND -R and the emergency repair process will install a new version of the file. The emergency repair process can also help identify corrupted or missing files. If the file in question is a Registry hive, the Emergency Repair disk can be used to restore the hive.

Tip If a service is behaving unpredictably, a good troubleshooting tactic is to stop and restart the service. If the problem is a missing or corrupted file, then the startup process may recognize the problem and present a meaningful error message indicating the file that is missing or corrupt.

Emergency Repair Process

The Emergency Repair process has four options to assist in isolating and replacing damaged files:

Inspect Registry Files

Prompts for replacement of each Registry file on the system. Any changes to the Registry hives SECURITY and SAM are lost, and these files are restored as they were at system installation. Changes to SOFTWARE and SYSTEM are restored as of the last update to the Emergency Repair information.

Inspect Startup Environment

This option verifies that Windows NT is an option in the Operating System Select menu. If it is not listed in the BOOT.INI file, it adds a Windows NT option for the next boot attempt.

Verify Windows NT System Files

This option identifies and offers to replace files that have been altered from their original state on the Windows NT CD. This also verifies that boot files, such as NTLDR and NTOSKRNL.EXE, are present and valid. To find out if one or more service packs need to be reinstalled, check FILES.LST on each service pack.

Inspect Boot Sector

This option verifies that the primary boot sector still references NTLDR, and updates the boot sector if it does not. This is useful if someone uses the MS-DOS® SYS.COM utility on the hard disk. The SYS.COM utility wipes out the Windows NT boot sector and replaces it with MS-DOS. Inspecting and repairing the boot sector will restore it to Windows NT, and preserve the ability to dual-boot to MS-DOS.

To begin the Emergency Repair process:

  1. With the Windows NT Setup Disk 1 in drive A, start the computer.

  2. Insert Disk 2 when prompted.

  3. Choose "R" at the Windows NT Setup Welcome Screen.

  4. Select the desired repair options and follow the prompts.


If the exact file that is missing or damaged is known, use EXPAND -R to retrieve the file from the Windows NT CD, uncompress it, and store it in the directory where it belongs.

EXPAND -R is a Windows NT command. But what if the Windows NT computer is not functioning? If the file belongs on a FAT partition, use another Windows NT computer to access and uncompress the file. Then use an MS-DOS boot disk to copy the file to the target directory.

If the target directory is on an NTFS partition, install another copy of Windows NT in a different directory or drive, and then use EXPAND -R to replace the file.


Windows NT automatically creates a REPAIR directory under SystemRoot (generally \WINNT35). Initially, the contents of the original Emergency Repair Disk are stored in this directory.

Windows NT also includes a utility, RDISK.EXE, for creating or updating an Emergency Repair Disk, or to update the Emergency Repair information stored in SystemRoot\REPAIR. Use either this disk or the REPAIR directory during the Emergency Repair process when necessary.

Important: Make frequent and consistent backup sets of all important files, including system files. A regular backup routine should include using RDISK.EXE to maintain an up-to-date Emergency Repair disk.

Section 4 Overview



At the end of this section, you will be able to:

  • Interpret blue screens.

  • Interpret common stop codes.

  • Describe and use Crashdump.

  • Describe and use DumpExam.

Interpreting Blue Screens


When Microsoft® Windows NT™ encounters a fatal error, it displays a "blue screen" with debug information. If system recovery options are enabled, the system will also generate a file containing the debug information.

Even though a blue screen looks somewhat intimidating, there is only a small amount of data that is important in determining the cause of the error. Following is a list of the information that needs to be analyzed in order to attempt problem detection:

  • The error code and parameters at the top of the screen.

  • The list of modules that have successfully loaded and initialized in the middle of the screen.

  • The list of modules that are currently on the stack at the bottom of the screen.

This information helps you determine the extent of the problem, the cause of the problem, and ultimately, how to get the system back to an operational state.

Some errors are immediately indicative of the problem, and can be resolved without the intervention of others. Some errors, however, will require Microsoft PSS assistance, and may even require a Kernel debugger to be set up for further analysis of the problem.

Reading Stop Codes


There are many different blue screens, with accompanying stop codes. Of these different codes, the most common ones are hardware errors, and some are caused by corrupted files or file systems. The stop codes are identified on the first line of the blue screen, followed by a parameter list (four hex numbers in parentheses). The stop error, parameters, and modules loaded (below the stop message), often identify the error. For example:

*** STOP: 0x0000000a (0x0000006c, 0x00000002, 0x00000001, 0x804029cc)

In this example:

  • The first parameter (0x0000006c in this example) identifies the address that was referenced improperly.

  • The second parameter (0x00000002 in this example) identifies the IRQL that was required to access the memory.

  • The third parameter (0x00000001 in this example) identifies the access as a Write (Read = 0).

  • The fourth parameter (0x804029cc in this example) identifies the instruction address that attempted to access the memory that was referenced in the first parameter.

In this case, the driver that made the call that caused the blue screen is identified at the bottom of the stop screen. The address listed in the fourth parameter should fall within the address ranges of one of the drivers in the list of modules displayed at the bottom of the stop screen.

Note: Each blue screen will have its own unique stop code and accompanying parameters. For information on blue screens, see Microsoft TechNet.

Common Stop Codes


The following table lists the most common Stop Codes as identified by Microsoft PSS:

Stop Code





An attempt was made to access pageable memory at a process internal request level (IRQL) that was too high. A process can only access objects that have priorities (IRQL) of equal or lower priority than its own. This is usually caused by a device driver using improper addresses.



Invalid Pool Header. There are many reasons that this would appear. Debugging the system would reveal the cause.



This is a very common bug check. Usually the exception address (the second parameter) pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address.



All file system bug checks have encoded in their first ULONG the source file and the line within the source file that generated the bug check. The high 16-bits identifies the file, while the lower 16-bits identifies the source line in the file where the bug check occurred.



Something has gone terribly wrong with the Registry. It could indicate the Registry received an I/O error while attempting to read one of its files as a result of a hardware problem or file system corruption.



The requested page of kernel data could not be read in. Caused by a bad block in paging file or disk controller error. If the error is a result of a paging error, upon system restart, AUTOCHK will attempt to map out the bad block. The second parameter identifies the cause of the error:
0xC000009A indicates a lack of non-paged pool resources.
0xC000009C and 0xC000016A both indicate a back block on the drive, while 0xC0000185 indicates improper termination of a SCSI device, bad SCSI cabling, or two devices attempting to use the same IRQ.






Unable to access boot device. Often, this indicates a disk controller configuration problem, or error in accessing the hard disk. Other possible causes include the following: during initialization of the I/O system, the driver for the boot device failed to initialize the boot device (device not available, SCSI error), or the file system could not recognize the data on the boot device. Also may indicate that a virus has infected the boot sector.



This means a trap occurred in privileged processor mode, and it is a trap the kernel is not allowed to have or catch. May indicate a computer RAM problem (mismatched SIMMs), a BIOS problem, or corrupted file system drivers. The first number in the bug check is the number of the trap. Consult an Intel x86 Family manual for the trap codes.



A hardware error in which HAL reports what it can identify, and directs the user to call the hardware vendor.

If the stop code indicates a problem that can be resolved locally, such as receiving a 0x0000007B INACCESSIBLE_BOOT_DEVICE error, correct the problem (such as remembering to turn on the external hard disk drive) and then restart the computer to verify the resolution. If the error cannot be resolved easily, using a Kernel debugger may help isolate the problem.

Note: For a more complete listing of stop codes, see Chapter 4, "Message Reference," of Windows NT References in the Windows NT Resource Kit.



Occasionally, it is not possible for Microsoft PSS to resolve a problem over the phone by communicating with someone on-site at the failing computer. In a severe event such as this, establish a Kernel debugger session using Microsoft Windows NT Remote Access Service. If that is not possible because of lack of hardware, proper phone lines, and so on, it may be necessary to create a Crashdump file of the blue screen and stop code.

Crashdump is the preferred method for blue screen debugging because it ensures that a mission-critical system will be brought back online as quickly as possible. This utility captures the contents of memory when a blue screen occurs and produces a file that can be analyzed by Microsoft PSS to determine the cause of the problem.

Once the dump file has been created, the file can be made available to Microsoft PSS either by sending the file to Microsoft or by preparing a RAS connection for Microsoft PSS to dial in and view the file contents remotely. This file can be submitted to Microsoft using the Internet by connecting to, and copying the file to /transfer/incoming/bussys/winnt.

To properly support Crashdump, the follow requirements must be met:

  • Recovery must be enabled in Control Panel, System, Recovery by selecting Write Debugging Information To: and specifying a file name to save the crash information to. This defaults to %SystemRoot%\MEMORY.DMP.

  • The paging file must be resident on the system drive and must be at least 1 MB larger than physical RAM.

  • The system drive must contain free disk space that is at least the size of the paging file.

Optionally, the following may be selected in Control Panel, System, Recovery:

  • Overwrite Any Existing File

  • Write An Event To The System Log and/or Send An Administrative Alert

  • Automatically Reboot

If Recovery is properly configured when a Stop message occurs, the following events happen:

  • The system automatically dumps the RAM contents to the pagefile.

  • The computer is automatically restarted (if designated in Control Panel).

  • The pagefile contents are written to %SystemRoot%\MEMORY.DMP.

Note: The writing to MEMORY.DMP may take a while to complete depending on the size of PAGEFILE.SYS on the computer. It is important to let it complete uninterrupted. The best way to verify that it has completed is to have selected either "Write An Event To The System Log" or "Send An Administrative Alert," and then waiting for the appropriate notification, either by an event in Event Viewer or an Administrative alert message.



Once a MEMORY.DMP file has been generated, Microsoft PSS needs to analyze it. One problem with providing this file to PSS is its size, because it will be at least the size of the physical RAM in the computer. However the size of the file, and the time required to identify the problem can be reduced.

While Microsoft PSS prefers to receive the whole memory dump file, the Windows NT 3.51 utility DUMPEXAM.EXE is a command-line utility that examines a MEMORY.DMP file, extracts information from it, and creates a text file from the information. The file created, MEMORY.TXT, will be significantly smaller than MEMORY.DMP. For example, a sample MEMORY.DMP file of 16,379,904 bytes was extracted to a MEMORY.TXT file of only 49,605 bytes. Often, enough information is provided in MEMORY.TXT that PSS does not require access to MEMORY.DMP.

Three files are required to run DumpExam, and they all must be in the same directory. They are located in the \SUPPORT\DEBUG\platform directory (where platform is I386, ALPHA, MIPS, or PPC) of the Windows NT Server CD. The first two files are:



The third file is dependent on the platform of the computer on which the dump file was generated. For example, KDEXTX86.DLL is required for an I386 computer.

The syntax for DUMPEXAM is as follows:

dumpexam [options] [CrashDumpFile]

The options for DUMPEXAM are described in the following table.




Displays the command syntax.


Specifies verbose mode.


Prints the header only.

-f filename

Specifies the output file name. Required only if the dump file is not located in %SystemRoot%, or the name is not MEMORY.DMP.

-y path

Sets the symbol search path.

Run DUMPEXAM with no parameters if:

  • No hot fixes or service packs have been applied to Windows NT Server 3.51.

  • The memory dump file is in the location specified in the Recovery dialog box in the System option in Control Panel.

This creates a text file called MEMORY.TXT. It is located in the same directory as the MEMORY.DMP file that contains information extracted from the dump file.

If hot fixes or service packs are installed, specify the symbol search path using the -y option. The symbol path for DUMPEXAM can contain several directories separated by semicolons (;). These directories are searched in the order in which they are listed, so list directories with the most recently installed hot fixes or service packs first.