Files Required to Start up Windows NT2000XP

Files Required to Start up Windows NT/2000/XP

If the POST routine was completed successfully, then your computer's hardware was initialized successfully as well. Now it's time to start the operating system. This process requires the presence of all the files necessary to boot the system. The Startup procedure will fail if any of these files are missing or corrupt.

The files required to start Windows NT/2000/XP (for x86 platforms) are listed in Table 6.1.

Table 6.1: Files Required to Start Up Windows NT/2000/XP (x86 Platforms)

File	Location
NTLDR	Root directory of the startup disk
Boot.ini	Root directory of the startup disk
Bootsect.dos[*]	Root directory of the startup disk
Ntdetect.com	Root directory of the startup disk
Ntbootdd.sys (for SCSI only)	Root directory of the startup disk
Ntoskrnl.exe	%SystemRoot%%\System32
Hal.dll	%SystemRoot%\System32
The\SYSTEM registry hive	%SystemRoot%\System32\Config
Device drivers	%SystemRoot%\System32\Drivers
[*]This file is required only in multi-boot systems, where MS-DOS, Windows 3.1x, or Windows 9x are used as alternative operating systems. (This file is needed for booting an alternative operating system.) You can also use the NT loader to boot UNIX or Linux. Copy the first sector of your native root Linux or FreeBSD partition into a file in the NT/2000 partition and name the file, for example, C:\Bootsect.inx or C:\Bootsect.bsd (by analogy to C:\Bootsect.dos). Then edit the [operating systems] section of the Boot.ini file by adding strings such as: C:\BOOTSECT.LNX="Linux" C:\BOOTSECT.BSD="FreeBSD"

Note 

Due to the differences between Itanium-based and x86-based systems, certain files required for the x86-based startup process are not required for Itanium-based computers. These files include the following—Boot.ini, Ntdetect.com, and Ntldr. The boot.ini file is not required, since its information on Itanium-based systems is now stored in NVRAM. Ntdetect.com is not needed, because unlike x86-based systems, all Itanium-based systems are fully ACPI-compliant, and, therefore, there is no need for basic hardware detection. All hardware is detected and initialized by Windows XP according to the ACPI specification requirements. The Ntldr file is the x86-based loader. It is not needed, since Itanium-based systems use another loader—IA64ldr.efi.

The files required to load Windows XP on Itanium-based systems are listed in Table 6.2. These files are located in the EFI system partition, which is the first partition of the startup drive.

Table 6.2: Windows XP Startup Files for Itanium-Based Systems

File and Folder Names	Location on Drives	Description
FPSWA.efi	Resides on the root of the EFI system partition	Supports EFI floating point operations
MSUtil (folder)	Resides on the root of the EFl system partition	Contains EFI tools
IA64ldr.efi	EFI\Microsoft\WinNT50.x folder on the ESP	This is the operating system loader. This path depends on the number of operating systems installed
Ntoskrnl.exe	%SystemRoot%\System32	The core of the Whistler operating system, also known as the kernel. The operating system code that runs as part of the kernel does so in a special privileged processor mode, with direct access to system data and hardware
Hal.dll	%SystemRoot%\System32	Hardware abstraction layer (HAL) dynamic-link library file. The hardware abstraction layer (HAL) isolates, or abstracts, low-level hardware details from the rest of the operating system, and provides a common programming interface to devices of the same type (such as video adapters)
System registry file	%SystemRoot%\System32\Config\System	The registry HKEY_LOCAL_MACHINE\SYSTEM key
Device drivers	%SystemRoot%\System32\Drivers	Hardware driver files for various devices

Note 

Windows NT, Windows 2000, and Windows XP define the "system" and "boot" partitions differently from other operating systems. These are the most important things that you should know. The system partition contains the files necessary to start Windows NT/2000/XP. The boot partition, which contains the %SystemRoot% and %SystemRoot%\System32 directories, can be another partition on the same or a different physical disk. The term %SystemRoot% is an environment variable.

Initial Startup Process

When the POST routine has successfully completed, the system BIOS tries to locate the startup disk. The search order for locating the startup disk is specified by the system BIOS. In addition to floppy disks and hard disks attached to SCSI or ATA controllers, firmware might support starting an operating system from other devices, such as CD-ROM, network adapters, or Zip or LS-120 disks.

The system BIOS allows you to reconfigure the search order (also known as the boot sequence). You can find detailed information concerning boot sequence editing in the documentation supplied with your computer. If drive A: is the first item in the boot sequence list, and there's a disk in it, the system BIOS will try booting from the disk. If there's no disk in drive A:, the system BIOS will check the first hard drive that's powered up and initialized. The first sector on the hard disk, which contains the Master Boot Record (MBR) and partition table, is the most critical data structure to the startup process.

The system BIOS reads the Master Boot Record, loads it into memory, and then transfers execution to the Master Boot Record. The code scans the partition table to find the system partition. When it's found, MBR loads sector 0 of the system partition and executes it. Sector 0 on the system partition is the partition boot sector, containing the startup code for the operating system. This code uses a method defined by the operating system.

Note 

If the startup disk is a floppy disk, the first sector of this disk is the Windows NT/2000/XP partition boot sector. For a successful startup, this disk must contain all the boot files required for starting Windows NT/2000/XP.

If the first hard disk has no system partition, MBR will display one of the following error messages:

• Invalid partition table

• Error loading operating system

• Missing operating system

Generally, MBR doesn't depend on the operating system. For example, on x86 computers the same MBR is used to start Windows NT/2000/XP, Windows 9x, MS-DOS, and Windows 3.1x. On the other hand, the partition boot sector depends on both the operating system and the file system. On an x86 platform, the WindowsNT/2000/XP partition boot sector is responsible for the following actions:

• Detecting the file system used to find the operating system boot loader (NTLDR) in the root directory of the system partition. On FAT volumes, the partition boot sector is 1 sector long. On FAT32 volumes, this data structure takes up 2 physical sectors, because the startup code requires more than 512 bytes. On NTFS volumes, the partition boot sector data structure can consume up to 16 sectors, with the extra sectors containing the file system code required to find NTLDR.

• Loading NTLDR into memory.

• Executing the boot loader.

On x86 computers, the system partition must be located on the first physical hard disk. Don't confuse the system partition and the boot partition. The boot partition contains Windows NT/2000/XP system files and can be the same as the system partition. It can also be on a different partition or even on a different hard disk.

If the first hard disk has no system partition that should be used to start the computer, you need to power down this disk. This will allow the system BIOS to access another hard disk, which will be used to start the operating system.

If there's a disk in drive A:, the system BIOS will try loading the first sector of this disk into the memory. If the disk is bootable, its first sector is the partition boot sector. If the disk isn't bootable, the system will display errors such as:

    Non-System disk or disk error    Replace and press any key when ready 

(if the disk is DOS-formatted)

or

    Ntldr is missing    Replace and press any key when ready 

(if the disk is formatted under Windows NT/2000/XP).

If you need to boot the system from a bootable CD (for example, to install Windows XP from the distribution CD or use the CD-based Recovery Console), you must set the CD-ROM as the primary boot device—the first item listed in the boot order. When you start your system using the bootable Windows XP CD, Setup checks the hard disk for existing Windows XP installations. If Setup finds an existing installation, it provides you with the option of bypassing CD-ROM startup by not responding to the Press any key to boot from CD-ROM prompt. If you do not press a key within three seconds, Setup does not run and the computer passes control from the CD-ROM to the hard disk.

 

If you don't want to start Windows XP Setup to install this operating system or repair the damaged Windows XP installation, remove the CD from your CD drive, since this will allow you to minimize the time required to start Windows XP. Also note that the presence of a non-bootable CD in the CD-ROM drive can significantly increase the time required to start Windows XP.

Boot Loader Process

The boot loader allows you to select the operating system to be started and loads the operating system files from the boot partition. This process is different for x86 systems and RISC-based computers. The tasks performed at this phase include installing a 32-bit memory model with flat memory space, detecting hardware configuration data, generating its configuration in the memory, and transferring the handle of this description to the loader. NTLDR then loads the kernel image, the HAL, the device drivers, and the file system drivers for the volume, from which the operating system will start. Besides other tasks at this phase, the system loads the drivers for which the start registry value is set to 0. The start registry entry for device drivers is located in the registry under the following key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ServiceName 

The ServiceName here is the name of the service. For example:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi 

NTLDR Functions

NTLDR controls the process of selecting the operating system to be loaded and detecting hardware prior to initializing the Windows NT/2000/XP kernel. NTLDR must be located in the root folder of the system partition. Besides the operating system loader, the partition must contain all the files listed in Table 6.1.

When NTLDR starts execution, it clears the screen and performs the following actions:

• Switches the processor to 32-bit flat memory mode. All x86-based computers first start in real mode, similar to an 8088 and 8086 start mode. Because NTLDR is a 32-bit program, it must switch the CPU to a 32-bit flat memory mode before it can perform any actions.

• Starts an appropriate minifile system. The code intended for accessing files on FAT and NTFS partitions is built into NTFS. This code enables NTLDR to access the files.

• Reads the Boot.ini file located in the root directory of the system partition and displays the boot menu. This screen is also known as a boot loader screen. If your computer is configured for starting multiple operating systems, and you select an alternative operating system (other than Windows NT/2000/XP), NTLDR will load the Bootsect.dos file and transfer all control to the code contained in this file. The alternative operating system will start as normal, because the Bootsect.dos file contains an exact copy of the partition boot sector necessary to start the operating system.

• If you select one of the Windows NT/2000/XP installations, NTLDR finds and executes Ntdetect.com to collect information on the hardware currently installed.

• NTLDR loads and starts the operating system kernel (Ntoskrnl.exe). After starting the kernel, NTLDR passes on the hardware information collected by Ntdetect.com.

 

One of the most significant improvements introduced with Windows XP is the so-called Fast Boot feature, which was implemented by increasing the boot loader performance. The Ntldr version included with Windows XP is optimized for fast disk reading. When the system is loaded for the first time, all information on the disk configuration, including file system metadata, is cached. The Logical Prefetcher, which is new in Windows XP, brings much of this data into the system cache with efficient asynchronous disk I/Os that minimize seeks. During boot, the logical prefetcher finishes most of the disk I/Os that need to be done for starting the system in parallel with device initialization, providing faster boot and logon performance. Furthermore, each system file during boot is now read only once, within a single operation. As a result, Windows XP boot loader is approximately 4-5 times faster than Windows 2000 boot loader.

As you can probably guess, the prefetcher settings are also stored in the registry. You can find them under the following key (Fig. 6.2):

Fig. 6.2: Logical Prefetcher settings in the registry

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ Memory Management\PrefetchParameters 

The values that interest us the most are the RootDirPath (data type REG_SZ, the default value is Prefetch) and EnablePrefetcher (data type REG_DWORD). The EnablePrefetcher setting can take the following values:

• 0x00000001—application launch prefetching

• 0x00000002—boot prefetching

If both options are enabled, the setting would be 0x00000003. The setting takes effect immediately. Note that in the Server product line, only the boot prefetch is enabled by default. Application prefetch can be enabled by the registry setting cited here. The system boot prefetch file is in the %SystemRoot%\Prefetch directory (and the path to it is specified by the RootDirPath parameter mentioned above). Although these prefetch-readable files can be opened using Notepad, they contain binary data that will not be recognized by Notepad. If you are going to view these files, make them read-only or copy them to a different location before opening.

Selecting the Operating System to Start

NTLDR displays a menu where you can select the operating system to be started. What you see on this screen depends on the information contained in the Boot.ini file, which was described in Chapter 4. An example of the screen is shown below:

    Please select the operating system to start:         Windows XP Professional         Windows 2000 Professional         Windows NT Server Version 4.0         Windows NT Server Version 4.0(VGA mode)    Use ˄ and ˅ keys to move the highlight to your choice.    Press Enter to choose.    Seconds until highlighted choice will be started automatically: 29      For troubleshooting and advanced startup options for Windows, press F8 

The process of selecting the operating system to start is similar to the process for earlier Windows NT versions (for example, Windows NT 3.51 and Windows NT 4.0). The operating system that appears first in the list is the default operating system. To select another operating system, use the arrow keys (˄ and ˅) to move the highlight to the string you need. Then press <Enter>.

If you don't select an item from the boot menu before the counter specified in the following string reaches zero, you'll see the message:

    Seconds until highlighted choice will be started automatically: 29 

NTLDR will load the default operating system. Windows NT/2000/XP Setup specifies the most recently installed copy of the operating system as the default option. You can edit the Boot.ini file to change the default operating system. A detailed description of the Boot.ini file format was provided in Chapter 4.

Note 

The startup menu does not appear if you only have one copy of Windows XP installed on your computer. In this case, Windows XP ignores the time-out value in the Boot.ini file and starts immediately.

Windows XP Advanced Startup Options

Any experienced Windows NT user will notice that there is one small but very significant difference between the boot loader screens in Windows 2000/XP and Windows NT 4.0. This is the string placed at the bottom of the screen:

    For troubleshooting and advanced startup options for Windows 2000,    press F8 

In Windows 95/98, there was a similar option. If you have any problems booting Windows 2000 and Windows XP, try using the advanced startup options menu displayed when you press the <F8> key.

The menu looks like this:

    Windows Advanced Options Menu    Please select an option:    Safe Mode    Safe Mode with Networking    Safe Mode with Command Prompt    Enable Boot Logging    Enable VGA Mode    Last Known Good Configuration (your most recent settings that worked)[*]    Directory Services Restore Mode (Windows domain controllers only)    Debugging Mode    Start Windows Normally[**]    Reboot[**]    Return to OS Choices Menu[**] 

Notice that this menu will remain on screen until you select one of the available options.

When Windows 2000/XP boots in safe mode, it uses the standard settings (VGA driver, no network connections, default system services only). When the system starts in safe mode, only vitally important drivers necessary for starting Windows are loaded. The safe boot mode allows the system to boot even with an incompatible or corrupt service or driver. Thus, the safe mode increases the probability of successful booting, because you load the system with the minimum set of services and drivers. For example, if your Windows 2000 installation became unbootable after installing new software, it's highly probable that your attempt to boot the system in safe mode will be successful. After booting the system, you'll be able to change the settings that prevent Windows 2000/XP from booting correctly, or delete the software that caused the problem.

The options of Windows XP advanced startup menu are described below:

• Safe Mode
  As I mentioned, this option is similar to the one that was introduced with Windows 2000. If the user selects this option, only the basic Windows XP services and drivers will be loaded. These services and drivers are vitally important for the operating system (this set includes standard mouse, keyboard and mass storage drivers, base video, and default system services). If you can't start Windows XP using this mode, you'll probably need to restore the damaged system. More detailed information concerning this topic will be provided later in this chapter.

• Safe Mode with Networking
  Similar to the option that existed in Windows 2000, Windows XP will start in safe mode (very much like the previous option), but in addition, there will be an attempt to start networking services and restoring network connections.

• Safe Mode with Command Prompt
  When you select this option, Windows 2000/XP will start using only the basic set of drivers and services (just the same as safe mode except that a command prompt will be started instead of the Windows GUI).

• Last Known Good Configuration (your most recent settings that worked)
  In Windows NT 4.0/Windows 2000, there was a similar option. However, in Windows XP this option has an improvement that deserves special mention. If you select this option in Windows 2000, the operating system starts using registry information saved immediately after successful startup (the Windows NT/2000/XP system startup is considered to be successful if at least one user has successfully logged on to the system). It should be pointed out that in Windows NT/2000 this option only allows you to correct configuration errors, and won't always be successful. Use this option only when you're absolutely sure that you've made an error when configuring the system. The problems caused by missing or corrupt system files or drivers won't be corrected. Also note that if you use this option, all modifications introduced into your registry since the last successful boot of Windows NT/2000 will be discarded.

In Windows XP, this option was enhanced by additional functionality. In contrast to Windows NT/2000, Windows XP creates backup copies of the drivers before updating the currently used set of drivers. In addition to restoring the most recent registry settings, the Last Known Good Configuration startup option also restores the last set of drivers used after the last successful user logon. This allows you to recover from system errors such as unstable or improperly installed applications and drivers that prevent you from starting Windows XP.

• Directory Services Restore Mode (Windows 2000 domain controllers only)
  This option shouldn't be used with Windows XP Professional because it's intended for domain controllers running Windows 2000 Server or later versions. As you can tell from the name of this option, it's used for restoring directory services.

• Debugging Mode
  This option starts Windows XP and establishes the debugging mode.

• Start Windows Normally
  New in Windows XP, this option allows you to start Windows XP normally.

• Reboot
  When the user selects this option, the boot process will restart from the beginning (actually, with the POST routine). Like the previous option, this one was first introduced with Windows XP.

• Return to OS Choices Menu
  New in Windows XP, this option returns you to the boot loader screen, allowing you to select the operating system.

As was said, the last three options were first introduced with Windows XP. Of course, they don't provide anything totally new and are purely cosmetic improvements. However, they certainly make the Advanced Startup Options menu more convenient than the one in Windows 2000.

You may be wondering where the system stores safe mode configurations used to start the system when you select one of advanced boot options. Like everything else in the system, these parameters are stored in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot (Fig. 6.3). This key contains all configuration settings used to boot the system in safe mode. It contains two subkeys: Network and Minimal. The Network key contains the information necessary to boot the system using the Safe Mode with Networking option, while the Minimal key contains the same information, except for networking settings. The SafeBoot key contains the AlternateShell value entry, which specifies the name of the program used instead of the Windows GUI. Normally, this entry has a value of "cmd.exe" (Windows 2000/XP command processor), which corresponds to the Safe Mode with Command Prompt option.

Fig. 6.3: The advanced startup menu options in Windows 2000/XP are specified by the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot registry key

Hardware Detection

When you select one of the Windows NT/2000 installations from the boot menu (or the default operating system starts loading after the timer has expired), NTLDR calls Ntdetect.com to collect information on the currently installed hardware. Ntdetect.com returns the collected information to NTLDR.

This phase of the initialization is different for Windows NT 4.0 and Windows 2000/XP. As I mentioned in Chapter 5, starting with Windows 2000, the system includes two new Executive subsystems: Plug and Play Manager and Power Manager. Plug and Play Manager is integrated with I/O Manager and doesn't participate in the initialization process. However, because Windows 2000 supports Plug and Play, PnP-aware drivers perform a certain part of hardware detection in the operating system. The main difference from Windows NT 4.0 is that it performs hardware detection using Ntdetect.com only. Because of this, a new Boot.ini parameter was introduced in Windows 2000—/FASTDETECT, which is used when Windows NT 4.0 and Windows 2000 co-exist on the same computer. If you have a configuration like this, the Windows 2000 version of Ntdetect.com will be used to load both operating systems. If the /FASTDETECT parameter is set, NTDETECT won't try to recognize Plug and Play devices. If this parameter is omitted, NTDETECT will enumerate all the hardware. So, if you have a multi-boot configuration where both Windows NT 4.0 and Windows 2000 are installed, the /FASTDETECT parameter should be set for the Boot.ini strings that start Windows 2000 and omitted for the strings that start Windows NT 4.0.

Selecting the Hardware Profile

If you've selected the option that starts Windows 2000/XP, and there's only one hardware profile in the system, Ntldr will continue the startup process by starting the operating system kernel (Ntoskrnl.exe) and passing on the hardware information collected by Ntdetect.com.

If Windows 2000 has several hardware profiles, the following information will be displayed on the screen:

    Hardware Profile/Configuration Recovery Menu    This menu allows you to select a hardware profile    to be used when Windows is started.    If your system is not starting correctly, then you may switch to a    previous system configuration, which may overcome startup problems.    IMPORTANT: System configuration changes made since the last successful    startup will be discarded.    Profile 1    Profile 2    Profile 3    Use the up and down arrow keys to move the highlight    to the selection you want. Then press ENTER.    To switch to the Last Known Good Configuration, press 'L'.    To Exit this menu and restart your computer, press F3.    Seconds until highlighted choice will be started automatically: 5 

After displaying this menu, the boot loader will allow you time to select among the available options. You can select one of the existing hardware profiles, switch to the Last Known Good Configuration option, or quit this menu and restart the computer.

The first hardware profile is highlighted. To select other hardware profiles, highlight the option you need and press <Enter>.

You can also select between the default configuration and LastKnownGood Configuration. If you select the Last Known Good Configuration option, Windows 2000/XP will load the registry information that was saved immediately after the last successful boot. If you don't select this option, Windows 2000 will use the default configuration that was saved in the registry the last time you performed a system shutdown. The Last Known Good Configuration is stored in the registry under HKEY_LOCAL_MACHINE\SYSTEM\Select. More detailed information concerning this topic will be provided later in the chapter.

 

Windows XP creates the default hardware profile for desktop computers. This default profile includes all the hardware detected when you installed the system. For portable computers, Windows XP creates two default hardware profiles (Docked Profile and Undocked Profile), and selects the appropriate profile depending on the way you are using your computer (as a dock station or standalone). Notice that despite the fact that full-featured Plug and Play support has eliminated the necessity of manually configuring hardware profiles, they still can be very useful for troubleshooting hardware problems.

Loading the Kernel

When the boot loader obtains information on the currently installed hardware and selected hardware profile, it starts the operating system kernel Ntoskrnl.exe and passes on the hardware information collected by Ntdetect.com.

Information on the currently selected hardware profile is passed to the loader when you press <Enter> in the Hardware Profile/Configuration Recovery Menu screen. The loader can also make this choice automatically (if the timer has expired or if there's only one hardware profile).

When the kernel starts loading, you'll see several dots on the screen. These dots serve as a progress indicator displayed when the boot loader loads Ntoskrnl.exe and the hardware abstraction layer into the memory. At this phase, neither of these programs are initialized. Ntldr then scans the registry and retrieves information on the size of nonpaged pool and registry quota (for Windows NT/2000). Next, Ntldr loads the HKEY_LOCAL_MACHINE\SYSTEM registry hive from %SystemRoot%\System32\Config\System.

At this point, the boot loader enables the registry API and creates a control set that will be used to initialize the computer. Both of these tasks are preliminary steps necessary for preparing the drivers for loading. The value specified in the HKEY_LOCAL_MACHINE\SYSTEM\Select registry key (Fig. 6.4) defines which control set in HKEY_LOCAL_MACHINE\SYSTEM should be used to load the system. By default, the loader will select the Default control set. If you select the LastKnownGood configuration, the loader will use the LastKnownGood control set. Based on your selection and on the value of the Select key, the loader will determine which control set (controlset00x) will be enabled. The loader will then set the Current value of the Select key to the name of the control set it will be using.

Fig. 6.4: The HKEY_LOCAL_MACHINE\SYSTEM\Select registry key

The loader then scans all the services defined by the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services registry key and searches device drivers with a Start value of 0x0 (this means that the drivers should be loaded, but not initialized). Normally, drivers with these values are low-level device drivers (for example, disk drivers). The Group value for each device driver defines its load order. The HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ControlServiceGroupOrder registry key defines the loading order.

When this phase is completed, all of the basic drivers are loaded and active. If one of the critical drivers can't be initialized though, the system starts rebooting.

Initializing the Kernel

When the Windows NT 4.0 kernel starts initializing, the screen turns blue, and a text similar to the one presented below appears:

    Microsoft ® Windows NT (TM) Version 4.0 (Build 1345)    1 System Processor (64 MB Memory) 

If this message appears, it means that all of the previous stages of the boot sequence have completed successfully. One obvious difference between Windows 2000/XP and Windows NT 4.0 is the fact that all system messages that appear during the Windows NT 4.0 boot process are displayed in 80×50 text mode, while Windows 2000 and Windows XP display these messages in VGA mode. The Windows NT 4.0 Hardware Abstraction Layer (HAL) provides all the support for this mode and is also responsible for displaying the messages. Windows 2000 has a special driver—Bootvid.sys—which performs these tasks. In Windows 2000 and Windows XP, you know that the Kernel is initializing when the animated screen displaying the OS logo appears. This cosmetic improvement doesn't change the basic principles of the loading process in comparison to the previous versions of the Windows NT operating system.

If you want to check things out for yourself, add the /SOS option to the Boot.ini file string that starts Windows 2000/XP. Then save your changes and reboot the system. You'll see the whole sequence of loading for all the drivers. The graphics logo will be used as a background, and in the foreground you'll see something very much like the following:

    Microsoft ® Windows XP Professional (TM) (Build 2600)    1 System Processor (256 MB Memory) 

The kernel creates the HKEY_LOCAL_MACHINE\HARDWARE registry key based on information obtained from the boot loader. The HKEY_LOCAL_MACHINE\HARDWARE key contains hardware data collected when the system starts. This data includes information on the hardware components and IRQs used by each hardware device.

The kernel then creates a Clone control set by making a copy of the control set indicated by the Current value.

Note 

In Windows NT 4.0, the Clone control set was visible; but after a successful boot, it became unavailable (the system displayed an error message any time an attempt was made to open this key). In Windows 2000/XP, the registry editors simply don't display this.

The Clone control set should never be modified, since it must be an identical copy of the data used for configuring the computer. It shouldn't contain any changes introduced in the course of system startup.

As the kernel initializes, it performs the following operations:

• Initializes low-level device drivers loaded at the previous stage

• Loads and initializes other device drivers

• Starts programs, such as Chkdsk, which should run before starting any services

• Loads and initializes system services

• Creates the paging file (Pagefile.sys)

• Starts all the subsystems necessary for Windows 2000/XP

Loading and Initializing the Device Drivers

Now the kernel initializes the low-level device drivers that were loaded at the previous stage (kernel loading). If any of these drivers can't be initialized, the system performs corrective action based on the data defined by the following registry entry:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services    \DriverName\ErrorControl 

Ntoskrnl.exe then scans the registry, this time for device drivers that have an HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DriverName\Start value of 0x01. The Group value for each device driver defines the order in which the drivers are loaded. The HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder registry subkey defines the loading order.

In contrast to the kernel loading phase, device drivers that have a Start value of 0x01 aren't loaded using BIOS calls. Instead, they use device drivers loaded and initialized at the kernel loading phase. Error handling for device drivers belonging to this group is based on the ErrorControl value for each device driver.

 

Windows XP initializes device drivers simultaneously to improve boot time. Instead of waiting for each device to initialize separately, many can now be brought up concurrently. The slowest device has the greatest effect on boot time.

Loading Services

The Session Manager (Smss.exe) starts the higher-level subsystems and services of the operating system. All information used by the Session Manager is also stored in the registry under the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager. The Session Manager uses information stored under the following registry items:

• The BootExecute data entry

• The Memory Management key

• The DOS Devices key

• The Subsystems key

The BootExecute Data Entry

The BootExecute registry entry contains one or more commands that the Session Manager has to run before it starts loading services. The default value for this registry item is Autochk.exe, which is simply the Windows NT/2000/XP version of the Chkdsk.exe program. The example shown below shows the default setting for this registry item:

    BootExecute: REG_MULTI_SZ: autochk autochk* 

The Session Manager is capable of running more than one program. The example shown below shows how to start the Convert utility, which will convert the x volume to NTFS format next time the system starts:

    BootExecute: REG_MULTI_SZ: autochk autochk* autoconv \DosDevices\x:    /FS:ntfs 

When the Session Manager executes all the commands specified, the kernel will load the other registry hives stored in the %SystemRoot%\System32\Config directory.

The Memory Management Key

For the next step, the Session Manager needs to initialize the information in the paging file, which is necessary to the Virtual Memory Manager. The configuration information is stored in the following data items:

    PagedPoolSize: REG_DWORD 0    NonPagedPoosSize: REG_DWORD 0    PagingFiles: REG_MULTI_SZ: c:\pagefile.sys 32 

In versions of Windows earlier than Windows XP, as device drivers, system services, and the user shell load, the required memory pages will not be in memory until loaded from the disk drive. Another key improvement in Windows XP is the overlap of pre-fetching these pages before loading the device drivers that require them.

The prefetcher in Windows XP has the following functions:

• Dynamically traces each boot to build a list of what to prefetch. Boot files are laid out together on disk during the idle time, or when the Bootvis.exe tool is used to arm boot traces. The prefetcher needs at least two boots after installation to learn which files to lay out. The prefetcher monitors the previous eight boots on an ongoing basis.

• Enables fast asynchronous I/O during boot to load required files in highly efficient transfers.

As was already mentioned, the prefetcher settings are stored in the registry under KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters key.

The DOS Devices Key

The Session Manager needs to create symbolic links that direct certain command classes to the appropriate file system components. The configuration data resides in the following registry entries:

    PRN: REG_SZ: DosDevices\LPT1    AUX: REG_SZ: DosDevices COM1    NUL: REG_SZ: Device Null    UNC: REG_SZ: Device Mup    PIPE: REG_SZ: Device NamedPipe    MAILSLOT: REG_SZ Device MailSlot 

The SubSystems Key

Since the architecture of all Windows NT/2000/XP subsystems is message-based, it's necessary to start the Windows (Win32) subsystem that controls all input/output operations and video display access. The process of this subsystem is called CSRSS. The Win32 subsystem starts the WinLogon process, which, in turn, starts other important subsystems.

Configuration information for subsystems is defined by the Required value under the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\SubSystems.

Logging on

The Win32 subsystem starts the Winlogon.exe process, which, in turn, starts the Local Security Administration process (LSA)—Lsass.exe. When the kernel initializes successfully, it's necessary to log on to the system. The logon procedure may be done automatically, based on the information stored in the registry, or it can be done manually. When you log on manually, the system displays the Begin Logon dialog or the Welcome screen (Windows XP-specific new feature). The Graphical Identification and Authentication (GINA) component collects your user name and password, and passes this information securely to the LSA for authentication. If you supplied valid credentials, you are granted access using either Kerberos V5 (for network) or NTLM (local machine) authentication.

 

Windows NT/2000 may continue initializing network drivers, but you can now log on to the system. As for Windows XP, if your PC doesn't belong to a domain, network initialization will be done at the same time as boot. However, the PCs that are members of a domain will still wait.

At this stage, the Service Control Manager loads the services that start automatically. The Start value under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DriverName is set to 0x2. Now the services are loaded according to their dependencies, which are described by the values DependOnGroup and DependOnService under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DriverName registry key.

Note 

As with Windows NT/2000, Windows XP isn't successfully loaded until you log on to the system. After that, the Clone control set will be copied to the LastKnownGood configuration.

The services listed in the following registry keys start and run asynchronously with the Welcome to Windows and Log On to Windows dialog boxes:

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices

The Plug and Play device detection process also runs asynchronously with the logon process and relies on system firmware, hardware, device drivers, and operating system features to detect and enumerate new devices. When these components are properly coordinated, Plug and Play allows for device detection, system resource allocation, driver installation, and device installation with minimal user intervention. Detailed information on the Plug and Play detection process was provided in Chapter 5.

After you log on, the following events occur:

• Control sets are updated. The control set referenced by the LastKnownGood entry is updated with the contents in Clone. Clone, a copy of the CurrentControlSet entry, is created each time you start your computer.

• Group Policy settings take effect. Group Policy settings that apply to the user and computer take effect. For more information about Group Policy, see Chapter 10.

• Startup programs run. Windows XP starts logon scripts, startup programs, and services referenced in these registry and folder locations:

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

  • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

  • %systemdrive%\Documents and Settings\All Users\Start Menu\Programs\Startup

  • %systemdrive%\Documents and Settings\%username%\Start Menu\Programs\Startup

  • %windir%\Profiles\All Users\Start Menu\Programs\Startup

  • %windir%\Profiles\%username%\Start Menu\Programs\Startup

Note 

The last two %windir% folders exist only on Windows 2000/XP systems upgraded from Windows NT 4.0.

Loading Other Services and Drivers

As I mentioned before, the system may continue loading and initializing certain services and drivers from the moment you log on. Future sections of this chapter concentrate on the following important topics:

• Control sets in the registry. Control sets contain information on the system configuration used during system startup. Proper understanding of control sets is necessary to appropriately use the LastKnownGood configuration.

• How the registry data specifies the loading order of services and drivers. We'll discuss the Start value that specifies the loading order of the service or driver. We'll also discuss the Error Control value that defines the default behavior of the system in case the driver or service can't be loaded or initialized correctly.

Control Sets in the Registry

The Control set contains system configuration data, including information on the device drivers that need to be loaded and the services that need to be started. Control sets are stored in the registry under the HKEY_LOCAL_MACHINE\SYSTEM registry key. The system may have several control sets, and their number depends on how frequently you modify the system settings or how often problems arise. A typical Windows NT/2000 installation contains the following control sets:

• Clone

• ControlSet001

• ControlSet002

• ControlSet003

• CurrentControlSet

The CurrentControlSet subkey points to one of the ControlSet00x subkeys. The Clone control set is an exact copy of the control set used for starting and initializing the system (Default or LastKnownGood). The kernel initialization process creates this control set at each system startup. The Clone control set becomes inaccessible after the first successful logon.

The HKEY_LOCAL_MACHINE\SYSTEM\Select registry key contains the following entries:

• Current

• Default

• Failed

• LastKnownGood

These parameters contain REG_DWORD data that point to a specific control set. For example, if the Current value is set to 0x1, then the CurrentControlSet points to ControlSet001. Similarly, if the LastKnownGood value is set to 0x2, it points to the ControlSet002. Usually, the Default value is the same as the Current value. The Failed parameter indicates the control set specified by the Default parameter when the user last used the LastKnownGood control set.

Earlier in the chapter, we discussed the process of system initialization using the Default and LastKnownGood configuration. When the kernel uses the default configuration, it uses the Default value to identify the control set that should be used for initialization.

There are only two situations when the kernel uses the LastKnownGood configuration.

• During system recovery after a critical failure (for example, if one of the critical device drivers couldn't be loaded or initialized). We'll discuss this topic in greater detail later in the chapter.

• When the user selects the LastKnownGood configuration from the Hardware Profile/LastKnownGood menu.

If you have either of the following problems, using the LastKnownGood control set may help you recover the damaged system:

• Problems caused by a device driver added into the system since the last successful startup

• Boot problems caused by invalid registry modifications

The LastKnownGood control set can help you recover from configuration errors.

Note 

If you suspect that changes made since the last successful user logon process are causing problems, do not log on, since this causes the LastKnownGood control set to be overwritten. Instead, restart the computer, and press F8 when prompted. Select Last Known Good Configuration from the Advanced Options startup menu. If you select the Last Known Good option during startup, all modifications introduced since the last successful startup will be discarded.

After the first user logs on, all configuration changes introduced using Control Panel applets will be reflected only by the CurrentControlSet control set. Thus, if you need to modify the control set, the only control set worth editing is the CurrentControlSet.

If you have problems finding subkeys of the CurrentControlSet, use the Find Key command from the View menu of the registry editor (Regedit.exe).

The Start Value

Each of the HKEY_LOCAL_MACHINE\SYSTEM\<control set>\Services\<DriverName> (where DriverName is the name of specific driver) keys contains the Start value that defines the loading order for the driver or service. The Start parameter can take one of the following values:

• 0x0 (Boot). The driver or service is loaded by the operating system boot loader before the kernel initialization phase starts. Disk drivers, for example, belong to this group.

• 0x1 (System). The service or driver is loaded by the I/O subsystem during kernel initialization. This value type is used by mouse drivers, for example.

• 0x2 (Auto load). The service or driver is loaded by the Service Control Manager. This type of loading order is generally used for services that start automatically under any conditions, independent of the service type. This type of value is used, for example, by parallel port device drivers. An example of a service that uses this value is the Alerter service.

• 0x3 (Load on Demand, Manual). The Service Control Manager will load this service only after obtaining explicit instructions to do so. Services of this type are always available, but load only when the user starts them manually.

• 0x4 (Disabled). This service or driver will never be loaded. Windows NT/2000 disables services or drivers if they can't be loaded by the Service Control Manager (for example, if the appropriate hardware isn't installed). If the Start parameter is set to this value, the Service Control Manager never tries to load the service or driver. The only exception to this rule is represented by the file system drivers, which the system always tries to load, even when the Start entry for these drivers is set to 0x4.

The ErrorControl Value

The list shown below provides brief descriptions of all the possible values of the ErrorControl registry entry located under HKEY_LOCAL_MACHINE\SYSTEM\<control set >\Services\< DriverName>.

• Ignore (0x0). If an error occurs when loading or initializing the device driver, the startup procedure continues without displaying an error message.

• Normal (0x1). If an error occurs while loading or initializing the device driver, the startup procedure will continue after displaying an error message. The ErrorControl value entries for most device drivers are set to this value.

• Severe (0x2). If the kernel detects an error while loading or initializing the driver or service, it switches to the LastKnownGood control set. The startup process then restarts. If the LastKnownGood control set is already in use, the startup procedure continues, and the error is ignored.

• Critical (0x3). The procedure used in this case is similar to the one used for Severe errors, with one exception. If the system has already switched to the LastKnownGood control set and this didn't eliminate the error, the boot process stops, and the system displays a failure message.

Preventing System Failures

Now it's 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/XP, but in all earlier versions of the Windows NT operating system as well. Windows 2000 and Windows XP 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, I recommend that you use these tools. This topic will be covered in greater detail later in the chapter.

• Backup 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 into 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.

• Don't disable System Restore. Despite the fact that some users may think that this tool consumes too much free disk space, it still can be very useful if you need to restore the damaged system.

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

• View system event logs on a daily basis (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 into the backup copy, since most backup utilities (including the Backup program supplied with Windows 2000/XP) don't recognize errors in user data.

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

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

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

• Problems with the hard disk containing the system partition.

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

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

Windows XP includes 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 and Windows XP provide a set of tools that protect system files and device drivers from being overwrittten 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/XP includes 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 implemented in Windows 95/98. It's one of the most important and useful features introduced in Windows 2000 and further enhanced in Windows XP. 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 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) functionality that was used in earlier Windows NT versions and, with some improvements, was also included with Windows 2000. The step—by step descriptions of actions that you are required to take 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. Now, if you have Installed an updated version of the driver after installing Windows XP, and suspect that this operation has caused system instability or even 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 procedure of 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 or System Restore instead of rolling back individual drivers.

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

• Recovery Console. Windows 2000/XP Recovery Console provides a command line interface to perform the recovery of a damaged system. Like the previous option, Recovery Console is also a new feature introduced in Windows 2000. 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 and Windows XP

All system files and device drivers in Windows 2000 and Windows XP 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 may 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, 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).

   
   Fig. 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 that allows you to specify the following options:

   
   Fig. 6.6: The Driver Signing Options dialog

   • If you set the Ignore radio button, the system will allow you to install any of the drivers. However, it won't check if the driver you're going to install has a digital signature. (If this option is installed, Windows 2000/XP behaves like Windows NT 4.0). I mentioned that the presence of a digital signature confirms that the file was 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 warning messages any time an attempt is made to install a system file or driver that isn't digitally signed. Notice that despite this warning, the system file or driver will be installed

   • 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 and Windows XP 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 is the recommended one. More detailed information on this topic was provided in Chapter 5. Here, I would only remind you that Windows 2000 and Windows XP attempt driver installation after the Plug and Play subsystem (PnP subsystem) discovers 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 was 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/XP are located in the %SystemRoot% \INF folder If you're installing an OEM driver, then the INF file will probably be located on the floppy disk or CD supplied by the vendor.

• There's also another method of installing device drivers—using the Hardware Installation Wizard located at %SystemRoot%\System32\ Newdev.dll The Hardware Installation Wizard performs the same operations as the user-mode 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 checks the Policy value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Driver Signing (Fig. 6.7). If this entry is missing, Windows 2000 and Windows XP will check the Policy value under HKEY_CURRENT_USER\Software\Microsoft\Driver Signing (Fig. 6.8). Notice that you set these parameters using the Driver Signing Options dialog. If you've logged in to the system as an Administrator, and you instruct the system to use this option by default, the system will set the Policy setting under HKEY_LOCAL_MACHINE; otherwise, it will set this parameter under HKEY_CURRENT_USER. When the system checks these settings, it first checks 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.

Fig. 6.7: The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Driver Signing registry key

Fig. 6.8: The HKEY_CURRENT_USER\Software\Microsoft\Driver Signing registry key

If the policy on unsigned drivers makes it necessary to check the digital signature, Setupapi.dll calls 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 device drivers and system files? Microsoft stores all the digital signatures protecting Windows 2000 distribution files in special catalog files that reside 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 into 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'll find catalog files for all 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 system files included into 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'll either get a warning message, or (if the option has been set) the driver installation will fail.

Other Tools of Protecting Windows 2000 System Files

Windows 2000 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 make your system unbootable.

Windows 2000 is the first Windows operating system where an attempt was made to correct this situation. Certainly, this functionality is also present in Windows XP. 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 accidentally modified or replaced. 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 Windows XP-compatible. 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 Windows XP 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're installing the following types of software:

• Windows 2000 and Windows XP 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 and Windows XP include a special utility for checking the 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.

• /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 question "Where does the system store all the settings that control SFC?". You won't be too surprised when I tell you that they're 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 the functions of protecting Windows 2000 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 are 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 I mentioned before, there are some cases when the system file gets replaced by incorrect or incompatible versions during the installation procedures of third-party add-on software that aren'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 Setup are protected by Microsoft digital signatures. This guarantees that the digitally signed files are Windows 2000-compatible. 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 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.

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

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

   
   Fig. 6.9: 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.10) and set the Save the file signature verification results to a log file checkbox.

   
   Fig. 6.10: 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 set 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 scanning.

   • 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 indicate the scanning progress (Fig. 6.11). 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.

Fig. 6.11: Scanning is in progress

Fig. 6.12: The Signature Verification Results window

Starting the System With Configuration Problems

When the Windows NT 4.0, Windows 2000, or Windows XP 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 stops during the boot process to prevent further data corruption. Typical examples of these screens are shown below: Fig. 6.13 shows the "blue screen" as it appears in Windows NT 4.0, while Fig. 6.14 shows the "blue screen" in Windows 2000 and Windows XP.

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

Fig. 6.14: Typical "blue screen" in Windows 2000 and Windows XP

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

• The user has installed add-on software that's 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 couldn't 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 became corrupt.

• The user tried to install a system service or device driver, and the newly installed service or driver isn't 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 usage of the Windows 2000/XP 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 Windows 2000 startup problems, don't neglect these tools!

However, what can be done if a problem already exists? Sometimes the message displayed in 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 a registry corruption that's preventing the system from booting. Unfortunately, this isn't always true. If you suspect that the boot problems relate 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, press <F8> to display the Advanced startup menu, which was described earlier in this chapter.

If you're an experienced Windows NT 4.0 user, you'll remember 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. After all, why did it work at all, and what actually caused the problem? Sometimes it may even seem that there are no reasonable explanations. However, remember the Original 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 there's a bug in the driver (after all, "there's always one more bug"), which remained unnoticed and 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 can also be prevented from booting by an incompatible driver. However, Windows 2000/XP is actually 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 of 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're 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 Windows 2000 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's 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 (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). So, it will help you to recover the damaged system only if the problem is limited to this registry branch and if you use this method immediately. Notice that all configuration changes introduced into the system since the last successful boot will be lost if you use this method.

If the information mentioned above didn't help you to solve the problem, then it's time to use one of the methods for restoring the corrupt registry that we discussed in Chapter 2. If you're working with Windows NT 4.0, try to restore the system by using an ERD and select the Inspect Registry Files option. After you select this option, the system will display a list of registry files where you can select the hives to be restored.

In contrast to the emergency repair process in Windows NT 4.0, neither the manual nor the automatic recovery of Windows 2000 using an ERD can repair registry errors. To tell you the truth, the Windows 2000 emergency recovery process does recover the system registry, but this recovery is awkward, because the ERD process uses a registry backup copy created by the Setup program during system installation. As you already know, the backup copy is stored in the %SystemRoot%\Repair folder. Because of this, I recommend that you use the Windows 2000 Recovery Console for registry recovery (and never forget to backup the registry). As I mentioned in Chapter 2, which is entirely dedicated to various methods of registry backup and recovery, the Backup program creates registry backup while performing the System State data backup. This backup copy is stored in the %SystemRoot%/Repair/Regback folder. Advanced users may use these registry backup files to restore the system without going through the whole routine of restoring the system state data.

Also, don't neglect the Resource Kit utilities for registry backup and recovery (Regback/Regrest in Windows NT 4.0 and REG in Windows 2000 Resource Kit).

Note 

A disk partition different from 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 Recovery Console provides a command-line interface, allowing administrators and users with administrative privileges the capability of recovering a system that doesn't 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 functionality 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'll 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 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

• ChDir (CD)—changes to the other 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 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 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.

Error Reporting

Windows XP now includes a new feature named Error Reporting service. As Microsoft declares, this service is intended to help you troubleshoot error in your system, and at the same time help Windows XP developers improve future versions of the product. The Error Reporting service monitors your system for user and kernel-mode faults that affect Windows XP components and applications.

When a user mode error occurs (such as an application error), the Error Reporting service does the following:

• Displays an alert stating that Windows XP has detected a problem (Fig. 6.15). You have the option of reporting the error to Microsoft by clicking the Send Error Report button or declining the action by clicking the Don't Send; or you can click click here to view technical information about the problem before sending a report to Microsoft. Notice that you can also debug the application by clicking the Debug button.

  
  Fig. 6.15: Error Reporting service displays an alert when a user-mode error, such as an application error, occurs

• Sends a problem report to Microsoft. If you click Send Error Report, the Error Reporting service sends the report to Microsoft through an Internet connection. You might be prompted to provide additional information to complete your error report. When the process is complete, the Error Reporting service enables you to obtain more details by clicking More Information.

• An automated process then searches a database of known issues for matching conditions. If a match exists, an on-screen message appears with information containing Internet links to updated drivers, patches, or Microsoft Knowledge Base articles with troubleshooting and support information.

When a kernel mode error occurs (such as the STOP message, which we briefly discussed in the previous section), Windows XP writes a small memory dump file to disk. After you reboot the system either in normal mode or safe mode with networking and logon, the Error Reporting service does the following:

• Displays an alert stating that Windows XP has encountered a serious problem (Fig. 6.16). As in the previous case, you have the option of reporting this error to Microsoft. You can also choose not to send an error report. To view technical details on the problem, follow the click here link.

  
  Fig. 6.16: The Error Reporting service displays an alert informing you that Windows XP has encountered a serious problem (a STOP message, in this case)

• Sends a problem report to Microsoft. If you choose to report the problem, the Error Reporting service sends the report to Microsoft (which includes the information in the small memory dump file) through an Internet connection. You might be prompted to provide additional information to complete your error report. When the process is complete, the Error Reporting service enables you to obtain more details by clicking More Information.

• An automated process then searches a database of known issues for matching conditions If a match exists, an on-screen message appears with information containing Internet links to updated drivers, patches, or Microsoft Knowledge Base articles with troubleshooting and support information.

You can manually configure Windows Error Reporting service options To perform this task, proceed as follows:

1. Start the System applet in Control Panel Go to the Advanced tab and click the Error Reporting button to display the Error Reporting window (Fig. 6.17)

   
   Fig. 6.17: The Error Reporting window

2. In this window, you can set the following Error Reporting options:

   • Completely disable the Error Reporting service by setting the Disable error reporting radio button. Notice that in this case you can still instruct the service to display notification in case of severe errors, such as STOP errors To do so, set the But notify me when critical errors occur checkbox directly below the above mentioned radio button.

   • Enable the Error Reporting service by setting the Enable error reporting radio button. If you set the Windows operating system checkbox directly below this radio button, the service will always report problems with Windows XP kernel-mode components You can also choose to report problems with individual applications by setting the Programs checkbox.

Windows XP always writes a small memory dump file when a STOP message appears. Therefore, the Error Reporting service is able to send a problem report with the information from the small memory dump file, even if you have configured your system to generate kernel or complete memory dump files.

To configure Windows Error Reporting for individual applications, proceed as follows:

1. Open the Error Reporting window (Fig. 6.17) If error reporting is disabled, enable this service by setting the Enable error reporting radio button, and make sure that the Programs checkbox is set.

2. Click the Choose Programs button to open the Choose Programs window (Fig. 6.18) In this window, you have the following options:

   
   Fig. 6.18: The Choose Programs window

   • If you set the All programs radio button, the service will report errors and problems with all applications installed in the system.

   • If you set the All programs in this list radio button, you will be able to enable or disable error reporting for Windows components and Microsoft applications by setting or clearing the appropriate checkboxes.

   • Finally, you'll be able to create an exception list for error reporting service. To do so, click the Add button at the bottom of this window, then select one or more applications for which you want error reporting to be disabled. Applications added to the exception list will be displayed in the Do not report errors for these programs field. To remove programs included into this list, select the program from this list and click the Remove button.

You can optionally change error report destinations from the default value (sent directly to Microsoft) or to a network path by changing Group Policy settings or by editing the registry.

To change the error report destination:

1. Start Regedit.exe and expand the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting key (Fig. 6.19). If this key doesn't contain the nested DW key, create it.

   
   Fig. 6.19: The Error Reporting options parameters in the registry

2. Create another nested key named DWNoSecondLevelCollection, and under this key create a string value named ER_Report_path. To change the error report destination, specify a path to the new location. For example, \\myserver\myshare\my_dir.

3. Click OK and close the Registry Editor.

4. To restore the original configuration and send reports directly to Microsoft, delete the ER_Report_Path entry.

^[*]This option is improved in comparison to Windows 2000.

^[**]Options that are new in Windows XP.