Chapter 7 - Troubleshooting

Article
02/20/2014

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.

By Dennis Maione

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.

Chapter 7 from MCSE Training Guide : Windows NT Workstation 4, Second Edition, published by New Riders Publishing

Microsoft provides the following objectives for "Troubleshooting":

Choose the appropriate course of action to take when the boot process fails.

This objective is necessary because someone certified in the use of Windows NT Workstation technology must understand the NT boot process and be able to troubleshoot and resolve problems that occur when booting. This includes configuration problems and boot failures resulting from hardware problems.

Choose the appropriate course of action to take when a print job fails.

This objective is necessary because someone certified in the use of Windows NT Workstation technology must understand the NT print process and architecture and be able to troubleshoot and resolve problems relating to printing. This includes configuration of printers as well as resource access problems.

Choose the appropriate course of action to take when the installation process fails.

This objective is necessary because someone certified in the use of Windows NT Workstation technology must understand the process of installing Windows NT Workstation and be able to troubleshoot and resolve problems that occur in the installation process. This includes faulty media, problems with hardware configuration, and failure of automation.

Choose the appropriate course of action to take when an application fails.

This objective is necessary because someone certified in the use of Windows NT Workstation technology must understand the subsystems involved in running applications and be able to troubleshoot and resolve problems that occur when executing applications. This includes configuring subsystems and execution priority.

Choose the appropriate course of action to take when a user cannot access a resource.

This objective is necessary because someone certified in the use of Windows NT Workstation technology must understand security and connectivity in Windows NT and be able to resolve problems that prevent resource access. This includes password, sharing, and permission problems.

Modify the Registry using the appropriate tool.

This objective is necessary because someone certified in the use of Windows NT Workstation technology must understand the NT Registry and the tools that can be used to modify it. These include the Control Panel, REGEDIT.EXE, and REGEDT32.EXE.

Implement advanced techniques to resolve various problems.

This objective is necessary because someone certified in the use of Windows NT Workstation technology must understand all facets of NT and be able to use all resources at his or her disposal to solve any problems that occur. These include monitors and logs.

This chapter will help you prepare for the "Troubleshooting" section of Microsoft's Exam 70-73 by introducing you to a variety of troubleshooting techniques. These techniques cover problems relating to booting, printing, installation, application execution, and resource access.

In a poll that Microsoft conducted among troubleshooters to determine what made for successful troubleshooting, more than half of the troubleshooting successes could be related to experience—either with the computer system or with the specific problem. This indicates that the best knowledge to have is knowledge of how the system works and what problems you might face. Just as bank tellers are trained not on how to spot counterfeit money but on how to spot the real stuff, you should focus most of your attention not on what might go wrong and how to fix it but on how a good working Windows NT Server looks. In this way, you will be able to more easily detect a problem and determine its cause.
Troubleshooting questions on the Windows NT Server exam are rarely as straightforward as, "You are troubleshooting a problem with RAS…." Instead, a need for troubleshooting is implied in scenario questions, and you will have to put your troubleshooting skills to work to figure out what is the best course of action. Scenario questions on the Windows NT Server exam are often worded so as to confuse you into thinking a particular piece of information is important when it is not. Become familiar with working systems, and when you are familiar, you will instantly know if something is wrong (like the bank teller who handles a piece of counterfeit money after thousands of real bills have passed through her hands). Then your experience and instincts will tell you where to go to solve the problem.
Having said all that, you still must have a good methodology for troubleshooting, and you must know what kinds of problems are likely to crop up both in a production environment and on the exam. Become very familiar with the categories of troubleshooting covered in this chapter and understand the problems that might arise from incorrect configuration or system failure. Also know what solutions make the most sense in a given situation.

Introduction
General Troubleshooting Techniques
Assessing Boot Process Failures
Assessing Print Job Failures
Assessing Installation Failures
Assessing Application Failures
Assessing User Resource Access Failures
Modifying the Registry
Using Advanced Techniques
Exercises
Review Questions
Exam Questions
Answers to Review Questions
Answers to Exam Questions

Introduction

The modern digital computer contains numerous components that interact with one another: both hardware and software. The potential for malfunctions, a poorly performing system, and general system failure always exists. The key to successful troubleshooting is to isolate the component or module responsible for the trouble, fix or modify the problem, and test the results. Often the issue at hand isn't easily isolated and may not arise out of one simple factor. Catastrophic failure is the easiest problem to fix, because the problem is always there to be analyzed. The intermittent problems are the most troublesome—and challenging.

The best weapon any professional can have in his or her arsenal when attempting to troubleshoot a system problem is the knowledge of how the underlying system is supposed to work. With that knowledge, and using the various diagnostic tools that Microsoft includes with Windows NT Workstation 4.0, you can fix many if not all of the common problems you encounter.

This chapter builds on the information you learned in Chapter 6, "Monitoring and Optimization," using many of the same tools and techniques. The basic difference between the information presented in that chapter and in this one is that problems discussed in this chapter are essentially showstoppers that require you to find a solution so your client can proceed to his additional work.

General Troubleshooting Techniques

Microsoft presents a basic troubleshooting model that it identifies using the acronym DETECT. The letters in DETECT stand for the words Discover, Explore, Track, Execute, Check, and Tie-up. The following list outlines the DETECT troubleshooting model.

Discover the problem. Talk to users and look at the systems in question to determine what the problem is. Find out what software is running and what versions of operating systems and service packs are being used. Gather as much information as you can to figure out what the real problem is. It may take a lot of work to go from point A when the user says, "My computer won't work" to point B when you discover that the user has been receiving a message indicating the primary domain controller could not be located.
Explore the boundaries. Determine the scope of the problem and whether it is reproducible. Does it happen only at specific times of the day? Is other software running when it happens? Is the same problem occurring in other locations on your site? And does TechNet record the problem as common and solvable?
Track the possible approaches. Brainstorm—either alone or with others—to determine the possible approaches to solving the problem. Include solutions that have been tried in the past (especially if they have been successful).
Execute an approach. Implement the approach that you determine is most likely to succeed. Don't forget to consider possible problems that might occur and take steps to avoid making the problem worse. If it is possible that some working system might be rendered inoperable by your changes, back up the data or disconnect it from the network. Be sure to make copies of all the files you propose to change, especially the Registry.
Check for success. Determine if your solution worked, and consider whether the solution is permanent or whether the system is likely to return to the problem state. If it is likely to reoccur, will the same fix work again, and can a user implement it him- or herself?
Tie up loose ends. Document your successes and failures as you work through the problem. Then gather the notes you made during the brainstorming and implementation of your solution so that you will have them for similar solutions. If you feel that the solution you used was not the best (even though it resulted in a successful repair), be sure to document that so you can try another solution next time. Also be sure that the user who placed the call (if it was someone other than you who discovered the problem) is satisfied that the problem is resolved; this will instill confidence in you and in your systems.

What follows are a number of sections in which specific problems are discussed. Be sure to keep in mind that the information presented really only helps you with the exploration and tracking stages of the troubleshooting model. The rest must be up to you to work out in the situations in which you find yourself.

Assessing Boot Process Failures

Choose the appropriate course of action to take when the boot process fails.

When you know that your workstation's hardware is functioning correctly, Windows NT Workstation's failure to start up properly and load the Windows NT shell may be a boot process problem. The key to solving problems of this type is to understand the logical sequence that your workstation uses when starting up. Windows NT shows you various boot sequence errors, the meaning of which should help you determine the problem with your system. You can also diagnose the BOOT.INI file to determine the nature of any potential problems, and you can use your emergency repair disks to boot your system and repair common boot process failure problems.

A boot failure is an obvious error, and one of the most common problems you will encounter. When you or your client can't start your computer, you know you have a problem. And it's the kind of problem that forces you to stop what you are doing and fix it before you can go on to further work.

The Boot Sequence

Your computer begins the boot sequence after the Power On Self Test (POST) completes itself. When you turn on the power to your computer, the first series of messages you see are hardware related and are not associated with the boot process. Your memory is tested, for example, and then your bus structure is tested. Your computer runs a series of tests. These tests signal to peripheral devices and sense their replies to check for successful I/O performance. You may see a series of messages stating that your mouse and keyboard are detected, noting the appearance of an IDE drive, indicating whether a SCSI adapter is detected, providing response from any devices on that SCSI chain, and so forth. Failure at this stage isn't a boot sequence problem.

The boot sequence initiates when the hard drive's master boot record (MBR) is read into memory and begins to load the different portions of the Windows NT operating system. Windows NT Workstation runs on different microprocessor architectures. The exact boot sequence depends on the type of microprocessor on which you have installed Windows NT Workstation.

The Windows NT Boot Process

The boot process begins when your computer accesses the hard drive's master boot record (MBR) to load Windows NT. If your system fails during the Power On Self Test (POST), the problem isn't NT-related; it is a hardware issue. What happens after the MBR program loads depends on the type of computer you are using.

The Intel Boot Sequence

Windows NT loads on an Intel x86 computer by reading a file called the NTLDR or NT Loader into memory from the boot sector of the startup or active partition on your boot drive. NTLDR is a hidden system file set to be read-only. NTLDR is located in the root folder of your system partition and can be viewed in the Windows NT Explorer when you set the View All File Type option. The NTLDR file initiates the following process:

NTLDR initializes the 32-bit flat memory model required by the Windows NT kernel to address RAM.
NTLDR initializes the minifile system driver to access the system and boot partitions.
NTLDR displays the Boot Loader menu on your monitor to provide you the choice of which operating system to use. These selections are stored in the BOOT.INI file in your systemroot directory.
After you select an operating system, a hardware detection routine is initiated. For Windows NT, the NTDETECT.COM program is responsible for this routine, and it creates a hardware list that it passes to the NTLDR program.
The operating system kernel is then loaded. The NTOSKRNL.EXE file located in the %systemroot%\System32 folder is called to load the kernel of Windows NT. The menu is replaced by the OS Loader V4.00 screen.
A blue screen appears while the Hardware Abstraction Layer (HAL) is being loaded. To execute this, the HAL.DLL is called with a set of routines that isolate operating system functions from I/O.
Next, the HKEYLOCALMACHINE \System hive of the Registry is read and the system is loaded. Registry hives are stored as files in the %systemroot%\System32\Config folder.
The boot time drivers HKEYLOCALMACHINE \System CurrentControlSet\Control\ServiceGroupOrder are loaded. For each driver that's loaded, a dot is added to the OS Loader screen.
The list of supported hardware devices is handed off from NTDETECT.COM to NTOSKRNL.EXE.
After NTOSKRNL.EXE executes, the computer's boot phase finishes, and the software you have installed begins to be loaded.

The RISC Boot Sequence

A RISC computer contains the NTLDR software as part of its BIOS. Therefore, the boot phase of a RISC-based computer is both simpler and faster than the boot phase of an Intel x86 computer. A RISC computer keeps its hardware configuration in its BIOS, which obviates the need for the NTDETECT.COM file. Another item kept in firmware is the list of all valid operating systems and how to access them. This means that a RISC computer doesn't use a BOOT.INI file, either.

A RISC computer boots by loading a file called OSLOADER.EXE. After reading the hardware configuration from the BIOS and executing, OSLOADER.EXE hands off the boot process to the NTOSKRNL.EXE. Then the HAL.DLL is loaded, followed by the system file, which ends the RISC Windows NT boot process.

Non-NT Operating Systems in the Boot Loader Menu If you install Windows NT Workstation over a previous installation of MS-DOS or Windows 95, the previous operating system will appear in the menu as MS-DOS or WINDOWS. When they are loaded and executed, these systems call the BOOTSECT.DOS file. BOOTSECT.DOS loads and hands off at the end of the boot process to the operating system component responsible for I/O communication. In Windows 95, that file is the

IO.SYS file.

Display Driver Names at Startup If you enter the /SOS switch in the BOOT.INI file, Windows NT will list the drivers' names in the OS Loader screen as Windows NT Workstation starts up.

BOOT.INI

NTLDR may invoke the Boot Loader menu, but BOOT.INI, an editable text file, controls it. (It is read-only, so you must remove that attribute before editing it.) BOOT.INI is the only .INI file that Windows NT uses—if, indeed, you can actually say that NT uses it. After all, Windows NT is not loaded at the time this file is called on.

BOOT.INI has only two sections: [boot loader] and [operating systems]. The [boot loader] section defines the operating system that boots by default, and the [operating systems] section defines the other operating systems that can be booted.

The BOOT.INI file contains paths to boot files for the operating systems listed in it. In NT operating systems, this path is defined in ARC format; otherwise, the path is presented as a DOS path. DOS paths, such as "C:\MSDOS," are very straightforward and require no explanation. ARC paths, on the other hand, can be very obscure in their contraction and interpretation. It is, therefore, necessary to discuss them at this point.

ARC Paths

ARC paths provide a means of defining the location of a file based on physical location—specifically, based on the controller card, physical disk, and partition on which the directory is stored. Because the drive labeled G: could be physically anywhere, the ARC path convention was adopted as the way to tell the NT boot process where the boot files are located.

An ARC path can take one of two forms:

multi(0)disk(0)rdisk(0)partition(1)\WINNT

scsi(0)disk(0)rdisk(0)partition(1)\WINNT

The first parameter (either multi or scsi) identifies the physical number of the controller being referenced, starting from 0 and counting up from there. If multi is used, it indicates either a non-scsi controller or a scsi controller with its BIOS enabled. If scsi is used, it indicates a scsi controller with its BIOS disabled.

The second and third parameters (disk and rdisk) are really a set of alternatives: Only one is used in any circumstance. Both the disk and rdisk parameters indicate the physical disk (associated with the controller indicated in the previous parameter). If the first parameter is multi, the disk parameter is ignored and the rdisk parameter is used. If the first parameter is scsi, the disk parameter is used and the rdisk parameter is ignored. Like the controller parameter, the counter associated with the hard disk parameter begins at 0 and increments from there.

The fourth parameter (partition) indicates the partition on the disk specified in either the second or the third parameter. Unlike the first three parameters, the counter for the partition begins at 1 and increments from there.

The final parameter is the path on the partition described in which the NT boot files are located. This path is frequently (but not always) WINNT.

The ARC path of each NT installation on any given computer is automatically placed into the BOOT.INI file in the system partition. If nothing ever changes on your server, you will never have to manipulate that file. However, if new partitions are created on your hard drives or if new hard drives or disk controllers are installed, the ARC paths might need to be updated.

ARC paths are based on physical configuration of your computer. When the configuration changes, the ARC paths in your BOOT.INI file are not automatically modified. As a result, some changes will render your system unbootable. This will not prevent NT from functioning properly after it is booted; however, it may prevent it from starting properly. In order to understand this, you need to understand how ARC numbers are assigned to partitions.

When you create a new partition using the Disk Administrator, the ARC numbers assigned to the partitions are re-evaluated. The numbers are generated according to the following pattern:

The first primary partition on each disk gets the number 1.
Each additional primary partition is then given a number, incrementing up from 1.
Each logical drive is then given a number in the order they appear in the Disk Administrator.

For example, suppose you have a hard drive partitioned like the one shown in Figure 7.1.

As you can see, a primary partition contains the system and boot information for NT Server, and the first logical drive contains the boot files for NT Workstation. All is well until you create a new primary partition in the free space on the hard drive (see Figure 7.2).

When you create the new primary partition, that partition gets the number which is one more than the first primary partition; in this case, the new partition is now the number 2. This makes the partition with the Workstation files number 3. Unfortunately, because the BOOT.INI file still thinks it is to go to partition 2, when you choose Workstation from the boot list, the boot fails and you see this message:

Windows NT could not start because the following file is missing or corrupt

<winntroot>\system32\ntoskrnl.exe

Please reinstall a copy of the above file

To resolve this problem, you have three options:

You can boot to an operating system that will still start (in this case, NT Server will still boot) and then change the BOOT.INI file from there.

Figure 7.1: In the original configuration, the Workstation boot files are stored on partition 2.

Figure 7.2: In the new configuration, the Workstation boot files are stored on partition 3 because the new primary partition is now partition 2.
You can boot from a recovery disk that has the correct BOOT.INI file and then modify the BOOT.INI file from within Workstation. (See "Boot Disk Recovery" for more information on creating a recovery disk.) This method is often used on a system that has only one operating system to boot.
If your system partition is formatted FAT, you can boot to DOS, use the attrib command with the –h –r –s switches to make it modifiable, edit BOOT.INI from DOS, and then reboot.

The [boot loader] Section

The [boot loader] section of BOOT.INI defines the operating system that will be loaded if the user doesn't make a selection within a defined period of time. By default, you see something like this:

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINNT

The timeout parameter is the length of time (in seconds) that NTLDR has to wait for the user to make a decision. If timeout is set to 0, the default operating system loads immediately. If it is set to –1, the menu remains onscreen until the user makes a decision.

The default parameter defines the actual path, in ARC-compliant form, to the directory that contains the files for the default operating system—which usually is the last operating system installed, unless someone has changed this entry. The easiest way to change the default operating system and the timeout setting is by using the Control Panel's System application.

Step by Step

7.1 Changing the Operating System That Boots by Default

Open the Control Panel and double-click the System icon.
Click the Startup/Shutdown tab to display that page of settings (see Figure 7.3).

Do Not Ignore Messages in Disk Administrator The NT Disk Administrator will not change your BOOT.INI file. However, if you create a partition in the NT Disk Administrator that necessitates the modification of the BOOT.INI file, a message will inform you of that. Do not ignore those messages because you may leave your NT Server unbootable. Although the solution to this boot problem is relatively simple, if you do not recognize the problem immediately, you might become frustrated and might reinstall NT unnecessarily.
From the Startup pull-down list, choose the operating system you want to boot by default.
If desired, modify the Show List For field to specify how long the system should wait before booting the default operating system automatically.
Click the OK button to write the changes to the BOOT.INI file.

Step by Step 7.1 outlines the preferred method of modifying the BOOT.INI file. You can edit BOOT.INI directly, but remember that a mistyped character in NOTEPAD.EXE or EDIT.COM could prevent your system from booting properly.

The [operating systems] Section

The [operating systems] section contains a reference for every operating system available to the user from the Boot Loader menu, as well as any special switches necessary to customize the Windows NT environment. One of these entries must match the default= entry in the [boot loader] section. Otherwise, you end up with two entries onscreen for the same OS, one of which has "(default)" after it. In all likelihood, only one of these will work. Trial-and-error should quickly discern which one.

Note that the paths are in ARC format with a label in quotation marks, which displays as an onscreen selection. Here's an example of an [operating systems] section:

multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Workstation ~Version 4.00"

multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Workstation ~Version 4.00 [VGA mode]" /basevideo /sos

c:\="Windows 95"

This example shows two entries for the same Windows NT Workstation installation, but the second one includes two switches (/basevideo and /sos) that customize the Windows NT boot and load process. These and other BOOT.INI switches are covered in the next section.

Figure 7.3: You can change the default operating system on the Startup/Shutdown tab in the System Properties dialog box.

BOOT.INI Switches

This section describes several useful switches you can include in the [operating systems] section of BOOT.INI. The only way to include a switch is to manually edit the BOOT.INI file. If you decide to do so, be sure to remove the read-only attribute from the file before editing it, and be sure that you save the altered file as a text file if you use a word processor that normally saves in another format.

Here are the available switches:

/basevideo The /basevideo switch tells Windows NT to load the standard VGA driver instead of the optimized driver written for your video card, which is useful, for example, if your monitor breaks and is replaced by one that doesn't support the same resolution or refresh rate that your last one did. If you can't see, it is awfully hard to get into Control Panel to change the video settings. Selecting the VGA mode entry uses the standard VGA 640¥480, 16-color driver that works with almost every monitor.
/sos The /sos switch enumerates to the screen each driver as it loads during the kernel load phase. If Windows NT hangs during this phase, you can use the /sos switch to determine which driver caused the problem.
/noserialmice=[COMx|COMx,y,z] When Windows NT boots, NTDETECT.COM looks for, among other things, the presence of serial mice. Sometimes this detection routine misfires and identifies modems or other devices as serial mice. Then, when Windows NT loads and initializes, the serial port is unavailable and the device is unusable because Windows NT is expecting a serial mouse. In other instances, the serial mouse detection signal can shut down a UPS connected to the serial port.

By itself, the /noserialmice switch tells NTDETECT.COM not to bother looking for serial mice. Used with a specific COM port(s), NTDETECT.COM still looks for serial mice, but not on the port(s) specified.
/crashdebug The /crashdebug switch turns on the Automatic Recovery and Restart feature, which you can also configure using the Control Panel's System application. In fact, when you configure this feature through Control Panel, what you are doing is merely adding this switch to the OS path in BOOT.INI.
/nodebug Programmers often use a special version of Windows NT that includes debugging symbols useful for tracking down problems in code. This version of Windows NT runs slowly compared to the retail version, owing to the extra overhead in tracking every piece of executing code. To turn off the monitoring in this version of NT, add the /nodebug switch to the OS path in BOOT.INI.
/maxmem:n Memory parity errors can be notoriously difficult to isolate. The /maxmem switch helps. When followed with a numeric value, this switch limits Windows NT's usable memory to the amount specified in the switch. This switch also is useful for developers using high-level workstations, who want to simulate performance on a lower-level machine.
/scsiordinal:n If your system has two identical SCSI controllers, you need a way to distinguish one from the other. The /scsiordinal switch is used to assign a value of 0 to the first controller and 1 to the second.

An example of the use of some of these switches appears in the [VGA] BOOT.INI choice. This choice allows you to boot with a generic video driver to repair a video configuration failure. In the case of that boot choice, the following example BOOT.INI line could accomplish it:

multi(0)disk(0)rdisk(0)partition(1)\WINNT=

"Windows NT Workstation ~Version 4.00 [VGA mode]" /basevideo /sos

This line uses the /basevideo switch to ensure that generic video drivers are used, and it also uses the /sos switch to enumerate the drivers as they load. This line is created by default by the Windows NT installation process whenever NT is installed on a computer.

The Load Process

After the boot portion of the operating system loads, your device drivers are loaded, and the boot process is handed off to the operating system kernel. In Windows NT, this portion of the startup occurs when the screen turns a blue color and the text shrinks. At that point, the kernel is initializing. The operating system begins to read various hives in the Windows NT Registry. One of the first hives read is the CurrentControlSet, which is copied to the CloneControlSet, and from which a HARDWARE key is written to RAM. The System hive is read to determine whether any other drivers need to be loaded into RAM and initialized. When that is complete, the kernel initialization phase ends.

The Session Manager then reads the System hive in the Registry to determine which programs need to run before Windows NT itself is loaded. Typically, the AUTOCHK.EXE program (a stripped-down version of CHKDSK.EXE) runs and reads the file system.

Other programs defined in the HKEYLOCALMACHINE SYSTEM\CurrentControlSet\Control\SessionManager\BootExecute key are run, and a page file is then created in the location specified by the HKEYLOCALMACHINE \SYSTEM \CurrentControlSet Control\Session Manager\Memory Management key. The Software hive is read next, and then the Session Manager loads other required subsystems defined in the HKEYLOCALMACHINE \SYSTEM CurrentControlSet\Control\SessionManager\Subsystems\Required key. This ends the portion of the boot process in which services are loaded into RAM.

After services are loaded, the Windows WIN32 Subsystem starts to load. This is where Windows NT Workstation switches into a graphics (GUI) mode. The WinLogon module runs, and the Welcome dialog box appears. The Windows operating system is still loading at this point, but the user can enter his username, domain, and password to initiate the logon process. After the Service Controller (SERVICES.EXE) loads and initializes the Computer Browser, Workstation, Server, Spooler, and other services, the request for logon is passed to the domain controller for service.

The SERVICES.EXE program is a central program in the Windows NT operating system. It initializes various system DLL files. Should this file become damaged, you would have to reinstall Windows NT Workstation.

The following DLLs provide operating system services:

Alerter (alrsvc.dll). Provides messaging services and event alerts.
Computer Browser (browser.dll). Provides a way for locating resources on the network.
Use the Resource Kit Utilities for More Diagnostic Capabilities The Windows NT Resource Kit contains a more detailed description of the boot process than that presented here. That kit also contains some additional tools for determining which drivers have loaded and for performing other diagnostic functions.
EventLog (eventlog.dll). Notes and enters events into the three log files.
Messenger (msgsvc.dll). Provides interapplication communications that enable one application to communicate with another.
Net Logon (netlogon.dll). Contains the code required to request resource validation from domain servers.
NT LM Security Support Provider (ntmssos.dll). Provides security support.
Server (srvsvc.dll). Enables Windows NT Workstation to provide limited network services to other computers.
TCP/IP NetBIOS Helper (lmhsvc.dll). Handles IP address resolution.
Workstation (wkssvc.dll). Enables a Windows NT Workstation computer to access resources on the network. Workstation includes services that enable the computer to log on to a domain, to connect to shared resources such as printers and directories, and to participate in client/server applications running over the network.

LastKnownGood Recovery

The LastKnownGood configuration provides a method for recovering your previous system setup. When you create a specific configuration for Windows NT, that information is stored in your Registry in a group called a control set. The LastKnownGood control set is updated every time you log in, enabling you to recover from a hardware configuration error—provided that you use this method immediately after discovering the error on the first boot attempt and do not try to log on a second time. If you log in with a hardware configuration problem, that will be recorded as part of the LastKnownGood configuration, and you will not be able to use LastKnownGood to recover in the future.

The information contained in the LastKnownGood configuration is stored in the Registry in the HKEYLOCALMACHINE \SYSTEM \CurrentControlSet key.

LastKnownGood Updated at User Logon A successful logon is considered the completion of the boot process. To mark the event, Windows NT Workstation updates the LastKnownGood control set key in the Registry with information about what was loaded and the current system configuration at startup.

Step by Step

7.2 Invoking the LastKnownGood Configuration

Reboot your system.
When a message appears asking you whether you want to boot the LastKnownGood configuration, press the spacebar.
From the Hardware Profile/Configuration Recovery menu, select a hardware profile. Then press the L key for the LastKnownGood configuration.

If a critical system error is encountered, Windows NT Workstation might default to the LastKnownGood configuration of its own accord. This isn't always true, but it is a frequent occurrence. Should basic operating system files be damaged, however, you cannot use the LastKnownGood configuration; instead, you must boot up using a boot floppy and then recover your system as described in the next few sections.

Boot Sequence Errors

The most common boot sequence errors occur when the operating system components required for the boot process cannot be found or are corrupted. Often a modification to the BOOT.INI file leads to a failure to boot properly. If you or your client has recently made a modification to the startup files, you should suspect that to be the problem first.

Catastrophic hardware failure is not a common problem, but it does happen—particularly in older equipment. If a hard drive stops operating, it is obvious because your computer sounds different. Also, when you open the case of the computer and listen to it, you won't hear the hard drive spin up and achieve its operating speed.

Much less obvious are hardware errors that prevent your system from starting but don't appear to alter the performance of your system noticeably. If your hard drive develops a bad disk sector and that sector contains the operating system components responsible for booting your computer, for example, the computer will appear to function correctly. This particular problem can be solved by reestablishing the boot files on another portion of your hard drive.

Certain error messages appear when there is a problem with the BOOT.INI file. If you get one of these error messages and the Windows shell doesn't load, you should suspect the BOOT.INI file and use a boot disk or an emergency repair disk (ERD) to repair the BOOT.INI file. (You will learn how to create an ERD later in this chapter.)

This message indicates that the Windows NT Loader file is either damaged or corrupted:

BOOT: Couldn't find NTLDR

Please insert another disk

Typically, the error with the NTLDR file occurs early in the boot process.

If you see a repeated sequence of error messages indicating that Windows NT Workstation is checking hardware, there is a problem with the NTDETECT.COM file. Those messages look like this:

NTDETECT V1.0 Checking Hardware...

It is possible for Windows NT to load even if the BOOT.INI file is missing. If that is the case, the NTLDR instructs Windows NT to start loading files it finds in the <default>\WINNT folder. If the operating system was installed in another location, an error message will appear, indicating that the NTOSKRNL.EXE file is missing or corrupt. The following error message appears when the BOOT.INI file is damaged or when it points to a location that no longer contains the Windows NT Workstation operating system files:

Windows NT could not start because the following file is missing or corrupt:

\<winnt root>\system32\ntoskrnl.exe

Please re-install a copy of the above file.

This message indicates that the Windows NT operating system kernel has failed to load. The problem most often occurs when someone has inadvertently renamed the folder containing the operating system files without realizing the consequences of that action. The solution is to use your boot disk to gain access to the system and then to rename the folder back to the location specified in the BOOT.INI file. It is less common to see a change in the BOOT.INI file giving rise to this problem because that requires a knowledgeable user's action.

Another potential reason the kernel might not have loaded is that you used the Disk Administrator to create a partition with free space. If you change the number of the partition that contains your Windows NT operating system files, the pointer in the BOOT.INI file will no longer point to the correct location. To fix this problem, you need to edit the pointer and correct the partition number so that BOOT.INI can locate your Windows NT operating system files.

When there is a problem with the boot sector, the following error message appears during startup:

I/O Error accessing boot sector file

Multi(0)disk(0)rdisk(0)partition(1):\bootsect.dos

This error message may indicate a problem with your hard drive. You should boot from a boot disk and run the RDISK utility.

Windows NT Workstation also posts a more specific message when it can determine that the error in locating the boot sector is hardware related. The operating system checks hardware (as you learned earlier) by testing it during startup. A lack of response to one of those tests generates the following message:

OS Loader V4.00

Windows NT could not start because of a computer disk hardware configuration problem.

Could not read from the selected boot disk. Check boot path and disk hardware.

Please check the Windows NT™ documentation about hardware disk configuration and your hardware reference manuals for additional information.

The preceding message might indicate that the pointer in the BOOT.INI file that should locate the Windows NT operating system actually references a damaged or nonexistent device. Or it might mean that the specified partition doesn't contain a file system that Windows NT can access with the boot loader.

Finally, you may see a STOP error if the Windows NT Loader cannot resolve the appropriate partition that contains your operating system files. This error takes the following form:

STOP: 0x000007E: Inaccessible Boot Device

This error appears when the hard disk controller has difficulty determining which is the boot device—which might happen if your computer contains an Adaptec SCSI disk controller, for example, and there is an ID number conflict. Another instance in which this error occurs is when the master boot record (MBR) is corrupted by a virus or a disk error.

If your workstation has an internal IDE drive and a SCSI disk drive with an ID number set to 0, you will also see the "inaccessible boot device" error. The 0 ID number is used to specify which disk is the internal disk, and this drive conflicts with a boot partition on the IDE drive. Any bootable SCSI disks may also be booted in preference to your internal IDE drive, so you may want to make all SCSI drives nonbootable to prevent the SCSI disk controller from booting that SCSI drive. (Some disk adapters dynamically assign SCSI device numbers, but they aren't particularly common.) If the Windows NT DETECT program in the boot loader assigns the SCSI bus adapter the number 0, the reference in the BOOT.INI file to your internal IDE drive becomes inaccurate.

If your system proceeds through the load phase and boots correctly but still seems to be malfunctioning, you should check the system event log to see whether any system messages were written to the log.

The system log may display errors, warnings, or informational events that can explain the conditions leading to the anomaly you observed due to an error in the boot sequence. To view the system log, first choose Start, Programs, Administrative Tools, Event Viewer. Then select the Log menu and choose the System Log command to open the system log. Figure 7.4 shows a system log listing various events.

Figure 7.4:

Boot Disk Recovery

If your hard disk system partition or the files become corrupted, you can start the system from a floppy disk provided you have a recovery disk available and that the boot partition is still intact. After you start your system using the floppy disk, Windows NT will run as normal, and you will be able to repair boot problems.

SCSI Preferred over IDE As a general rule, SCSI drives are faster than IDE drives and are preferred by the operating system. Don't mix and match these two drive types. If you have a SCSI disk controller and SCSI drives, use those to store your boot partition.

Most computers default to trying the floppy drive as the primary boot device, and then they move to the hard drive should the floppy drive fail. If your computer is configured to start from the hard drive, you must change this in your computer's BIOS setup. Press the keystroke displayed in the startup sequence to open your computer's setup. Then change the boot sequence so it will start from the floppy drive before attempting to boot from a recovery disk. If your Windows NT Workstation computer does not have a floppy drive, you will not be able to use this recovery feature.

A recovery disk contains the same files that are stored on the system partition of your hard disk—the ones that initiate and control the startup process.

Step by Step

7.3 Creating a Recovery Disk

Format a floppy disk from within Windows NT. This first step is important because a disk formatted from any other operating system will not boot Windows NT.

For Intel-based servers, copy the following files onto the disk:
1. NTLDR
2. NTDETECT.COM
3. BOOT.INI
4. BOOTSECT.DOS (if you want to be able to boot to DOS)
5. NTBOOTDD.SYS (for SCSI disks without SCSI BIOS enabled)
  
  For RISC-based servers, copy the following files onto the disk:
6. OSLOADER.EXE
7. HAL.DLL
8. *.PAL from System partition (for ALPHA-based servers)
Modify the BOOT.INI file for the server for which you are creating the boot disk.
Test the disk by inserting it into the floppy drive of the machine in which it is to be used and rebooting. If all is well, the disk should initiate boot, and then Windows NT should load normally.

The Emergency Repair Process

The installation process enables you to create an emergency repair directory and emergency repair disk, both of which are backup copies of Registry information (which come in handy if you can't boot Windows NT because of missing or corrupt files). The emergency repair process can help you fix a troubled Windows NT installation.

Emergency Repair Directory Versus Emergency Repair Disk

Installation always creates the emergency repair directory. You can find it in <winntroot>\REPAIR. You can create an emergency repair disk as well. Do you need both? Well, no, not really. The directory serves just as well as the disk unless the directory itself becomes corrupt or the drive itself dies, in which case you're stuck. The disk serves as a backup in case of an extreme emergency.

Boot Disk Files Are All Generic The files on the recovery disk are hardware specific, but unlike the Registry, none of them are installation specific. This means that, although you should create a recovery disk before a problem occurs, you could create one later from any Windows NT computer (Workstation or Server) that has the same processor platform. The only tricky part to using a recovery disk created in that way is replacing NTBOOTDD.SYS should your computer need it.

NTBOOTDD.SYS is the driver for a SCSI drive that does not have its BIOS enabled. You can obtain it by copying NTBOOTDD.SYS from another machine with the same SCSI driver or by copying it from the NT Server or Workstation CD. Be aware, however, that this file is not called NTBOOTDD.SYS; it is called by the name of the drive type on the CD. Therefore, you will have to locate the proper driver and copy it to your disk, changing its name to NTBOOTDD.SYS in the process.

Both the directory and disk are computer specific, at least in part. Although you can sometimes borrow an emergency repair disk from another computer, you generally should assume otherwise. Keep a separate emergency repair disk for each computer, and tag it with the serial number of the computer because names and locations change over time. Don't leave these disks in the hands of users. Keep them with an administrator in a secure but accessible location.

Table 7.1 lists and describes the files on the emergency repair disk.

Table 7.1 Files on the Emergency Repair Disk

File	Description
SETUP.LOG	A text file that contains the names of all the Windows NT installation files, along with checksum values for each. If any of the files on your hard drive are missing or corrupt, the emergency repair process should detect them with the aid of this hidden, system, and read-only file.
SYSTEM._	A compressed copy of the Registry's System hive. This is the Windows NT control set collection.
SAM._	A compressed copy of the Registry's SAM hive. This is the Windows NT user accounts database.
SECURITY.	A compressed copy of the Registry's Security hive. This is the Windows NT security information, which includes SAM and the security policies.
SOFTWARE.	A compressed copy of the Registry's Software hive. This hive contains all Win32 software configuration information.
DEFAULT.	A compressed copy of the system default profile.
CONFIG.NT	The VDM version of the MS-DOS CONFIG.SYS file.
AUTOEXEC.NT	The VDM version of the MS-DOS AUTOEXEC.BAT file.
NTUSER.DA	A copy of the file NTUSER.DAT (which contains user profile information) from the directory winntroot\profiles\Defaultuser.

RDISK.EXE

Both the emergency repair disk and directory are created during installation, but neither is updated automatically at any time thereafter. To update the emergency repair information, use the hidden utility RDISK.EXE. To start RDISK, choose Start, Run and type RDISK. Because RDISK.EXE is in the search path (\<winntroot>\SYSTEM32), you do not have to specify the full path. Some administrators just add the RDISK program to the Administrative Tools group.

RDISK offers two options for administrators: Update Repair Info and Create Repair Disk (see Figure 7.5). These tasks can be performed only by members of the Administrators group; everyone else will be told that the processes fail.

Update Repair Info

The Update Repair Info button updates only the emergency repair directory, although it does prompt for the creation/update of an emergency repair disk immediately following successful completion of the directory update. Always update the directory before creating the disk because the disk will be created using the information in the directory.

Create Repair Disk

If the information in the repair directory is up-to-date, you may choose to create or update an emergency repair disk. You don't have to use a preformatted disk for the repair disk. RDISK formats the disk regardless.

A significant limitation of RDISK that you should definitely know about is that it will not update the DEFAULT., SECURITY, or SAM files in the repair directory (or disk). In other words, you may update your repair disk week-to-week, but none of your account changes are being backed up. To do a complete emergency repair update, you must run RDISK.EXE using the undocumented /S switch. This takes a while, especially if your account database is quite large. It is better, however, than losing all your accounts if and when disaster strikes.

Figure 7.5: The Emergency Repair Disk utility allows you to update the repair information stored in the \Repair folder and allows you to create a new repair disk based on that information.

Starting the Emergency Repair Process

Regarding the emergency repair directory and the emergency repair disk, you need to recognize that you can't boot from either or use either from within Windows NT. To actually invoke the emergency repair process, you must access the original three Windows NT Setup disks. If you don't have the original disks handy, you can generate them from the CD by using the WINNT32 command and the /OX switch. Chapter 2, "Installation and Configuration," includes more information on the WINNT32.EXE program. Because these disks are generic, any set will do, regardless of which Windows NT Server machine they were created on. In fact, you can create them from any machine that has a functioning CD-ROM drive (if you don't do it from an NT machine, however, you have to use the WINNT command instead of WINNT32).

In the installation process, you had the choice to either install Windows NT or repair an existing installation. Pressing R on this screen invokes the emergency repair process. Don't be concerned when the Setup process then continues its pace through the rest of the three setup disks. That is normal.

The emergency repair process gives you several options. You can select any or all of the options in the emergency repair menu. (The default is to undertake all repair options.) After you select your repair options, Setup attempts to locate your hard drive. When it finds your hard drive, Setup asks whether you want to use an emergency repair disk or whether you want Setup to search for your repair directory. You then encounter a series of restoration choices based on the repair options you select and the problems Setup uncovers as it analyzes your system. The next few sections discuss the emergency repair options.

Inspect Registry Files

At this point, the process gets computer-specific. If your Registry becomes corrupt, only your own emergency repair disk can save you—no one else's can. You granularly select to repair any combination of the System, Software, Default, and Security/SAM hives, and these are copied directly from the repair directory or disk. You don't need the original source CD or disks for this procedure.

NT Does Not Support an Emergency Repair That Spans More Than One Disk A large limitation for an NT implementation of any significant size is that the emergency repair information can become larger than a single disk can handle. Unfortunately, if this happens, NT will not prompt you for a second disk when creating the ERD; instead, it will abort with an error message telling you that the emergency repair disk is full. Although failure of this process is beyond the scope of the NT Workstation exam, it would be well worth your while to investigate ways to reduce the size of the total repair package that NT tries to copy to your repair disk. If you search Microsoft TechNet using the term "Emergency Repair," you will find many helpful articles.

Inspect Startup Environment

The files required to boot Windows NT were listed earlier in this chapter. If any of these files is mistakenly deleted or becomes corrupted, choose Inspect Startup Environment to repair them. You can use anyone's emergency repair disk for this option because these files are generic across all Windows NT installations (for the same platform, anyway). You do need to produce the original installation CD, however, before the repair process can replace the files.

Verify Windows NT System Files

This option often takes time, but it systematically inspects every file in the Windows NT directory tree and compares each with the checksum values in SETUP.LOG. If it determines that any files are missing or corrupt, the repair process attempts to replace them. Again, you need the original disks or CD when using this option.

Inspect Boot Sector

If you upgrade to a new version of DOS and suddenly find that you cannot boot to Windows NT anymore, your boot sector probably has been replaced. The MS-DOS or Windows 95 SYS command is notorious for trashing the Windows NT boot sector. The emergency repair disk solves this problem, and you don't even need a computer-specific ERD. You can borrow one from anybody.

Assessing Print Job Failures

Choose the appropriate course of action to take when a print job fails.

A single standardized print model under Windows replaces the individual print models of applications under MS-DOS, something more easily understood. The downside is that when problems arise, they affect your entire application suite and maybe an entire workgroup.

Keep in mind that Windows retains the older model for printing for MS-DOS applications that run in Windows NT Workstation from the command prompt. These applications require their own printer drivers to print anything other than ASCII output. If you are using WordPerfect 5.1, for example, you must have both WordPerfect and a printer driver installed. Some MS-DOS applications may require that you turn on the printer port prior to printing by using a command such as this:

NET USE LPT1: \\servername\printername

Applied Service Packs May Cause Verification to Fail If you have applied Service Packs to your Windows NT Server system, validation will fail because Service Packs often modify NT system files. The validation process checks the current system files against the files on the CD-ROM and flags them as being corrupt if they are not the same. However, sometimes files are flagged as being corrupt only because the repair process recognizes the valid changes that the Service Packs have made. You can check this by examining the FILES.LST file on each Service Pack to determine which files have been changed. If you suspect a file is corrupt, replace it, but be sure to reapply the Service Pack after your system has been repaired.

One of the benefits of Windows printing is that the operating system handles all print job output in a standardized manner, regardless of the application from which you are printing. Windows NT, being a network operating system, enables you to define network printers that are available as shared resources for other Windows NT Workstations to print to. Any client or server on a network can serve as the print server to a network printer. In addition, you can set up local printers that are not shared to other network computers, but that need to be managed by their owners.

Understanding the Windows Printing Subsystem

The printing subsystem is modular and works hand-in-hand with other subsystems to provide printing services. When a printer is local, and a print job is specified by an application, data is sent to the Graphics Device Interface (GDI) for rendering into a print job in the printer language of the print device. The GDI is a module between the printing subsystem and the application requesting the printing services. This print job is passed to the spooler, which is a .DLL. The print job is then written to disk as a temporary file so that it can survive a power outage or your computer's reboot. Print jobs can be spooled using either the RAW or the EMF printer language.

The client side of the print spooler is winspool.drv, and that driver makes a Remote Procedure Call (RPC) to the spoolss.exe server side of the spooler. When the printer is attached to the same computer, both files are located on the same computer. When the printer is attached to a Windows NT Workstation in a peer-to-peer relationship, those files are located on different computers.

Spoolss.exe calls an API that sends the print job to a router (spoolss.dll), which sends the print job to the computer with the local printer, where the localspl.dll library writes the file to disk as a spooled file. At this point, the printer is polled by localspl.dll to determine whether the spooled print job is capable of being processed by the printer, and any necessary alterations are made.

The print job is then turned over to a separator page processor and is despooled to the print monitor. The print device receives the print job and raster image processes it to a bitmap file that is then sent to the print engine to be output.

For network printers, the process is very much the same, but client requests and server services are more clearly defined and separate. The routers found in the spooler modules (winspool.drv, spoolss.exe, and spoolss.dll) are identical to those used for a local printer. A local print provider on the client localspl.dll is matched to a remote print provider on the server side (win32sp.dll for Windows print servers or nwprovau.dll for NetWare print servers). In the network printing process, the print processors and print monitors may use several different server DLLs, each one of which is required by a supported operating system.

You generally install a printer using the Add Printer Wizard that you access by choosing Start, Settings, Printers. By stepping through the wizard, you create a virtual printer with a name that you provide. You can create any number of virtual (or logical, if you will) printers that use the same physical printer for a number of purposes. If you want to print differently, to have different security schemes, or to provide different access times, you must create multiple virtual printers. You can then use the following methods of manipulating printers:

Double-click on the printer to see any spooled jobs, provided you have the privilege to do so.
Right-click on a printer to view a shortcut menu that provides several actions. You can use this menu to delete a printer that no longer exists, for example. You can use the Default Printer command to set the default printer for a Windows NT Workstation from the shortcut menu.
Right-click on a printer and select the Properties command from the shortcut menu to access the Printer Properties and modify any number of settings.

Using a Basic Error Checklist

Any number of things can go wrong when you attempt to print to a printer. In many cases, Windows NT alerts you to an error, and in some cases, Windows NT actually tells you what the error type is.

Here is a standard checklist of the most common solutions to printing problems.

If the print job spools, but it will not print, do the following:

Make sure that your printer is turned on and that all the connections are secure.
See if the paper tray is empty and needs to be refilled.
Make sure a piece of paper is not jammed in the printer.
Check the printer for an error condition that prevents print processing.

The preceding solutions are so simple that it's easy to waste time and overlook them. It is amazing how many printer problems disappear when you restart your printer. If that fails to work, restart Windows NT Workstation (that is, assuming that your printer worked before you specified the print job).

If none of these solutions seems to work, try the following:

Verify that the printer you think you printed to is either the default printer or was selected within the application from which the print job was sent.
Print a simple text file from Notepad. This often verifies whether the print problem is application-specific. Try printing from DOS to test the DOS subsystem if that is the problem environment.
Print to a different printer, or substitute another printer on the same printer port. This helps determine whether the printer is malfunctioning.
Check the amount of available hard disk space on your system partition to see whether there was room to create the temporary spooled print file.
Print to a file, and then copy that file to the printer port in question. If you can print in this manner, you should suspect the spooler or a data-transmission error. Otherwise, you are probably dealing with a hardware, device driver, or application error.

At the very worst, you can try reinstalling the printer and supplying a new or updated printer driver. These are the usual sources of printer drivers:

The Windows NT operating system distribution disks.
The setup disks that came with your printer.
The printer manufacturer's BBS or Web site.
Microsoft's technical support line. You can contact Microsoft at 206-882-8080. Microsoft's current printer driver library is on the Windows NT Driver Library disk.

If you observe the problem printing to a printer immediately after you install the printer, you should probably suspect a configuration issue. Make sure that you assigned the correct port in the Configure Port dialog box of the Add Printer Wizard. To check port settings after the fact, open a printer's Properties dialog box by right-clicking on the printer in the Printers folder and selecting Properties. In addition, you may suspect that the printer driver is incorrect, especially if you printed a test page after installation and it came out garbled. If the driver is incorrect, you can modify it from the General tab of the printer Properties dialog box.

Step by Step

7.4 Modifying Printer Configuration via the Printer Properties Dialog Box

From the Start menu, choose Settings, Printers to open the Printers dialog box.
Right-click the printer you are troubleshooting and choose Properties from the shortcut menu.
From the General tab, you can change the printer driver and print a test page.
From the Port tab, you can configure port settings or change the port to which you are printing.

Printers As Shared Resources

Network printers are shared resources. You must own the printer (have created or installed it), be an administrator, or be assigned the rights to use a printer in some way to be able to view, modify, and use a printer. Different levels of rights can be assigned by an owner or an administrator. You assign shared rights by selecting the Sharing command on a printer's shortcut menu, which brings up the Sharing tab of the Printer Properties dialog box (see Chapter 3, "Managing Resources," for a review of printer configuration and sharing).

Creating additional printer shares for the same physical printer proves useful for the following reasons:

Each share can have a different printer setup.
You can assign different access privileges to groups of users.
Each group can have different printing priorities.
You can control access to the printer at different times for each group.
You can use one share for a network printer and another share name for a local printer.

If a user cannot connect to a printer, he may not have been given the right to access that printer. An administrator will be able to view and modify printers on any Windows NT Workstation.

If you have MS-DOS clients on the network and you want them to see a printer share, you must use a file naming convention that DOS recognizes. Names can be up to eight characters long but cannot contain spaces or any of the following characters:

? * # | \ / = > < %

To hide a printer share, add a dollar sign character to the end of the share name, as in sharename$. Any printer with that kind of a name will not show up in the Connect To Printer dialog box that is one of the steps in the Add a Printer Wizard. A user must know that this printer share exists and be able to enter both the correct name and the correct path to the printer share to connect to that printer.

Solving Print Spooler Problems

Any print job spooled to a printer is written as a temporary file to the %systemroot%\System32\Spool\Printers folder. The file is deleted after the printer indicates that the job has been printed. The most common print spool problem is a lack of available disk space. If you print high-resolution graphics, you might have print jobs as large as 20MB to 80MB per file for a 32-bit image at standard page size. Not surprisingly, it doesn't take many print jobs like that to overwhelm the typical Windows NT Workstation configuration.

When you print to the spooler, two files are created for each print job: an .SPL file, which is the actual print job spool file, and an .SHD file, which is a shadow file. The shadow file contains additional information about the print job that is not part of the print job itself, such as its owner, priority, and so forth. If your computer crashes, .SPL and .SHD files remain in the default spool file until the service restarts and they are processed and printed. After they are printed, these files are deleted from disk.

You can print directly to a printer from your application by turning off the print spooling feature. Before you print, open the Scheduling tab of the Printer Properties dialog box and select the Print Directly to the Printer radio button. When the printer next becomes available, your document prints. Until that point, you cannot use the application from which you sent the print job. However, you can task switch to another application and continue working until your printing application becomes available again.

Spooler Performance Problems

You can solve spooler performance problems by increasing the priority that Windows NT Workstation assigns to the Spooler service. By default, Windows NT assigns this service a rating of 7, which is consistent with other background processes. You can increase the rating to 9 to improve the performance of the spooler to the level of a foreground operation. Only consider doing this, however, as a temporary measure to print a large print job or if your workstation is used heavily as a print server. Changing this rating permanently degrades the performance of other services and applications on the workstation.

Corrupted Spool Files Are Not Deleted Should your spooled files become corrupted, they will be orphaned and will remain in the spool folder taking up valuable space.

To change the priority of the Spooler service, open the REGEDT32 application and change the value of the PriorityClass of type REGDWORD in the following key:

HKEYLOCALMACHINE \System \CurrentControlSet \Control \Print

Set that value to the priority class required. If you enter a value of 0 or no value, NT substitutes with the default value for a background process, which is 7 for Windows NT Workstation.

Changing the Default Spool Folder

Should you run out of room on your system partition for spooled print jobs, you can specify a different default spool folder. You make such a change in the Advanced tab of the Server Properties dialog box, which you access by double-clicking on the Server icon in Control Panel.

Step by Step

7.5 Changing the Location of Spooled Documents

Create a new spool directory.
Choose Start, Settings, Printers.
Open the File menu and select the Server Properties command.
Click the Advanced tab, and then enter the location of the spool file directory.
Click OK.

Defragmentation of Hard Drives Improves Printer Performance One very simple and effective way to improve printer performance is to defragment your hard drive on a regular basis.

You may want to create the spool folder on an NTFS volume and set security for this folder. You can edit the Registry to change the value of the DefaultSpoolDirectory of type REGSZ in the following key of the Registry:

HKEYLOCALMACHINE \System \CurrentControlSet \Control \Print \Printers

After you enter the new folder and its path, save the change and restart your machine to put the change into effect. Any spooled job in the original location will be lost but will not be deleted. You must delete the TEMP file manually.

If you want to, you can assign an individual spooled folder for each virtual printer. Find your printers in the following key:

HKEYLOCALMACHINE \System \CurrentControlSet Control\Print\~Printers\printername

Then enter the folder and its path as the data in the SpoolDirectory value for that key. Again, you need to restart the workstation to effect the change.

Enabling Printer Logging

You can enable event logging for your spooler by adding a check mark to the Enable Spooler Event Logging check box on the Advanced tab. Doing so enables you to track who has used a printer, when the person used it, and what he or she requested.

Step by Step

7.6 Enabling Auditing on a Printer

Enable file and object access auditing in the User Manager.
To enable printer auditing for a specific printer share, open the Security tab of the Printer Properties dialog box and click the Auditing button.
In the Printer Auditing dialog box, click the Add button (see Figure 7.6).
In the Add Users and Groups dialog box, select a group or user to be audited.
Click OK to return to the Printer Auditing dialog box.
Select a user or group, and then click the check boxes in the Events to Audit section to track events you want to log for that particular user and group.
Click OK.

Use the Event Viewer utility in the Administrative Tools folder to view logged events.

Using the Print Troubleshooter

To help you solve printer problems, Windows NT comes with an interactive printing troubleshooter that's part of the online Help system.

Step by Step

7.7 Accessing the Print Troubleshooter

Choose the Help command from the Start menu.
Click on the Index tab, and then enter the keyword troubleshooting into the Type the Word(s) You Want to Find text box (see Figure 7.7).
Double-click on the problem type and follow the instructions in the Help system.

Printers are among the most important network resources in many organizations. Therefore, you will be called on often to solve problems that crop up with printer shares and printer hardware. This section reviewed some of the most common problems.

Figure 7.6: The Printer Auditing dialog box allows you to configure auditing to track printer use and access.

Figure 7.7: The Print Troubleshooter topic in the Help system guides you through systematic printer troubleshooting.

Figure 7.7: The Print Troubleshooter topic in the Help system guides you through systematic printer troubleshooting.

Assessing Installation Failures

Choose the appropriate course of action to take when the installation process fails.

The Windows NT Setup program makes installation errors much less common than they used to be. Several categories of errors may still occur after an installation, but they are also easier to track down and eliminate.

Installation Disk Errors and Upgrades

Infrequently, there will be a problem with the CD that you have obtained to perform the Windows NT Workstation installation. Typically, a Read error is posted; less frequently, the installation may not complete itself and you may not be able to determine why.

To obtain a replacement disk, contact Microsoft at 800-426-9400. Have your registration number handy; the sales and support staff requires it to process your request. New media requests under the warranty are generally sent without cost. If the upgrade is a slipstream upgrade, however, you may be charged postage.

A note about slipstream upgrades and Service Packs is also in order. Many small problems are often repaired as part of a minor version change in the operating system. If you have a problem related to an installation, either get the latest version of the operating system from Microsoft or download any available Service Pack from the Microsoft Web site.

Inadequate Disk Space

The Windows NT's Setup program examines the partition that you specify you want Windows NT Workstation installed in for the amount of free space it contains. If you don't have adequate free space, the installation stops and fails. At that point, you need to take corrective action to proceed with the installation.

In some respects, the Setup program is both smart and stupid. It protects your files in the Recycle Bin by not deleting them, which is wise. On the other hand, it leaves any number of .TEMP files that could be safely deleted scattered about your disk.

Download and Install the Latest Service Pack A Service Pack is a self-running program that modifies your operating system. It isn't uncommon within the lifetime of an operating system to have two or three Service Packs. As of the writing of this book, Service Pack 4 was available in Beta form for Windows NT Workstation 4.0. You should try to install the latest Service Pack because it generally solves a lot more problems than it creates.

To free up some room on your disk, consider doing any of the following:

Empty your Recycle Bin.
Delete any .TEMP files you find in the various locations they are stored in (for example, the Print Cache folder).
Delete any files you find in your Internet browser's cache folder or any other cache folder you have.
Uninstall any programs you no longer need.
Compress any files you use only on an infrequent basis.
Go into the Disk Administrator and change the size of the system partition that you want to use for your installation.
Create a new partition with adequate room for the installation.
Compress your NTFS partition to make more room.
Search for and delete all .tmp or .temp files

Several other methods enable you to reclaim or recover lost disk space, and it's possible to get really creative in this area. The methods listed here, however, are often sufficient to help you get over the crunch.

Disk Configuration Errors

If you inherit a configuration with a nonsupported SCSI device adapter, you may not be able to boot your newly installed Windows NT Workstation operating system. If that happens, boot to a different operating system and try starting WINNT on the installation CD. You can also use a network installation to try to rectify the problem. If none of these solutions works, you may be forced to replace the adapter with one recommended on the Hardware Compatibility List.

Check All Hardware Against the Latest HCL The best way to ensure that you are using hardware compatible with Windows NT Workstation is to check the Hardware Compatibility List (HCL) to see whether the device is approved for use and supported.

Inability to Connect to a Domain Controller

The error message Cannot Connect to a Domain Controller is one of the more common error messages you might see when you install Windows NT Workstation, change your hardware configuration, or change network settings. There are a number of potential solutions to this problem.

Carefully verify that you are entering the correct username and password and that the Caps Lock key is not on. The next thing you should check is to make sure that the account name you are using is listed in the User Manager for Domains on the primary domain controller. An incorrect password generates a different error message than does the lack of user account. You should also check to see whether the machine account has been added to the User Manager for the primary domain controller.

Next, open the Network Control Panel and confirm that the network bindings are properly installed on the Bindings tab. Some bindings, such as TCP/IP, require not only computer names, but also IP addresses and subnet masks. If two machines on the network have the same IP address, you get an error condition. Failure to enter the subnet mask also prevents your workstation from finding and connecting to a domain controller to get its network identity properly verified.

The failure to connect to a domain controller is a very common problem. Unfortunately, the error message isn't descriptive of the problem.

Domain Name Error

If you make a mistake selecting the domain name, you get an error message when you attempt to log on. The solution is obvious when you realize what the problem is. Just go back and select the correct domain name.

Assessing Application Failures

Choose the appropriate course of action to take when an application fails.

Unlike in MS-DOS and earlier versions of Windows, an application failure in NT Workstation won't bring your system to a complete halt. Most application failures are recoverable, and in many cases, you won't even need to reboot your computer to re-establish a working configuration. That is not to say that a system crash is impossible—it just happens very infrequently.

Most often the worst actors are applications written for MS-DOS or 16-bit Windows applications. These programs tend to crash more frequently than do 32-bit Windows applications (which is a good reason to upgrade).

When an application malfunctions, bring up the Task Manager and shut the process down. You can access the Task Manager by using either your keyboard or your mouse (which is useful in case either is hung up by the malfunction).

Step by Step

7.8 Closing an Application Using Your Keyboard

Press Ctrl+Alt+Delete to open the Windows NT Security dialog box.
Press the Tab key repeatedly until the Task Manager button is selected, and then press Enter to open the Task Manager.
Press the Tab key until one of the tabs at the top of the dialog box is selected, and then use the right or left arrow key to move to the Applications tab (see Figure 7.8).
Tab into the applications list and use the up and down arrow keys to select the offending application.
Press Tab until the End Task button is selected, and then press Enter to shut down the application.
Press Alt+F+X to exit the Task Manager.

Figure 7.8: The Applications tab of the Task Manager allows you to terminate unresponsive applications.

If your keyboard is unresponsive or if you just prefer to use your mouse, you can close an unresponsive application using the mouse.

Step by Step

7.9 Closing an Application Using Your Mouse

Right-click the taskbar and choose Task Manager from the menu that appears.
Click the Applications tab, and then select the application you want to terminate.
Click the End Task button to shut down the task.
Choose the File, Exit Task Manager command to close the Task Manager.

Using the Application Log

Many errors are logged into the Application log for native Windows NT applications. The developer of the application determines the events that are logged, their codes, and meanings. Often an application's manual or online Help system documents what events will appear in the Application log, as well as your ability to control the events that are noted.

Service Failures

Some applications run as services on Windows NT Workstation. Internet Information Server's three tools (WWW, FTP, and Gopher), for example, are all services. Services are started, stopped, and paused either from within their central administrative tool (for IIS that tool is the Internet Service Manager) or from within the Services Control Panel. If you want to configure a service so that it runs automatically when your workstation boots, more often than not you will set this from the Services application in Control Panel.

Sooner or later, though it's sad to say, you will see the following infamous error message when your Windows NT Workstation starts up after the load phase:

One or more services failed to start. Please see the Event Viewer for details.

When you open the Event Viewer, you will be able to analyze the cause of the failure or, at least, the result. Open the System log using the Event heading in the Event Viewer and look for an Event code of 6005. That code marks an informational message that indicates the EventLog service has started. Any event prior to that is a boot event and should be resolved. Double-click on an event message to view an Event Detail dialog box (see Figure 7.9).

One of the problems with the Event Viewer is the cryptic nature of its messages. Another is the fact that the messages logged often show only the result, and not the cause of a failure. For example, in Figure 7.10, you see the System log of an NT Workstation.

As you can see in Figure 7.10, this workstation has recorded three separate logon events (numbered 6005), each of which is marked by the starting of the EventLog service. Two of these were successful; however, the middle one was not. The last event recorded in the unsuccessful login was a failure in the NetLogon service; in fact, the detail indicates that a domain controller could not be located for logon validation. When that error occurred, an actual error message was displayed to the user informing him that an error had occurred. Unfortunately, a number of things could cause such an error. For example, this error could be caused by any of the following:

No domain controller is present on the network.
Although there is a domain controller, the workstation does not share a protocol with it.
The Workstation service for the NT Workstation has not been configured to start at system start.
The NetLogon service was not configured to start during startup.
The network adapter has been configured incorrectly.

Figure 7.9: The Event Detail dialog box gives you detailed information about an event in the Event Log.

Figure 7.10: The System log in the Event Viewer can be used to determine the cause of service failure.
The network adapter is broken.
The network cable is simply not connected to the computer properly (which happens to be the problem in this case).

Because many services depend on others to start properly, you can't stop at a single error and decide to fix it without first looking at the other errors that occurred in the same time frame. If you look at Figure 7.10 again, you'll see that a Service Control Manager message indicated the adapter driver didn't start because of a faulty device. Then, just before the EventLog message, you'll see two warnings about the tkxp16 device (which is the token ring adapter card on this workstation). One indicates that the adapter could not be opened; the other indicates a "lobe wire fault," which means the cable connections should be checked.

By looking through all of the error messages, you can often detect the source of the problem instead of being hung up looking at the results of the problem. Had you simply stopped at the error that said you couldn't log on, you might have spent a good deal of time trying to figure out where the domain controller in your domain was and why it wasn't responding. Unfortunately, not only are those searches frequently fruitless, but they often cause a troubleshooter to reconfigure components that were never faulty to begin with.

This illustrates the interconnected nature of services and device startup. This chapter will not even attempt to provide a detailed analysis of these interrelationships because such an analysis requires advanced knowledge of Windows NT architecture and the Registry. What can be said is that if services fail on startup, the Event Log will give you an idea where to look for solutions. Begin with the messages around the start of the Event Log because it is close to the start of NT startup. Work your way up the list to determine what failed first, and then look at what failed as a result. By seeking out the initial problem, you will be able to get to the root of the problem sooner than if you try to treat all the resulting symptoms (which may cause you much frustration and may cause you to reconfigure a service that is not in error).

Assessing User Resource Access Failures

Choose the appropriate course of action to take when a user cannot access a resource.

In order to access a resource in Windows NT, you must meet three criteria:

You must have a name and password recognized by the NT computer the resource is on.
The resource must be available to you from where you are.
You must be given permission to use the resource.

If someone is having trouble accessing a resource, any or all of the preceding could be the problem.

Usernames and Passwords

In an environment in which an NT Workstation is participating in a workgroup, a user will log on to a local NT Workstation and then access local or network resources. In order for the user to access resources on the local or network computers, the account and password combination the user logs in with must also be valid on the machine that holds the resource. This means that if a user logs in to an NT Workstation with the name Fred using a password of password and then tries to access a resource on another Workstation, that Workstation must have an account called Fred for which the password is password. Failing that, the user attempting to access the resource must be able to provide a valid name and password combination to the NT Workstation that holds the resource if he or she is challenged for such a username and password.

For example, if a user is logging in to a domain from an NT Workstation, the user must have a valid user account in the domain and must be able to provide the password for it. Assuming she supplies that information, the account she specifies must be recognized by all the machines that hold resources the user wants to access—just like in a workgroup). Fortunately, in a domain environment, most of the machines that have available resources also belong to the domain and will, therefore, recognize the user's account.

If a user cannot log on, a number of problems could be preventing it:

The user may be using an incorrect name or password.
The user's account may be disabled (by the Administrator) or locked out (because of too many incorrect passwords).
The password may have expired (which requires a password change).

The problem of an incorrect name is easily remedied: Simply have the user log on using a valid username. If one is not available, create one using User Manager. The password problem is also easily remedied: Make sure the user is using the correct capitalization for the password (remember that passwords in Windows NT are case sensitive). If that fails, you can go into the User Manager (logged in as an Administrator), reset the password to something known, and then have the user log in again.

If the user's account is disabled from the User Manager, the account can be enabled again by an administrator going into User Manager and clearing the Account Disabled check box in the user's properties. If the user's account has been locked out because of too many incorrect password attempts, the account can be unlocked by an administrator going into User Manager and clearing the Account Locked check box in the user's properties. If the account has been locked because the user forgot his or her password, you may also have to change the password to something the user knows to prevent future lockouts.

If the user's password has expired, the user simply has to change his or her password from the Login dialog box. If this is not possible, you will have to enter User Manager and reset the password from the user's account properties.

If you hear that many users are having problems with passwords expiring too frequently or lockout happening too often, you might want to change the account policy in User Manager. The account policy controls how frequently passwords expire, the lockout policy, and other password features.

Step by Step

7.10 Changing Password Options

Open the User Manager by choosing Start, Programs, Administrative Tools.
Choose the Account command from the Policies menu.
In the Account Policy dialog box, select the options you desire, and then click OK (see Figure 7.11).

The following account policy options pertain to this discussion:

Minimum and maximum password age before a password expires
The minimum length of a password
Whether blank or no character passwords are permitted
Whether a password list is maintained for an account and allows the user to cycle between passwords
How many failed attempts to log on to a given account results in an account lockout

If you use the Account Lockout feature, it is important to enter a Lockout Duration. After an account is locked for that duration, it becomes useable again and a user can again attempt to access the account.

To change your own password, you can press Ctrl+Alt+Delete and then click the Change Password button in the Windows NT Security dialog box (see Figure 7.12). The use of the Ctrl+Alt+Delete keystroke to initiate a logon or password change is meant to prevent the posting of a spoofed Password Change dialog box, that is, a program written to simulate a logon dialog box that would thereby allow a hacker to steal your user and password combination.

After the user logs on properly, the next step requirement for accessing resources is that the resource must be available on the network.

Figure 7.11: The Account Policy dialog box gives you a forum for modifying password options for all users on your Windows NT Workstation.

Figure 7.12: The Windows NT Security dialog box appears when you press the key combination Ctrl+Alt+Delete.

Resource Availability

A frequent cause of access problems is that resources are simply not available to the user over the network. Even when the user provides a username and password that the machine sharing the resource accepts, the problem of resource availability might still be present. In order for users to access a resource over the network, the following criteria must be met:

The machine holding the resource must be accessible.
The machine must be booted with the Server service started.
The resource must be shared.
Printer resources must be functioning properly.

It may seem obvious to say that the machine must be accessible, but remember that not all users understand the way networks operate. The machine must be on the same LAN segment (either physical or logical), or there must be some way to access it through a router. If a user calls to tell you that she cannot access a resource on a computer, she may not understand that when she moves a laptop from one location to another, certain resources might not be available. In addition, logical accessibility is required. The computer from which the user is trying to access a resource must be running the same protocol as the machine sharing the resource. In addition, some protocols have configuration settings that must be the same for both machines. For example, the TCP/IP addresses must share the same network address or be passed through a router. If TCP/IP addresses are configured manually, it's possible that the address has been changed by a well-meaning user who was trying to make it easier to remember the IP address of a machine.

It may also seem obvious to say that a machine must be booted. But that can also be a cause of access problems. If a machine is not booted with the operating system that is sharing the resources, the resources will not be available. Similarly, if the machine is down for maintenance or if it has crashed, it will have to be restarted or repaired before resources will be available again. In addition, if the user is attempting to access resources on an NT machine, the capability of sharing resources is dependent on having the Server service running. If it is not running, no resources will be available on the network. This can be checked from the Services dialog box (accessible by double-clicking the Services icon in the Control Panel). If the Server service is not running, you should start it. If it cannot be started, verify that the network adapter is functioning correctly and is configured correctly.

Finally, the resource must be shared. A user may be used to logging in to a specific machine and locally accessing a resource. That user is then surprised when the resource is not available elsewhere. Make sure that the resource has been shared for general use because, unlike NetWare resources, nothing is shared by default on an NT machine.

In the case of shared printers, they must have been configured properly and shared, just like files. Establishing this configuration includes making sure that the physical setup is correct, that the correct drivers have been installed, and that the print device is turned on and has paper in it.

The final stumbling block to resource access is permission to use the resource.

Resource Permissions

If a user has logged in properly and the resource is available on the network but the user cannot access it, the problem is probably related to permissions. As you learned in Chapter 3, permissions can be applied to shared resources or to local resources (provided that the resources are on volumes formatted with NTFS). If a user can see a resource in Network Neighborhood but is denied access, or if he can read a file but cannot change it, permissions are probably to blame.

Check the share-level permissions, check the NTFS permissions, and check to see if the user is part of a group that has been assigned No Access. Remember that permissions of the same type (share-level or NTFS) are cumulative for the user and all groups the user belongs to, except when one of those is No Access, in which case the user gets no access. Also remember that if share-level and NTFS permissions are both present, the least of the permissions becomes the effective permission.

Printer permissions interact the same as file permissions, and you will need to check what users and groups have what access in order to determine if a user ought to have permission to access a resource and what the access needs to be changed to if it is inappropriate.

Modifying the Registry

Modify the Registry using the appropriate tool in a given situation.

The Registry is hierarchical, and each branch is referred to as a hive. Individual sub-branches are called keys, each of which is a binary file. The top or first key of a hive is the primary key, and each key is composed of subkeys that take value entries. Most Registry entries are permanent, although some are session dependent, transient, and never written to disk. An example of a transient key is the HKEYLOCALMACHINE \Hardware, which is generated via automatic hardware detection by the Hardware Recognizer (NTDETECT.COM for Intel computers). The Hardware key is an example of a session value. Another transient value is the information written as part of a logon for a session, including security tokens.

When you install software, either a program or a part of the operating system (such as a device driver or service) writes new subkeys and value entries to the Registry. Uninstall these components to remove the information. Subkeys and value entries store information about hardware settings, driver files, and environmental variables that need to be restored—basically anything the application developer requires reference to.

Only members of the Administrators and Power Users groups can access the Registry by default. You can assign other users rights to modify all or part of the Registry by hives, but you should think long and hard before doing so. The potential to compromise security or corrupt an installation is high. By default, all users can see the Registry files, but they cannot edit, delete, or copy Registry files without specific permission to do so.

Using the Registry Editor

You use the Registry Editor to view and modify the Windows NT Registry. Of the two versions of the Registry Editor, REGEDT32.EXE and REGEDIT.EXE, the former is more generally useful and offers more options.

To discourage their casual use, Microsoft did not include these programs on the Start menu or in the Administrative Tools folder where you might expect to find them. These programs are located in the WINNT folder, but you can add them to your Start menu if you want.

Whenever you change a setting in a Control Panel application or alter your desktop, you are writing changes to the Registry associated with the user account profile with which you logged on. If you want to view and modify Registry information relating to services, resources, drivers, memory, display, or network components, you can use the Windows NT Diagnostic program (WinMSD). This utility is found in the <System Root>\System32 folder or in the Administrative Tools folder on the Programs submenu of the Start menu. When you make a change in WinMSD, you are limited in what you can alter and protected from making destructive changes.

The following list outlines the six root keys and their subtrees:

HKEYCLASSESROOT. This subtree stores OLE, file, class, and other associations that enable a program to launch when a data file is opened. Although HKEY CLASSESROOT is displayed as a root key, it is actually a subkey of HKEYLOCALMACHINE \Software.
HKEYCURRENTUSER. All user settings, profiles, environment variables, interface settings, program groups, printer connections, application preferences, and network connections for each user are stored in the subkeys of this root key.
HKEYLOCALMACHINE. This subkey contains information that identifies the computer on which the Registry is stored. Information in this key includes settings for hardware such as memory, disk drives, network adapters, and peripheral devices. Any software that supports hardware (such as device drivers, system services, system boot parameters, and other data) is also stored in this subkey.
HKEYUSERS. All data on individual user profiles is stored in this subkey. Windows NT stores local profiles in the Registry, and the values are maintained in this subkey.
HKEYCURRENTCONFIG. This key contains the current configuration for software and any machine values. Among the settings stored in this root key are display device setup and control values required to restore the configuration when the program is launched or your computer starts up.

Proceed with Caution When you alter a value in the Registry using the Registry Editor, the changes you can make are unlimited—and can be hazardous to your computer's health. If you delete or modify a required key, you could cause your computer to malfunction. The only recovery methods you can count on in that instance are reinstalling Windows NT or using the repair disk. Proceed with caution when working in the Registry, and consider wandering around with the files opened as read-only (choose the Read Only command from the Registry Editor menu) to begin with.
HKEYDYNDATA. This last key in the Windows NT Registry holds transient or dynamic data. This root key cannot be modified by the user.

When the system loads the Registry, most of the data is stored in the HKEYLOCALMACHINE and HKEYUSERS keys.

If you make a mistake and delete a key or value in the Registry Editor, you cannot use an Undo command to recover from the error. However, turning on the Confirm On Delete command on the Options menu offers a limited safeguard. But even that isn't foolproof; as everyone knows, it is easy to confirm a deletion and repent the mistake later. The only way to undo an important Registry deletion is to use the LastKnownGood configuration.

Step by Step

7.11 Reversing a Critical Deletion

Close the Registry Editor.
Immediately restart your computer.
Hold down the spacebar as Windows NT loads and select the LastKnownGood option.

When Windows NT boots your system this way, it uses the backup copy of the Windows NT Registry. Any changes you made to your system since your last startup are discarded. The LastKnownGood configuration at least enables you to recover from any critical deletion you might make in the Registry—provided that you recognize the error before you log on to your computer successfully again.

Backing Up the Registry

The most important thing you can do to protect your system's configuration is to back up the Registry files. When you create an ERD (as described earlier in this chapter), you back up specific hives of the Registry. You should keep a full backup of the Registry on hand.

The Registry files are located in the %system root%\System32\Config folder. For most installations, the %system root% is typically C:\WINNT. Individual users' Registry data is written to the NTUSER.DAT file stored in that user's folder at the location C:\WINNT\Profiles\<username>\NTUSER.DAT. When a user logs on to his workstation, a Profile folder is created for him with an NTUSER.DAT file that will hold his user profile. Roaming profiles for a domain are stored in the original copy of the NTUSER.DAT file on the domain controller.

The following CONFIG folder files store direct information on Registry hives:

DEFAULT
NTUSER.DAT
SAM
SECURITY
SOFTWARE
SYSTEM
USERDIFF
USERDIFR

Several files are associated with each Registry hive in the CONFIG folder. The first and primary file takes no extension. The CONFIG directory also contains auxiliary files for the Registry, which are the backup, log, and event files. These files have the same names as in the preceding list, but they have .LOG, .EVT, or .SAV extensions. The System file also has a SYSTEM.ALT file associated with it. The .EVT event files are viewable in the Event Viewer and contain audited events. .LOG files store changes that can be rolled back. The .SAV files are part of the LastKnownGood boot configuration that enables you to restore your Registry based on your last booted session. (The LastKnownGood option was described earlier in this chapter.)

The .LOG file is a backup file that enables changes to be rolled back. It serves as a fault-tolerance feature because changes are written to the .LOG file first. When the data is completely written in the .LOG file, the process of updating the matching Registry hive begins. First, the data section to be changed is marked, and then the data is transferred. When the data transfer is completed, the update flag is reset to indicate successful transfer. Should there be a problem or should your computer malfunction during the transfer, the update is started again from scratch.

The SYSTEM file is updated in a somewhat different manner because your computer relies on that key to start up. The duplicate SYSTEM.ALT file operates as the replacement for a .LOG file, and the entire file is mirrored and replicated. Then in the event of a crash, the backup file is used, and the entire file is replaced.

It is unnecessary to back up the entire Registry. Much of the information is transitory and session-dependent. Only specific portions of the Registry need be protected. The files of greatest importance are the SYSTEM and SOFTWARE files. They are generally small and can fit on a single floppy disk. You should also note that the SAM and SECURITY files can't be modified and cannot be copied or backed up.

To back up the Registry, use the RDISK program described earlier in this chapter and set that option. Do not try to copy the files directly to a disk. You can also back up individual hive files from within the Registry Editor by saving a branch using the Save Key command on the Registry menu. You can use the Restore Key command to load those backup files.

The hives of the Registry are locked and cannot be accessed to be copied directly. In a dual-boot system, or if you boot your system using MS-DOS or some other operating system, these files are not locked and may be copied directly. You could copy those files to another drive or volume.

You can view Registry files on a FAT volume from any other operating system. If the file system is an NTFS volume, only a Windows NT or Linux system running a disk access utility can view, read them, and copy the files. On Windows NT, one program that can do this is NTFSDOS.EXE.

For a temporary copy of a key, use the Restore Volatile command instead of the Restore Key command. Restore Volatile loads the key in the Registry Editor, but it does not load that key again in a future session after your computer reboots.

Changing the Registry Size

Normally, the default size of the Windows NT Workstation Registry is sufficient for most configurations. If you have a large organization and store a lot of user profiles and application data configurations, you may find that the Registry runs out of room. Then you may need to alter the maximum size of the Registry.

Step by step

7.12 Changing the Maximum Registry Size

Double-click the System icon in the Control Panel folder.
Click the Performance tab, and then click the Change button in the Virtual Memory section to view the Virtual Memory dialog box (see Figure 7.13).
Enter a size in the Maximum Registry Size (MB) text box, and then click OK.

The Registry size can be somewhat larger than the value entered in the System application of Control Panel. It is related to the size of your paging file, which is related to the amount of installed RAM in your system. When the Registry exceeds the size you set, it brings your system to a halt with a STOP error. This problem very rarely occurs unless you attempt to reduce the size of the Registry artificially. Keep a maximum Registry size about 2MB larger than the current size in the Virtual Memory dialog box.

Troubleshooting the Registry

Several problems may be directly related to Registry errors. The most common problems are the following:

Your computer won't boot properly or at all.
Your computer looks or works differently than it once did.
Your computer won't shut down correctly.

Figure 7.13: The Virtual Memory dialog box allows you to modify the maximum Registry size.
The "Blue Screen of Death" (resulting from a STOP error) appears.
A software or hardware component that operated correctly stops working even though no physical changes have been made to the files or to the device.
Something stops working after you add new software or hardware, and the two are not known to be incompatible.

Most of these error conditions are at least correctable from backup. The one really frightening error is the STOP error because you can't access your machine. To clear the Blue Screen of Death, try booting from your boot disk and running the CHDSK program to repair the type of errors associated with disk and file problems. The CHDSK.EXE program is located in the <System Root>\System32 directory.

Using Advanced Techniques

Implement advanced techniques to resolve various problems.

Windows NT comes with several diagnostic tools to help you optimize and tune the system and to correct error conditions. In many ways, the operating system is meant to be self-tuning and to require that relatively few settings be altered to make the computer run well. To track errors, Windows records a system of events in log files. These events can be tracked and controlled, and they prove very useful in troubleshooting. This section delves into the event logs in some detail.

To aid in solving network problems, Windows NT also offers you the Network Monitor. This utility enables you to examine and analyze network performance and utilization. Common network issues are also discussed in this section.

Working with the Event Logs and Event Viewer

Events are actions that occur on your system. The system itself generates events and records them in the System and Security log files. Applications record their events in the Application log. You see standard events, and you can audit resources to add additional events. Many application developers use the event system to aid in analysis of their application. The Event Viewer enables you to view the event logs and analyze them.

The event logs are normally viewed by anyone who cares to see the information. You can also remotely view an event log if you have the permission to do so on another machine.

An administrator may want to restrict access to these logs so that the information is secure and can't be erased. To restrict who can open the System or Application logs, you can set the following key:

HKEYLOCALMACHINE \System \CurrentControlSet \Services \EventLog-<logname>

so that the RestrictGuestAccess value of type REGDWORD is set to 1. When the RestrictGuestAccess is set to 0 or doesn't exist, the default condition is for anyone to access these two logs.

The log files are a first-in first-out (FIFO) system. When the ultimate limit of a log file is reached, the oldest events are deleted to make room for new events. The default size is 512KB, and the oldest event stored is up to one week old. You can modify these settings from within the Event Viewer.

Step by Step

7.13 Changing the Settings of the Event Logs

Open the Event Viewer (see Figure 7.14).
Choose the Log Settings command from the Log menu.
Select the log type in the Change Settings for Log list box in the Event Log Settings dialog box (see Figure 7.15).
Set the size of the log in the Maximum Log Size spinner.
Select one of the radio buttons in the Event Log Wrapping section to determine what happens to old events.
Close first the Event Log Settings dialog box and then the Event Viewer.

A prudent administrator makes a habit of checking the event logs on a regular basis. Many events occur so frequently that they can overwhelm the event logs and make it difficult to determine what other error conditions or trends exist. By analyzing the event logs, you can determine what event types are worth keeping and how often they should be noted.

Another useful option available through the Event Viewer is the export of event logs to data files. Several different output formats are offered to enable you to more easily analyze the data in the logs. You can export your log data out to text files (.TXT), event log files (.EVT), spreadsheet files (.SYLK), and database data file (.DBF) formats, among others. Numerous third-party tools help you analyze Windows NT Workstation log files.

If you want additional information about an event, double-click on the event to view the Event Detail dialog box (refer to Figure 7.9), which offers the following information for the event:

Date of event
Time of event

Figure 7.14 The Event Viewer gives you access to the three event logs.

Figure 7.15 The Event Log Settings dialog box allows you to modify the settings for any or all of the three event logs.

User account that generated the event (When applicable, this information is recorded in the Security log.)
Computer on which the event occurred
Event ID (the actual event code)
Source or component that recorded the error
Type of event: Error, Information, or Warning
Category of event
Description of event
Data describing the event in hexadecimal form

You can find many of the error messages in the documentation and resource kits for Windows NT Workstation. Microsoft also keeps a technical database that contains many reasons for which error messages are generated. You can search the Knowledge Base on the Microsoft Web site (as a premium service) or on the Microsoft network to obtain information regarding errors stored in the logs.

Another database on CD-ROM is delivered to programmers as part of their subscription to the Microsoft Developer Network program. This database contains information about not only error conditions, but internal error codes of interest to programmers. Programmers with all levels of participation in MSDN receive this database.

The Event Log is very flexible. You can turn event logging on and off for a number of resources by specifying the auditing properties for that resource. Many developers use these logs to record information specific to their applications.

The Event Log is almost an embarrassment of riches. To help you find the particular event you need, the Event Viewer offers a find and search function. You can also filter the Event Log derived from your own computer by using the View menu commands to sort by any of the following items:

Computer
Event date and time
Event ID
Event type
User
Source of the event

Know How to Use the Event Viewer The Event Viewer (like the Performance Monitor) is one of the Windows NT operating system's central diagnostic tools. Learning how to use this tool well will reward the administrator with a better running workstation, less time spent tracking down errors, and a lower-stress existence.

Network Diagnostics

Numerous network problems arise relating to both hardware and software configuration. Some of these problems require that you experiment with cabling and couplings; others can be solved with software that comes with Windows NT Workstation.

If you have a complex network installation, you may require diagnostic equipment to test your hardware. Often you can test individual components by rearranging their positions in the network (swapping cables or boards) and isolating the offending piece of hardware.

Windows NT comes with a utility called the Network Monitor that can prove very useful in diagnosing network activity. This Administrative Tools utility collects and filters network packets and can analyze network activity. However, this utility diagnoses only the computer that it is running on. A copy of Network Monitor that is capable of monitoring all network traffic on your LAN is available with the Microsoft BackOffice product SMS.

The Network Monitor is a supplementary component of the Windows NT Workstation installation. To install this program, open the Network Control Panel's Service tab and click on the Add button. After Windows NT Workstation builds its list of services, you can select the Network Monitor from the list.

Network Monitor is both statistical and graphical. In the four panes of the Network Monitor, the current activity appears in real-time (see Figure 7.16).

The Graph pane in the upper-left corner shows the following bar graphs:

% Network Utilization
Broadcasts Per Second
Bytes Per Second
Frames Per Second
Multicast Per Second

These parameters indicate the level of activity your network is experiencing and how saturated your network bandwidth is.

The Session Stats pane shows you which nodes are communicating and the number of frames (of the first 128 measured) sent and received from each.

The Total Stats pane (on the right half of the Network Monitor) provides complete network statistics in the following categories:

Captured Statistics
Network Card (Mac) Error Statistics
Network Card (Mac) Statistics
Network Statistics
Per Second Statistics

You must scroll to see each of the panels in the pane for these different categories.

The last pane at the bottom of the window is the Station Stats pane. Information here shows what your workstation is communicating to the network. Click on a column head to sort by that category. The following categories appear:

Broadcasts Sent
Bytes Rcvd
Bytes Sent
Directed Frames Sent

Figure 7.16 The Network Monitor utility allows you to view frames coming into and going out of your workstation.

Frames Rcvd
Frames Sent
Multicasts Sent
Network Address

An amazing number of network problems are related to TCP/IP protocol addressing. Make sure that your workstation either has a unique address or uses a DHCP (Dynamic Host Configuration Protocol) service for its TCP/IP assignment. Also verify that the subnet address you entered in the TCP/IP Properties dialog box is correct.

Step by Step

7.14 Viewing TCP/IP Settings

Double-click the Network icon in Control Panel.
Click the Protocols tab of the Network dialog box.
Select the TCP/IP protocol, and then click Properties to view the Microsoft TCP/IP Properties dialog box (see Figure 7.17).
Examine the settings to see whether they are correct.

The PING utility is also included in Windows NT Workstation. You can ping other computers on the network to see whether they are active. Actually, you can ping your own workstation with the specific address, the default gateway, or any computer on the Internet or your intranet. Use the PING command in a command prompt session without any other parameters to see an informational screen detailing its use.

Resource Conflicts

Many configuration errors are resource conflicts. These take the form of duplicate interrupt or I/O assignments or SCSI devices having duplicate or improper assignments. You may see these problems when you first boot your system, or they may show up later when a device doesn't work properly.

Figure 7.17: The Microsoft TCP/IP Properties dialog box allows you to view and modify TCP/IP settings.

Check the Event Log to see what error events are listed. Also run the Windows diagnostic program WinMSD (in the Administrative Tools folder) to examine your resource settings. You can roll back errors in software by using the LastKnownGood configuration.

Using the Windows NT Diagnostics Program

The Windows NT Diagnostics program is the worthy successor to the MSD program found in Windows 3.1. This dialog box (see Figure 7.18) shows you information on many of the Registry items found in the HKEYLOCALMACHINE subtree. Using WinMSD, you can obtain detailed information and reports on the state and configuration of your workstation. You cannot use this diagnostic tool to change any configuration settings, but you can use it to determine what conditions exist so that you can fix a problem.

This dialog box contains the following tabs:

Display. Information on your video adapter, its firmware, and any adapter settings is found on this tab.
Drives. This tab offers a list of drives and volumes in a hierarchical display. Drives include floppy disk drives, hard disk drives, CD-ROM drives, optical drives, and mapped drives through any network connections. If you double-click on a drive letter, the Drive Properties dialog box appears. The Drive Properties dialog box shows you cluster size, bytes per sector, the current status of the use of the disk, and the file system in use.
Environment. All environmental variables in use for a command prompt session appear on this tab.
Memory. This tab shows the installed memory, virtual memory, and usage of both.
Network. The network tab shows installed logons, transports (protocols and bindings), settings, and statistics. Figure 7.19 shows the Transports display of the Network tab.

Figure 7.18: The Windows NT Diagnostics tool.

Figure 7.19: The Transports listing of the Network tab of the WinMSD dialog box.
Resources. When you open this tab, the listing of device assignments appears. Shown here are the IRQ, port numbers, DMA channels, and UMB locations used by each device. If you suspect a device conflict, this is the place to go to attempt to locate the suspect.
Services. The information stored in the HKEYLOCAL MACHINE\System\CurrentControlSet\Services key is displayed on this tab. If you select a service and click on the Devices button, the information stored in the HKEYLOCALMACHINE \System \CurrentControlSet \Control key appears, along with the status of that control.
System. This tab shows the information stored in the HKEYLOCAL MACHINE\Hardware key, including the CPU type and information on other installed devices.
Version. The information stored in the HKEYLOCAL MACHINE\Software\Microsoft\Windows\NT\CurrentVersion key is shown on this tab. You will find the operating system version, build number, and Service Pack update, and the registered owner of the software.

Windows NT ships with several utilities for evaluating a workstation's configuration and performance. By being proficient in the use of these tools, a savvy administrator can solve many problems and prevent others from occurring.

Using Additional Resources

In the introduction to this chapter, you learned that successful troubleshooting had a variety of components. Two major components were knowledge of the system and prior experience with the problem. Fortunately, not all knowledge and experience must come first-hand. If you have access to people who have more knowledge and experience than you, they can be valuable troubleshooting resources. In addition, a variety of sources of good information are available in subscription form. These include Microsoft's TechNet, Knowledge Base, and Developer Network. In addition, a variety of periodicals can give you up-to-date articles by experts in the NT field (Windows NT Magazine is a prime example). As well, don't forget the Official Microsoft Courses (available in an ATEC near you) and the Microsoft Web site.

All of these resources are invaluable for you as an NT expert to use in those situations when your knowledge is simply not enough to troubleshoot the problem. You should attempt to get your hands on as many of these resources as you can because they will more than pay for themselves the first time they yield an answer that saves you hours or days of work.

Essence of the Case

Here are the essential elements in this case:

The administrator account on an NT Workstation is inaccessible due to loss of password.
Due to loss of Administrator account, all administrative access has also been lost.

Scenario

You are the administrator charged with maintaining a network of 15 NT Workstations operating in a workgroup. The users have varying knowledge of NT, but all share the understanding that you do all the system maintenance. As a result, you are the only one who knows the Administrator account on each PC, and you maintain the same password on each for administrative ease.

At the behest of a user who's desperate to share a directory for another user to access, you give out the administrative password. Because you are busy at the time, you promptly forget that you have done so.

A couple of weeks later you get a call from the same user. Now it seems that he wants to remove the share he created, but he has a problem. After getting the password to the Administrator account, he "played around a bit." Not only did he create a bunch of shares, but he also changed the Administrator password "just to see if you could do that," and now he has forgotten it. As much as he has tried to remember the password, he is now convinced that he has lost it forever.

Analysis

The problem here is one of access and ends up being a sort of "chicken and egg" scenario. Without a useable Administrator account (or at least an account with administrator access), you cannot perform account maintenance. But if you are unable to perform account maintenance, you cannot get back your Administrator account. So you are forced to exit the loop and turn to restoration methods. Two possible solutions are available, both of which have potentially detrimental consequences. The first is to restore the accounts database from an emergency repair disk, and the second is to restore the Registry from a tape backup. In both cases, the possible danger is that the restoration may not be current enough to solve your problem, or it may be too current and may simply restore the problem.

Fortunately, you have been diligent in updating the emergency repair information on the hard disk of each workstation as you made changes to accounts and disk structures. As a result, the /Repair directory on the user's machine is as up-to-date as the last change you made using the Administrator account. Therefore, no changes that the user made himself will be present in these updates, which will serve to remove the password change when you restore.

You take the following action to restore the accounts database:

Run RDISK and choose the Create Repair Disk option.
Using the three Setup disks that came with the NT Workstation CD-ROM (or that you created with WINNT32 /ox), you restart the system. Then, using the repair disk, you restore the SAM.
If any changes were made to the system after the last repair directory update, you will have to redo them manually.

This chapter covered a variety of troubleshooting methods. It began with a suggested approach to troubleshooting (the DETECT model) and moved on to present a number of symptoms and solutions. Some of the specific areas covered in this chapter were booting, printing, installation, applications, access and permissions, and the Registry.

The objective of this chapter was to give you a framework for understanding the kinds of issues that may arise when troubleshooting NT Workstation problems, both in a production environment and on the exam.

Key Terms

Before you take the exam, make sure you are comfortable with the definitions and concepts for each of the following key terms:

DETECT
HCL
MBR
NTLDR
NTDETECT.COM
NTOSKRNL.EXE
BOOT.INI
ARC path
/SOS
LastKnownGood
BOOTSECT.DOS
NTBOOTDD.SYS
OSLOADER.EXE
recovery disk
emergency repair disk
RDISK.EXE
Event Viewer
Security log
System log
Application log
hive
Network Monitor
service
REGEDIT.EXE
REGEDT32.EXE

The following section allows you to assess how well you understood the material in the chapter. The exercises provide you with opportunities to engage in the sorts of tasks that comprise the skill sets the objectives reflect. Review and exam questions test your knowledge of the tasks and concepts specified in the objectives. Answers to the review and exam questions follow in the answers sections. For additional review- and exam-type questions, see the Top Score test engine on the CD-ROM that came with this book.

Exercises

These lab exercises enable you to practice troubleshooting Windows NT Workstation, as well as to create resources that will help you resolve a variety of problems.

7.1 Creating a Boot Floppy Disk and Emergency Repair Disks

In this exercise, you create a set of disks that enable you to start your workstation in case of boot failure and to repair a workstation that doesn't boot properly.

Estimated Time: 20 minutes

To create the boot floppy, follow these steps:

Insert a blank floppy disk in the disk drive and format that disk.
Open the Windows NT Explorer and select the BOOT.INI, NTLDR, and NTDETECT.COM files.
Copy these files to the floppy disk to create the NT boot floppy disk.
Restart your computer without removing the floppy disk from the drive. If the disk is valid, it will boot your computer.
Label the disk and store it in a secure location.

To create a set of emergency repair disks, follow these steps:

Choose Start, Programs, Command Prompt.
Type RDISK /S and press the Enter key.
Click on the Create Repair Disk button in the Repair Disk Utility dialog box (refer to Figure 7.3).
Insert a formatted floppy disk, and then click on the OK button.
After Windows NT Workstation creates the ERD, remove the floppy disk, write-protect it, and store it in a safe location.
Click the Exit button to close RDISK.
Click the Close box.

7.2 Displaying Device Drivers at Startup

This exercise explores how to have the BOOT.INI file enumerate your drivers when the kernel is loading.

Estimated Time: 15 minutes

Choose Start, Programs, Accessories, Notepad.
Select the Open command from the File menu.
Select All Files from the File of Type list box, and then select the BOOT.INI file in the root directory.
Find the line in the BOOT.INI file that reads Windows NT Server Version 4.00 [VGA] followed by the /basevideo and /sos switches. If your system uses a VGA driver, skip to step 6.
Choose the File, Save As command and save the BOOT.INI file to a different name, such as BOOT.BAK.
In the BOOT.BAK file, delete the /basevideo switch but leave the /sos switch intact. Modify the bracket text to read Windows NT Server Version 4.00 [SOS].
Select the File, Save As command and save the file as the BOOT.INI file in the root directory. (Note that the file BOOT.INI is read-only, system, and hidden. You will probably have to change the attributes to be able to save the file.)
Exit Notepad and reboot your system.
Select the SOS option from the boot menu when it appears. As your device drivers are loaded, each one is listed onscreen in ARC format.
Log on to Windows NT Workstation.
Restore the original BOOT.INI file with the VGA configuration and the /basevideo switch. Then reboot to test your system.

Review Questions

What phase of the startup process displays the blue screen with a series of dots added to the screen?
How can you restore your workstation's previous configuration?
How do you create a boot floppy?
How do you share a printer so that it is available to others on the network?
What is a Service Pack?
What are the most common reasons that a user can't log on to a domain?
How can you tell which service has failed?
What is a user profile and what does it control?
Who "owns" a resource?
Why is much of the Windows NT Registry not worth backing up?
How long do events remain in an Event Log?
What utility is most useful for determining resource conflicts?

Exam Questions

When is the LastKnownGood Configuration overwritten?
1. When you request an update on the Startup/Shutdown tab of the Control Panel's Services application.
2. When you start up your computer.
3. When you shut down your computer.
4. When you log on successfully to your workstation.
An error message appears, saying that a service failed to load. Where would you go to determine the nature of the problem?
1. The Services tab of the Control Panel's Network application
2. The User Manager for Domains
3. The System log in the Event Viewer application
4. The Control Panel's Services application
Which file is not required on a boot disk for an x86 Windows NT Workstation?
1. BOOT.INI
2. NTLDR
3. NTDETECT.COM
4. NTBOOTDD.BAT
Which of the following programs creates an ERD?
1. FORMAT
2. RDISK
3. RECOVER
4. ERD
Your print job spools, but it does not print. Which of the following could not be the reason?
1. The printer is turned off.
2. The paper tray is empty.
3. The printer's memory is full.
4. Your hard drive is full.
How do you hide a printer share?
1. Move the file to your system WINNT folder.
2. Add a dollar sign after the share name.
3. Set an option in the Printer Properties dialog box.
4. Create a hidden spool folder.
What happens when you don't have adequate space for an installation?
1. The Setup program detects this, stops, and cancels the operation.
2. The space available is used to overwrite as many files as possible.
3. Your installation becomes corrupted.
4. You are given the choice of installing MS-DOS as a temporary measure.
Which one of the following should you not do to reclaim space on your disk?
1. Delete any TEMP files you find in various locations (for example, in the print cache folder).
2. Empty your Recycle Bin.
3. Uninstall any programs that you no longer need.
4. Change your file system.
Which methods can you use to open the Task Manager?
1. Select the Task Manager from the Administrative Tools folder.
2. Click on the Task Manager button in the Windows NT Security dialog box.
3. Select the Task Manager command from the Start menu's Status bar shortcut menu.
4. Press Ctrl+Esc.
Which of the following user profiles does not exist?
1. Default user profile
2. A user account profile
3. Anonymous user profile
4. Roaming profiles
How do you control what action is taken when your workstation encounters a STOP error?
1. Use the Control Panel's System application to specify the action.
2. No action is possible; the computer logs an error and reboots.
3. Use the Control Panel's Network application to specify the action.
4. Reboot to MS-DOS and enter the RECOVER command.

Answers to Review Questions

The blue screen appears when the Hardware Abstraction Layer (HAL) loads. Each dot represents a device driver being loaded. For more information, see the section "The Intel Boot Sequence."
The LastKnownGood configuration is offered as a step in the startup process. Press the spacebar to return to that configuration. Each time you successfully log on to Windows NT Workstation, the LastKnownGood configuration is changed. For more information, see the section "LastKnownGood Recovery."
Format a floppy disk and copy the hidden system files: BOOT.INI, NTLDR, NTBOOTDD.SYS, and NTDETECT.COM in your %systemroot% to that floppy disk. For more information, see the section "Boot Disk Recovery."
You can specify that a printer is to be shared in the Add Printer Wizard. After the fact, you can select the Sharing command from a printer's shortcut menu and configure the printer share from the Sharing tab of the Printer Properties dialog box. For more information, see the section "Printers As Shared Resources."
A Service Pack is a program that Microsoft releases to update Windows NT Workstation (or another application). Service Packs are numbered for each version of the operating system, and greater numbers are given to later versions. It's a good idea to use Service Packs to stay current. For more information, see the section "Installation Disk Errors and Upgrades."
Either the username and password have been entered incorrectly, or the user account doesn't exist. For more information, see the section "The Load Process."
Open the Event Viewer and examine the System log to see what error events are listed. Then check for details to determine the cause. For more information, see the section "Service Failures."
A user profile is a collection of Registry settings that control the look and feel of your workstation, commands on the Start menu, available applications, printers, and other resources. Profiles come in two forms: default, which is related to a specific user, or roaming, which is stored on the network to enable a user to move from workstation to workstation. For more information, see the section "The Emergency Repair Process."
The creator of the resource owns that resource and has full rights and privileges to it. An administrator can access a resource and modify it and can take ownership of that resource away from the original owner. Doing so, however, causes the original owner to be locked out of his ownership position. For more information, see the section "Assessing User Resource Access Failures."
Much of the Windows NT Registry describes transient settings that are session dependent. Two of the Registry hives describing Security and SAM settings cannot be backed up. For more information, see the section "Backing Up the Registry."
Events remain in the Event Log for seven days or until the log fills up and additional space is required. Events are removed in a first-in first-out manner. For more information, see the section "Working with the Event Logs and Event Viewer."
The Windows NT Diagnostics program lists the various devices that you have installed on your workstation and the settings they have for IRQs, I/O ports, DMA, and so forth. Through examination of this utility, you can determine what conflicts might exist. For more information, see the section "Using the Windows NT Diagnostics Program."

Answers to Exam Questions

D is correct. A successful logon overwrites changes in the Registry for the LastKnownGood configuration. For more information, see the section "LastKnownGood Recovery."
C is correct. Any system failure is written as an event in the System log. For more information, see the section "Service Failures."
D is correct. Choice D is fictitious. All the other choices are essential files that are copied to the floppy boot disk. For more information, see the section "The Intel Boot Sequence."
B is correct. RDISK creates and updates emergency repair disks. For more information, see "The Emergency Repair Process."
D is correct. A full hard drive has no effect on a previously spooled print file because that file has already been written to disk. For more information, see the section "Solving Print Spooler Problems."
B is correct. By adding a dollar sign to the end of a sharename, you can hide that share from view. For more information, see the section "Printers As Shared Resources."
A is correct. Early in the process, Setup examines the file system and the disk size and assesses the amount of free space you have and the amount that's required. If you don't have enough free space, the installation is aborted. This is true even if you are overwriting enough files to free up sufficient disk space for the installation. For more information, see the section "Assessing Installation Failures."
D is correct. Changing the file system permanently deletes all the data on your disk. In almost all instances, this is neither necessary nor required. For more information, see the section "Inadequate Disk Space."
B and C are correct. A is incorrect because there is no command for the Task Manager on the Start menu. D is incorrect because the keystroke used to open the Task Manager is Ctrl+Shift+Esc. For more information, see the section "Assessing Application Failures."
C is correct. A, B, and D all exist and support both local and remote users on a network. Choice C is incorrect because there is no "guest" or anonymous user profile, only the default profile. For more information, see the section "The Emergency Repair Process."
A is correct. The System Control Panel contains a setting for the action to be taken when a STOP error occurs. For more information, see the section "Boot Sequence Errors."

About The Author

Dennis Maione lives in Winnipeg, Canada, where he is a full-time trainer for PBSC Computer Training Centres, the largest Canadian ATEC. He is an MCSE, MCT and has been in the computer training business for three years. He has a computer science degree and more than 15 years of experience programming and administering networks in a variety of environments. Dennis is also the author of MCSE Training Guide: Windows NT Server 4, Second Edition and is co-author of CLP Training Guide: Lotus Notes.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

International rights = English only.

Click to order

Chapter 7 - Troubleshooting

On This Page

Introduction

General Troubleshooting Techniques

Assessing Boot Process Failures

The Boot Sequence

The Windows NT Boot Process

BOOT.INI

Step by Step

The Load Process

LastKnownGood Recovery

Step by Step

Boot Sequence Errors

Boot Disk Recovery

Step by Step

The Emergency Repair Process

RDISK.EXE

Assessing Print Job Failures

Understanding the Windows Printing Subsystem

Using a Basic Error Checklist

Step by Step

Printers As Shared Resources

Solving Print Spooler Problems

Step by Step

Step by Step

Using the Print Troubleshooter

Step by Step

Assessing Installation Failures

Installation Disk Errors and Upgrades

Inadequate Disk Space

Disk Configuration Errors

Inability to Connect to a Domain Controller

Domain Name Error

Assessing Application Failures

Step by Step

Step by Step

Using the Application Log

Service Failures

Assessing User Resource Access Failures

Usernames and Passwords

Step by Step

Resource Availability

Resource Permissions

Modifying the Registry

Using the Registry Editor

Step by Step

Backing Up the Registry

Changing the Registry Size

Step by step

Troubleshooting the Registry

Using Advanced Techniques

Working with the Event Logs and Event Viewer

Step by Step

Network Diagnostics

Step by Step

Resource Conflicts

Using the Windows NT Diagnostics Program

Using Additional Resources

Exercises

Review Questions

Exam Questions

Answers to Review Questions

Answers to Exam Questions

About The Author

Additional resources