Preventing System Failures

Now it is time to discuss the measures that will help you prevent system failures. Naturally, all emergency planning should be done beforehand.

Performing maintenance procedures on a regular basis allows you to prevent possible problems or, at least, minimize their negative effect. The general procedures are listed below:

• Most of the time, system malfunctions, or even boot failures, are caused by overwritten system files or by incompatible drivers. This usually happens when you install incompatible third-party software. This problem exists not only in Windows 2000, Windows XP, and Windows Server 2003, but in all earlier versions of the Windows NT operating system as well. Windows 2000, Windows XP and Windows Server 2003 implement additional tools, though, which protect system files and drivers with a digital signature. The digital signature guarantees that the system file or driver is Windows-compatible. If you want to avoid any possible problems, it is recommended that you use these tools. This topic will be covered in greater detail later in the chapter.

• Back up the System State data and prepare for the Automated System Recovery process (ASR) on a regular basis. Don't forget to perform these operations before introducing significant modifications in the system configuration (including new hardware and software installations). A usable and up-to-date backup copy of all your important data will also be helpful.

• In Windows XP systems, don't disable System Restore. Although some users may think that this tool consumes too much free disk space, it can still be very useful if you need to restore a damaged system.

  Detailed instructions on performing these operations were provided in Chapter 2.

• View system event logs on a daily basis (or, at the very least, view the system and application logs). Pay close attention to the messages generated by the FtDisk driver and hard-disk drivers, because they may report possible file-system errors. If you don't follow this rule, file-system errors may remain unnoticed until the Chkdsk utility detects them. Notice that, in this case, the damaged data may even be included in the backup copy, since most backup utilities (including the Backup program supplied with Windows 2000 and later versions) don't recognize errors in user data.

• Check your disks on a regular basis for early detection of possible file-system errors. It is also recommended that you defragment your disks regularly to eliminate any possible performance problems. Use only built-in tools or third-party disk utilities certified for Windows 2000/XP/Windows Server 2003. An official list of third-party software products tested for compatibility with Windows 2000/XP/Windows Server 2003 can be downloaded from http://www.microsoft.com.

• Install a parallel copy of the operating system to improve reliability.

If the POST procedure has been completed successfully, this means that the hardware has initialized correctly. If the boot process still fails, the boot problem may come from one of the following sources:

• Problems related to the hard disk containing the system partition.

• Corruption of the Master Boot Record (MBR) or partition boot sector.

• One of the boot files may be missing or corrupt. A list of the files necessary to boot Windows NT, Windows 2000, Windows XP, or Windows Server 2003 was provided earlier in this chapter.

Windows XP and Windows Server 2003 include several advanced tools that help restore the damaged system. These tools are briefly described in the list below.

• Windows file protection with a digital signature. Windows 2000, Windows XP, and Windows Server 2003 provide a set of tools that protect system files and device drivers from being overwritten during software-installation procedures. Previous versions of Windows NT didn't provide protection for system files (which also include dynamically loaded libraries (DLL) and executables (EXE)). If these files were accidentally overwritten by incompatible versions, the possible consequences range from performance degradation to catastrophic failures. Windows 2000 and its successors include the following system-file protection tools: System File Protection (SFP), System File Checker (SFC), and File Signature Verification (FSV).

• Automatic Updates. Automatic Updates automates the process of downloading updates from the Windows Update website. You can configure Automatic Updates to check for and download updates.

• Safe mode. This option closely resembles a similar boot option included in Windows 95/98. It is one of the most important and useful features introduced with Windows 2000 and further enhanced in Windows XP and Windows Server 2003. When the system boots in safe mode, it loads the minimum set of device drivers and services. Safe mode improves reliability and provides an easy way to recover a system damaged by incorrect software installation. Notice, however, that the safe-mode option isn't a universal tool that helps in all cases. For example, this option is almost useless if there's a problem with your hard disk or if any of the system files are missing or corrupt.

• Automated System Recovery. Automated System Recovery (ASR) is a two-part recovery system that allows you to restore a damaged Windows XP or Windows Server 2003 installation by using files saved to tape media, and hard-disk-configuration information saved to a floppy disk. It replaces the Emergency Repair Disk (ERD) function that was present in earlier Windows NT versions and, with some improvements, was also included with Windows 2000. Step-by-step descriptions required in order to prepare and perform the Automated System Recovery are provided in Chapter 2.

• Driver Rollback. This is probably one of the most useful recovery tools introduced with Windows XP and Windows Server 2003. Now, if you have installed an updated version of the driver after installing Windows XP or one of the products of the Windows Server 2003 family, and suspect that this operation has caused system instability or boot problems, you can replace a specific device driver with a previously installed version. Replacing a driver is the simplest way of restoring the system, provided, of course, that it is the driver that is causing the problem. The Roll Back Driver button in Device Manager enables you to revert to an older driver while you investigate issues with the new one. The procedures for performing Driver Rollback are described in Chapter 5. Note that, if you update several drivers during a single session, it might be more convenient to use the Last Known Good Configuration startup option.

• Error Reporting. Error Reporting, if enabled, monitors your system for problems that affect Windows XP or Windows Server 2003 components and applications. When a problem occurs, you can send a problem report to Microsoft and receive a response with more information.

• Recovery Console. Recovery Console provides a command-line interface to perform the recovery of a damaged system. Using Recovery Console, you can enable or disable services, restore damaged Master Boot Records and/or partition-boot sectors and replace damaged system files. This is a powerful recovery tool, available only for users with administrative rights in the local system. The syntax of the Recovery Console commands will be discussed later in this chapter.

System File Protection in Windows 2000, Windows XP and Windows Server 2003

All system files and device drivers in Windows 2000, Windows XP, and Windows Server 2003 are protected by a digital signature, which confirms that these system files and drivers are compatible with the operating system. A Microsoft digital signature verifies that the signed file was successfully tested for compatibility at Windows Hardware Quality Labs (WHQL), and wasn't modified or overwritten when installing add-on software.

According to the configuration settings, Windows 2000/XP and Windows Server 2003 might ignore drivers that aren't digitally signed, display a warning message when detecting these drivers (this option is set by default), or simply prohibit their installation. To configure system-file protection options in Windows 2000/XP/Windows Server 2003, proceed as follows:

1. Open Control Panel and start the System applet. The System Properties window will open. Go to the Hardware tab (Fig. 6.5).

   
   Figure 6.5: The Hardware tab of the System Properties window

2. Click the Driver Signing button. The Driver Signing Options window will appear (Fig. 6.6). This window contains the What action do you want Windows to take? option group, which allows you to specify the following options:

   
   Figure 6.6: The Driver Signing Options dialog

   • If you select the Ignore radio button, the system will allow you to install any of the drivers. However, it won't check if the driver you are going to install has a digital signature. (If this option is installed, Windows 2000/XP or Windows Server 2003 behaves like Windows NT 4.0). As already mentioned, the presence of a digital signature confirms that the file has been officially tested for compatibility. If the system file or device driver doesn't have a digital signature, this means that the file isn't officially guaranteed to be compatible.

   • If you set the Warn radio button, the system will display warnings any time an attempt is made to install a system file or driver that isn't digitally signed (Fig. 6.7). Notice that, despite this warning, the system file or driver will be installed. Furthermore, you can encounter situations where Microsoft currently has no certification program for the device that you are attempting to install (Fig. 6.8). In particular, this is true for devices that have appeared on the market recently. Still, most of these devices (such as portable USB disk drives, infrared ports, digital cameras, Bluetooth devices, etc.) will install without problems and operate smoothly.

     
     Figure 6.7: Any time an attempt is made to install a system file or driver that isn't digitally signed, Windows 2000/XP and Windows Server 2003 operating systems display a warning

     
     Figure 6.8: For the moment of this writing, Microsoft had no certification program for Bluetooth devices

   • If you set the Block radio button, the system won't allow anyone to install drivers without a digital signature.

Note 

Users with administrative rights (Administrator and members of the Administrators group) can specify the default option, which will be used by default for all users who log on to the computer. To establish this mode, set the Apply setting as system default checkbox in the Administrator option group.

Mechanism of Driver Protection by a Digital Signature

How do Windows 2000, Windows XP and products of the Windows Server 2003 family install drivers? There are two methods:

• Automatic driver installation by the PnP subsystem. This method, first introduced in Windows 2000, was further streamlined in Windows XP and Windows Server 2003 and is the recommended option. More detailed information on this topic was provided in Chapter 5. Here, you should remember that Windows 2000 and its successors only attempt driver installation after the Plug and Play subsystem (PnP subsystem) has discovered a new device. The User-Mode Plug and Play Manager (UMPNPMGR, which is the system DLL: %SystemRoot%\System32\Umpnpmgr.dll) waits until the kernel-mode PnP subsystem notifies it that a new device has been detected. When the notification arrives, UMPNPMGR searches the INF file for a device driver that contains the necessary installation information. All INF files for drivers included with Windows 2000, Windows XP or Windows Server 2003 are located in the %SystemRoot%\INF folder. If you are installing an OEM driver, the INF file will probably be located on the floppy disk or CD supplied by the vendor.

• There is also another method for installing device drivers - using the Hardware Installation Wizard located at %SystemRoot%\System32\Newdev.dll. The Hardware Installation Wizard performs the same operations as the usermode PnP Manager. It also searches the INF file for the device driver to be installed.

Both UMPNPMGR and Hardware Installation Wizard use Setup API (SETUPAPI - %SystemRoot%\System32\Setupapi.dll) for reading the information contained in the INF file. Besides handling driver-installation instructions, Windows 2000/XP/Windows Server 2003 checks the Policy value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Driver Signing (Fig. 6.9). If this entry is missing, Windows 2000 and Windows XP/Windows Server 2003 will check the Policy value under HKEY_CURRENT_USER\Software\Microsoft\Driver Signing. Note that you set these parameters using the Driver Signing Options dialog. If you have logged on to the system as an Administrator and you instruct the system to use this option by default, the system will follow the Policy setting under HKEY_LOCAL_MACHINE. Otherwise, it will follow the HKEY_CURRENT_USER parameter. When the system checks these settings, it turns first to the Policy setting under HKEY_LOCAL_MACHINE (if this value is set, it will have priority over the parameters set for individual users). If the Policy value is set to 0, the system will install all of the drivers, including those with no digital signature. If this value is set to 1, the system will allow you to install drivers without a digital signature, but a warning message will be displayed. If this value is set to 2, all of the drivers that aren't digitally signed will be ignored.

Figure 6.9: The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Driver Signing registry key

If the policy on unsigned drivers makes it necessary to check the digital signature, Setupapi.dll calls on CryptoAPI services to decrypt the signature using the VeriSign open key.

But where does the system store the digital signatures that protect Windows 2000/XP/Windows Server 2003 device drivers and system files? Microsoft stores all the digital signatures protecting Windows distribution files in special catalog files that are located in the %SystemRoot%\System32\Catroot directory. OEM device drivers should be supplied along with their individual catalog files. Microsoft supplies these files to the device supplier after the device has been successfully tested and included in the Hardware Compatibility List (HCL). The \Catroot directory contains the master index of the device-driver catalog files (sysmast.cbd and sysmast.cbk) and the nested folder. The nested-folder name represents a long combination of digits and characters. When you open this folder, you will find catalog files for all of the operating system's built-in components. The Nt5.cat and Nt5inf.cat files deserve special attention, because they store the digital signatures for all of the Windows 2000/XP/Windows Server 2003 system files included in the distribution set.

If the result of decrypting the digital signature of a device driver or system file doesn't coincide with the digital signature contained in the driver-catalog file, or if the driver has no catalog file, you will either get a warning message or (if the option has been set) the driver installation will fail.

Other Tools for Protecting Windows 2000/XP/Windows Server 2003 System Files

Windows 2000/XP/Windows Server 2003 also includes tools which allow you to protect the device drivers and system files. These tools guarantee that the device drivers and system files remain unchanged, and include the following:

• Windows File Protection

• System File Checker

• File Signature Verification

Windows File Protection

All earlier versions of Windows had one common drawback - when installing third-party add-on software, all shared files (including DLL and EXE files) could be changed or even overwritten by incorrect or incompatible versions. This, of course, could lead to unpredictable results. For example, the system performance could be affected, certain applications could behave incorrectly, or STOP errors could become persistent. In some cases, this could even render your system unbootable.

Windows 2000 is the first Windows operating system in which an attempt was made to correct this situation. This functionality is also present in Windows XP and all products of the Windows Server 2003 family. The Windows File Protection feature contains the following two components:

• Windows File Protection service

• The System File Checker command-line utility (Sfc.exe)

Windows File Protection service (WFP) is based on the principle of detecting the digital signatures of all protected system files (such as SYS, DLL, OCX, TTF, FON, EXE files) and protecting these files from being modified or replaced accidentally. Windows File Protection services runs in background mode and protects all files installed by the Setup program during installation of the operating system.

WFP detects any attempts made by other programs to replace the protected system files. It performs this task by checking to make sure that the file intended to replace the protected version is digitally signed. The presence of a digital signature verifies that the version is compatible with the operating system. If the newer version is incorrect, Windows File Protection replaces this file with the one from the backup copy of the %SystemRoot%\System32\Dllcache folder or from the distribution CD. If the Windows File Protection function can't locate a correct version of the file, it prompts you to specify the path to a directory that stores this version. It also registers any attempt at system-file replacement in the system-event log. This function is enabled by default, which means that it will allow you to replace protected system files only when you are installing the following types of software:

• Service Packs (using the Update.exe program)

• Hotfix packs (using the Hotfix.exe program)

• Operating-system upgrades (using the Winnt32.exe program)

• Any Windows Update software

System File Checker

Windows 2000, Windows XP, and Windows Server 2003 include a special utility for checking system files (System File Checker, Sfc.exe). This is a command-line utility, which scans all installed system files and checks their versions when rebooting the system. If this utility detects replaced versions of any protected system file, it will find the correct version in the %SystemRoot%\System32\Dllcache directory and will replace the modified file with this version.

This utility uses the following syntax:

   sfc [/scannow] [/scanonce] [/scanboot] [/cancel] [/quiet] [/enable]     [/purgecache] [/cachesize=x]

where:

• /scannow - if this parameter has been specified, SFC will perform the check immediately.

• /scanonce - if you specify this parameter, SFC will scan all protected system files only once.

• /scanboot - if you specify this parameter, a scan will take place each time you reboot the system.

• /revert - returns scan to the default settings (Windows XP only).

• /cancel - cancels all pending scans of protected system files (Windows 2000 only).

• /quiet - replaces all incorrect file versions without prompting the user (Windows 2000 only).

• /enable - enables WFP for standard operation (Windows 2000 only).

• /purgecache - this switch clears the file cache of the System File Protection function and scans all protected system files immediately.

• /cachesize=x - allows you to specify the size of the file cache of the System File Protection function (in MB).

Note 

To use the Sfc.exe utility, you need to log on as an Administrator or member of the Administrators group.

If the contents of the %SystemRoot%\System32\Dllcache folder become corrupt, use Sfc /scanonce, Sfc /scannow or /Sfc /scanboot commands to restore the contents of the \Dllcache folder.

Now, let's answer the following question: Where does the system store all of the settings that control SFC? Not surprisingly, they are stored in the registry. All registry settings that control SFC behavior are located under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. These settings are listed below:

• SFCDisable - the first registry setting read by SFC. If this value isn't set to 0 and the system is running in debugging mode (WinDbg kernel debugger is active), SFC disables all of the functions for protecting system files and device drivers.

• SFCScan. If this value is set to 1, SFC will scan the system files immediately after system initialization. If the SFCScan value is set to 2, SFC will reset it to 0 immediately after performing the scan. The default value for this setting is 0 and the value instructs SFC to protect system files (however, without scanning immediately after system initialization).

• SfcDllCacheDir - specifies the path to the \Dllcache folder.

• SFCQuota - this value specifies the total size of the system files that need to be scanned and protected.

Note 

None of the registry settings listed above are mandatory, nor are they present in the registry by default. If any of these settings are missing, SFC behaves as if the missing parameters are present and set to default values (the default value for SFCQuota is equal to −1; this value specifies an unlimited size of data to be checked).

File Signature Verification

As mentioned before, there are some cases where the system file is replaced by incorrect or incompatible versions during the installation procedures for third-party add-on software that isn't digitally signed. This replacement can make your system unstable (and be a potential source of persistent boot problem STOP errors).

To avoid this kind of problem, all of the system files installed during Windows 2000/XP/Windows Server 2003 Setup are protected by Microsoft digital signatures. This guarantees that the digitally signed files are compatible with the operating system. The digital signature also verifies that the signed file is either the original version developed by Microsoft or has been tested for compatibility. Verification of the files' digital signatures allows you to identify all of the files installed on the computer that aren't digitally signed. The File Signature Verification utility also displays the following information on the detected files:

• Name and fully qualified path to the file

• Date of modification to the file

• File type and version number

To start the verification procedure, click the Start button, select Run, and enter the following command: sigverif.

If you save the information collected by sigverif in the log file, this tool will prove to be very useful for troubleshooting problems related to incorrect versions of system files. To log this information, proceed as follows:

1. Start the sigverif program. The File Signature Verification window will open (Fig. 6.10). Click the Advanced button.

   
   Figure 6.10: The initial dialog of the File Signature Verification program

2. The Advanced File Signature Verification Settings window will open. Go to the Logging tab (Fig. 6.11) and set the Save the file signature verification results to a log file checkbox.

   
   Figure 6.11: The Logging tab of the Advanced File Signature Verification Settings window

3. Go to the Logging options group, which provides you with the following logging options:

   • Append to existing log file: if you select this radio button, the results of the new scanning operation will be added to the end of the existing log file.

   • Overwrite existing log file: if you select this option, the existing log file will be overwritten by the results of the new scan.

   • You can manually enter the log file name into the Log file name field.

4. Click OK. You'll return to the File Signature Verification window. To start scanning, click the Start button in this window. The Scanning files… progress indicator will show the scanning progress. To cancel scanning, click Stop. When finished, the program will display the Signature Verification Results window (Fig. 6.12), containing a complete list of all the unsigned files the program has detected.

   
   Figure 6.12: The Signature Verification Results window

Starting the System with Configuration Problems

When the Windows NT 4.0, Windows 2000, or Windows XP/Windows Server 2003 operating system detects a severe error that it can't correct, it generates a system message known as a "blue screen". The Blue Screen of Death (BSOD) may also appear when Windows NT/2000/XP/Windows Server 2003 stops during the boot process to prevent further data corruption. A typical example of the "blue screen" as it appears in Windows 2000, Windows XP, and Windows Server 2003 is shown in Fig. 6.13.

Figure 6.13: Typical "blue screen of death" in Windows NT 4.0

In earlier Windows NT versions, the STOP consisted of 5 parts. The Windows 2000 STOP screen consists of only three parts: bugcheck information, recommended user action, and debug port information. Even so, the interpretation of STOP messages and the identification of the true source of problems still remains a difficult task. If the STOP message appears during the startup process, the following are the most probable sources of the problem:

• The user has installed add-on software that has destroyed one of the most important parts of the system registry - the HKEY_LOCAL_MACHINE root key. This usually happens when an application program attempts to install a new system service or device driver. As a result, the "blue screen" either informs you that the system could not load the registry, or one of the registry files, will be indicated.

• The user configured the system hardware incorrectly. As a result, critical system files were overwritten or were corrupted.

• The user tried to install a system service or device driver that is not compatible with the hardware installed on the computer. When the user tries to reboot the system, it will attempt to load the incorrect file. This will destroy the correct version of this system file that was loaded before the failure.

Note 

Active use of the Windows 2000/XP/Windows Server 2003 system file-protection features described in the previous section is one of the most efficient and reliable methods of preventing boot-time STOP screens. If you really want to avoid startup problems, don't neglect these tools!

What can be done if a problem already exists? Sometimes the message displayed in the case of a boot failure may explicitly refer to the missing or corrupt registry file (the message that informs you of a missing or corrupt SYSTEM hive file, shown at the beginning of this chapter, is an example). In certain cases, STOP messages may also inform you of an instance of registry corruption that is preventing the system from booting. Unfortunately, this isn't always true. If you suspect that the boot problems are related to the registry, first try to restore the damaged system using the LastKnownGood configuration.

Ntldr displays a boot menu that allows you to select the operating system to be started. For x86-based computers, this menu depends on the contents of the Boot.ini file. To use the LastKnownGood Configuration in Windows NT 4.0, press the <Space> key when the boot menu appears. Then select the LastKnownGood Configuration option. To use the LastKnownGood Configuration in Windows 2000, Windows XP, and Windows Server 2003, press <F8> to display the Advanced startup menu, which was described earlier in this chapter.

If you are an experienced Windows NT 4.0 user, you will recall that most of the boot problems in the system were caused by incompatible or incorrect device drivers. Incompatible drivers can either result in a system crash immediately after installation or after a certain period of time, during which they seem to work correctly. The second situation, when the corrupt driver works for some time without causing any problems, has always been difficult to explain. Why did it work at all? What actually caused the problem? Sometimes it may even seem that there are no reasonable explanations. However, remember one variant of Murphy's Law: "If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it".

Suppose that there is a bug in the driver (after all, "there is always one more bug") that didn't reveal itself right away. Both the hardware and software configuration of your computer may change with time, and these changes may wake the wretched thing up (because, if something can go wrong, it will). Remember, Windows 2000/XP/Windows Server 2003 can also be prevented from booting by an incompatible driver. However, Windows 2000 and, especially, Windows XP/Windows Server 2003 are more reliable and robust than Windows NT 4.0 because booting the system in the safe mode (the concept borrowed from Windows 9x) presents a more convenient means for quick recovery after such errors.

If an incompatible driver causes a problem when you reboot the system for the first time after installing it, you are lucky. In this case, the LastKnownGood Configuration will be very helpful. When you select this option from the safe-boot menu, the system will use the HKEY_LOCAL_MACHINESYSTEM\CurrentControlSet registry key and restore all the configuration information stored since the last successful boot. If using the LastKnownGood Configuration option didn't help and you know for certain which driver has caused the problem (the sigverif utility discussed earlier in the chapter gives you a list of these drivers), you can try other methods of quick recovery. For example, try using safe-mode options, such as Safe Mode, Safe Mode with Networking, or Safe Mode with Command Prompt. After the system boots with the minimum set of services and drivers, you can try deleting the corrupt driver using administrative tools such as Hardware Wizard or Device Manager. If both system and boot partitions are formatted using the FAT file system, you can try booting from an MS-DOS system disk and manually delete or rename the driver that is causing the problems.

Note 

The LastKnownGood Configuration option provides the quickest and easiest method of recovering a corrupt registry for both Windows NT 4.0 and Windows 2000/XP/Windows Server 2003 (if it works, of course). Unfortunately, this method has some limitations. For example, it restores only one part of the registry (namely, the ControlSet00x branch under HKEY_LOCAL_MACHINE\SYSTEM). As a result, it will only help you to recover the damaged system if the problem is limited to this registry branch and if you use this method immediately. Note that all configuration changes introduced in the system since the last successful boot will be lost if you use this method.

If the information provided above does not help you to solve the problem, then it is time to use one of the methods for restoring the corrupt registry discussed in Chapter 2.

Note 

A disk partition other than the boot partition is a safe place for storing the backup copies of your registry (ideally, you should store registry backups on another physical disk). This will help you to safeguard the registry backups from hardware failures, which might make your backup copies unavailable.

Recovery Console

Windows 2000/XP/Windows Server 2003 Recovery Console provides a commandline interface, providing administrators and users with administrative privileges with the ability to recover a system that will not boot. Using the Recovery Console, you can start and stop system services, read and write data to the local hard drives (including NTFS drives), and repair damaged boot sectors and MBR.

This new function is especially useful when you need to copy one or more system files to the local hard drive in order to recover a damaged system. You can copy these files from a CD or disk. Recovery Console will also be very helpful if you need to reconfigure a service or driver that causes boot problems.

Note 

You need to log in as an Administrator to access the Recovery Console.

Methods of starting, installing, or deleting the Recovery Console were discussed in detail in Chapter 2. In this chapter, we will concentrate on using this tool for recovering a system that has configuration problems.

Using Recovery Console

Recovery Console provides an MS-DOS-like command-line interface. Like any other tool of this sort, Recovery Console has a help command that displays a list of available commands. You can also find a complete list of Recovery Console commands in the Windows 2000/XP/Windows Server 2003 online Help system (search using the keywords "Recovery Console").

A brief listing of Recovery Console commands is provided below:

• Attrib - changes file or folder attributes

• Batch - executes commands contained in the text file you specify

• Bootcfg - manipulates the Boot.ini file

• ChDir (CD) - changes to another directory

• Chkdsk - starts the Chkdsk program

• Cls - clears the screen

• Copy - copies a single file you've specified

• Delete (DEL) - deletes a single file

• Dir - lists the contents of the current directory

• Disable - disables the system service or driver

• Diskpart - manages partitions on your hard disk

• Enable - enables the service or driver

• Exit - exits Recovery Console and reboots the computer

• Expand - expands the compressed file

• Fixboot - repairs the corrupt boot sector on the system partition

• Fixmbr - repairs the corrupt Master Boot Record

• Format - formats the hard drive

• Help - displays a list of Recovery Console commands

• Listsvc - displays a list of all of the available services and drivers

• Logon - allows you to log on to the Windows 2000/XP system

• Map - displays a list of drive mappings

• MkDir (MD) - creates a new directory

• More - displays text files in screen-size portions

• Rename (REN) - renames the file

• RmDir (RD) - deletes the directory

• Set - displays and sets the Recovery Console environment variables

• SystemRoot - marks the current directory as SystemRoot

• Type - prints the text file on the screen

To display information concerning the use of a certain command, use the following syntax:

   HELP command name 

(for example, HELP FIXBOOT) or

   command name /?

(for example, LISTSVC /?).

Note 

There are certain limitations that restrict the usage of the Recovery Console. For example, in Win2K, you could copy the files from disks to the local hard disk, but any attempt at copying the files from the hard drive to disk failed. You can only create a new directory within the %SystemRoot% folder (\WINNT, for example), but this operation fails if you attempt to create a new directory at the root level (C:\). You can only copy files to the root folder or to the %SystemRoot% directory. Finally, the copy command doesn't support wildcard characters and, consequently, doesn't allow you to copy multiple files.