Fixing the Underlying Problem | Microsoft Windows 2000 Server Administrators Companion

Once you have the system booting again, you might need to perform some further troubleshooting. Booting the computer successfully in safe mode is a relief, but it is of little consolation if you still can't boot normally. Unfortunately, solving the underlying trouble can be very complex and, as a result, the recommendations here are only a starting point. If these recommendations don't fix the trouble, consult the Microsoft Windows 2000 Server Resource Kit and the Microsoft Knowledge Base for further information. With that stipulation, the advice dispensed in the next several sections can help you fix the majority of the difficulties you are likely to encounter.

When troubleshooting, act like a scientist running an experiment. Change only one thing at a time to minimize the likelihood of confounding variables. Also, do some deep thinking about the results you get. If you see that the system is hanging on a certain service that is failing, check to make sure that the failing service isn't dependent on some other services that aren't starting. For your own sanity, start with the least painful steps first. Save formatting your hard disk and reinstalling Windows for last.

Maybe It'll Go Away

The first thing to try after successfully booting a system in safe mode is to attempt rebooting normally. Oddly enough, this actually works sometimes and is worth a try if the system just mysteriously refuses to boot one day.

Check the Microsoft Knowledge Base

If Windows displays any specific error messages, go to Microsoft's online Help and Support center (http://support.microsoft.com/default.aspx) and search under the Windows 2000 Server category for a few keywords from the error message. Often this speeds the troubleshooting process by letting you quickly home in on the cause. Otherwise, use the rest of this chapter to troubleshoot it yourself (but refer back to the Knowledge Base if you manage to generate any notable error messages during your troubleshooting process).

Undo Anything You've Changed

As mentioned earlier in the chapter, malfunctions are usually the result of some action: installing a new driver or program, changing a registry setting, formatting the system drive, and so on. Therefore, the first thing to do once you get the system booting again is to undo anything that you've done recently (if possible).

Start by booting using the Last Known Good Configuration (if you haven't already). Also trying uninstalling any recently added drivers, or programs (especially utilities), and removing or disabling any recently added devices (see the section entitled Check Device Manager later in this chapter for more information about checking for hardware problems).

Check Event Viewer

One of your first moves when trying to track down the source of system problems should be to check Event Viewer, which is available either as a part of the Computer Management console or by itself from the Administrative Tools folder. Event Viewer (Figure 38-1) often gives you a string of clues as to the cause of the trouble and sometimes even tells you what to do to fix it. For more information about using Event Viewer, see Chapter 10. Carefully examine errors or warnings in the system log and other relevant logs. Don't forget the Information events, sometimes a source of valuable clues.

Figure 38-1. The Event Viewer window.

Check Device Manager

If a device in the system is causing a resource conflict or some other impasse, check Device Manager, located in the Computer Management snap-in. Examine the system for devices with conflicts or errors, and consider disabling these devices or removing them from the system. (Note that removing them from Device Manager usually just causes the devices to be redetected the next time the system boots, potentially causing the same problem.) It is standard practice when troubleshooting resource conflicts to disable or remove every device in the system that you can boot without (such as sound cards, network cards, and modems). Once the system works normally, add the devices back one by one until the problem reappears. Then you can troubleshoot the device in question. Chapter 6 includes more information about troubleshooting hardware.

Advanced Configuration Power Interface (ACPI) systems automatically configure all PCI devices, preventing you from changing a device's resource settings to resolve a conflict. To deal with resource conflicts, remove the devices in question from Device Manager and allow it to rescan them, or change which PCI slots the cards are plugged into.

Use System Information to Check the Configuration

Besides checking Event Viewer and Device Manager, use the Windows 2000 Server system information tools to gather further information about the system and any possibly problematic hardware or software (although most of the time you can find and fix trouble more quickly using Event Viewer and Device Manager alone).

To view system information, use the following procedure:

Click Start, choose Programs, Accessories, System Tools, and finally System Information (or type msinfo32 in the Run dialog box or at a command prompt).
Select Components and then Problem Devices, as shown in Figure 38-2. Make a note of any devices listed here and then use Device Manager to troubleshoot them.

Figure 38-2. The System Information console in the Computer Management window.
In System Information, select Hardware Resources and then Conflicts/Sharing to view a list of hardware conflicts and shared resources. Note that most shared resources don't cause any difficulties on a modern system, but some devices don't like to share, so this is a place to check if a device is causing trouble.
If you suspect an ill-behaved startup program might be the source of your difficulty, select Software Environment, and then Startup Programs to see a list of programs that start with Windows.

Check the Services

As with Microsoft Windows NT, checking the services in Windows 2000 can be invaluable in solving a dilemma. If a key service isn't starting, you're going to have trouble. Make sure that key services are set to start automatically, and consider disabling services that could potentially cause trouble, or at least set them to start manually (although an automatically starting service starts any services it needs—even services set to start manually—unless the services are disabled).

You might also want to specify what actions to take if the service fails. To perform some of these actions with the Services snap-in, follow these steps:

Launch the Services snap-in from the Administrative Tools folder on the Programs menu.
Use the window shown in Figure 38-3 to view the status of the services.

Figure 38-3. The Services window.
Use the Start Service, Stop Service, Pause Service, and the especially useful Restart Service toolbar buttons to make changes to the state of the services.
To change advanced settings for a service, double-click the service to open its Properties dialog box, shown in Figure 38-4.

Figure 38-4. A service's Properties dialog box.
Use the Startup Type list box in the General tab to change how you want the service started.
Use the Log On tab to choose which account you want the service to log on. The default is the LocalSystem account, but you can change this to a user account as needed.
Click the Recovery tab, and then choose what actions you want to take on the first, second, and subsequent failures of the service, as shown in Figure 38-5.

Figure 38-5. The Recovery tab of a service's Properties dialog box.
In the Reset Fail Count After box, enter the number of days after which you want to start over counting service failures.
Click the Dependencies tab to view the services that the specified service is dependent on.

Examine the Boot Log

Sometimes it's useful to create a log file of the Windows startup process, documenting which devices, drivers, and services start up properly and which don't. To create a boot log, start the computer in any safe mode by pressing F8 during the boot process and then choosing the desired safe mode or choosing the Enable Boot Logging option from the Windows Advanced Options menu.

This creates a log file with all of the drivers and services loaded or failed during the boot process. The file is called Ntbtlog.txt and is stored in the %Windir% folder.

Use the File Signature Verification Utility

A system that uses only Microsoft certified and signed device drivers and system files exhibits better stability than a system that doesn't, all else being equal. Although Windows 2000 Server blocks the installation of unsigned device drivers, this can be overridden with the appropriate permissions. If you suspect that an unsigned system file or device driver could be the cause of your difficulties, use the File Signature Verification utility to locate any unsigned files. To do so, use the following procedure:

Choose the Run command from the Start menu, type sigverif in the Open box, and then click OK. Alternatively, open the System Information tool (Msinfo32.exe) and choose the Windows command from the Tools menu, and then choose File Signature Verification Utility from the submenu.
Click Start to scan for unsigned system files (Figure 38-6), or click Advanced to specify other file types and folders to scan for unsigned files (instead of the Windows system files). To scan for unsigned device drivers, search the \Windows\Wystem32\Drivers folder and subfolders.

Figure 38-6. The File Signature Verification utility.
Make a note of any unsigned drivers (or refer to the Sigverif.txt log file saved in the Windows folder), and disable them by disabling the associated device (or updating the driver) in Device Manager, uninstalling the driver using Add/Remove Programs, or renaming the driver in the \Windows\System32\Drivers folder.

Use the System File Checker

The System File Checker is a command-line tool that allows you to verify that all of the protected system files are intact. This tool can be handy if you suspect that the system files might be corrupt. If the System File Checker finds that a protected system file has been overwritten, it retrieves the correct version from the %SystemRoot%\System32\Dllcache folder and uses it to replace the incorrect version.

To use the System File Checker, log on locally as an administrator, go to a command prompt, and type sfc followed by the appropriate parameter. See Table 38-2 for a list of parameters and what they do.

If the %SystemRoot%\System32\Dllcache folder becomes corrupted or is deleted, use one of the following commands to repair the folder: sfc /scannow, sfc /scanonce, or sfc /scanboot.

Table 38-2. System File Checker options

Parameter	Action
/scannow	Immediately scans all protected system files.
/scanonce	Scans all protected files a single time.
/scanboot	Scans all protected files every time the computer is booted.
/cancel	Cancels all scheduled scans.
/quiet	Scans and replaces incorrect files without prompting the user for action.
/enable	Resets Windows File Protection to its default status. Users are prompted to restore any files that are overwritten.
/purgecache	Deletes all files in the %SystemRoot%\System32\Dllcache folder (the Windows File Protection cache) and immediately scans the protected system files.
/cachesize=x	Specifies how large (in megabytes) the %SystemRoot%\System32\Dllcache folder (the Windows File Protection file cache) should be.

Editing the Boot.ini File

The Boot.ini file controls with what options Windows boots (such as Safe Mode or VGA display), or which operating system boots if there are multiple operating systems installed.

It's occasionally necessary to edit the Boot.ini file, sometimes simply to reduce the boot time delay or change the default startup options, but sometimes it's to get a system booting again (such as when a system with mirrored system disks fails).

To edit the Boot.ini file, open it using any text editor (you'll have to temporarily remove the hidden, read-only and system attributes by typing attrib c:\boot.ini -h -r -s at a command prompt). Table 38-3 lists some Boot.ini switches that you can use to make troubleshooting easier in the future (although these switches by themselves don't repair anything).

Table 38-3. Boot.ini switches for the various Windows 2000 boot options

Boot Option	Switch to Use in Boot.ini
Safe Mode	/safeboot:minimal /sos /bootlog /noguiboot
Safe Mode With Networking	/safeboot:network /sos /bootlog /noguiboot
Safe Mode With Command Prompt	/safeboot:minimal(alternateshell) /sos /bootlog /noguiboot
Enable Boot Logging	/bootlog
Enable VGA Mode	/basevideo
Directory Service Restore Mode (domain controllers only)	/safeboot:dsrepair /sos
Debugging Mode	/debug

Restore from a Backup

If you can start Windows 2000 and you're confident that the system was in a good state at the last backup, consider restoring from the backup rather than wasting time trying to track down a corrupt file. Remember, however, that any changes you've made since the last backup will most likely be lost, so use this option as one of your last choices.

Reinstall Windows

Reinstalling Windows is your last resort. It provides a way to thoroughly clean the system, possibly without reinstalling programs. If you run Setup from within Windows you can perform an upgrade install right over the old installation and preserve the settings.

Your problems, however, might be so deeply rooted that even this type of reinstall can't fix them. In such cases, the source might be the settings, which are largely preserved during a reinstall. It then becomes necessary to perform a clean install, either by uninstalling Windows using the method described in the section entitled Uninstalling Windows, later in this chapter (or by just formatting the disk) or by performing a parallel installation (after which you probably will want to delete the damaged installation). See Chapter 5 for information about performing a clean installation of Windows.