Safe Mode

[Previous] [Next]

Perhaps the most common reason Windows 2000 systems become unbootable is that a device driver crashes the machine during the boot sequence. Because software or hardware configurations can change over time, latent bugs can surface in drivers at any time. Windows 2000 offers a way for an administrator to attack the problem: booting in safe mode. Safe mode is a concept Windows 2000 borrows from Consumer Windows—a boot configuration that consists of the minimal set of device drivers and services. By relying on only the drivers and services that are necessary for booting, Windows 2000 avoids loading third-party and other nonessential drivers that might crash.

When Windows 2000 boots, you press the F8 key to enter a special boot menu that contains the safe-mode boot options. You typically choose from three safe-mode variations: Safe Mode, Safe Mode With Networking, and Safe Mode With Command Prompt. Standard safe mode comprises the minimum number of device drivers and services necessary to boot successfully. Networking-enabled safe mode adds network drivers and services to the drivers and services that standard safe mode includes. Finally, safe mode with command prompt is identical to standard safe mode except that Windows 2000 runs the command prompt application (Cmd.exe) instead of Windows Explorer as the shell when the system enables GUI mode.

Windows 2000 includes a fourth safe mode—Directory Services Restore mode—which is different from the standard and networking-enabled safe modes. You use Directory Services Restore mode to boot the system into a mode that lets you restore the Active Directory directory service of a domain controller from backup media. All drivers and services load during a Directory Services Restore mode boot; therefore, you wouldn't use Directory Services Restore mode to boot unbootable systems.

Driver Loading in Safe Mode

How does Windows 2000 know which device drivers and services are part of standard and networking-enabled safe boots? The answer lies in the HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot registry key. This key contains the Minimal and Network subkeys. Each subkey contains more subkeys that specify the names of device drivers or services or of groups of drivers. For example, the vga.sys subkey identifies the VGA display device driver that the startup configuration includes. The VGA display driver provides basic graphics services for any PC-compatible display adapter. The system uses this driver as the safe-mode display driver in lieu of a driver that might take advantage of an adapter's advanced hardware features but that might also prevent the system from booting. Each subkey under the SafeBoot key has a default value that describes what the subkey identifies; the vga.sys subkey's default value is Driver.

The Boot file system subkey has as its default value Driver Group. When developers design a device driver's installation script, they can specify that the device driver belong to a driver group. The driver groups that a system defines are listed in the List value of the HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder key. A developer specifies a driver as a member of a group to indicate to Windows 2000 at what point during the boot process the driver should start. The ServiceGroupOrder key's primary purpose is to define the order in which driver groups load; some driver types must load either before or after other driver types. The Group value beneath a driver's configuration registry key associates the driver with a group. Driver and service configuration keys reside beneath HKLM\SYSTEM\CurrentControlSet\Services. If you look under this key, you'll find the VgaSave key for the VGA display device driver, which you can see in the registry is a member of the Video Save group. Any file system drivers that Windows 2000 requires for access to the Windows 2000 system drive are in the Boot file system group. If the system drive is NTFS, the NTFS driver is part of this group (the value of Group under the Ntfs key is Boot file system); otherwise, the Fastfat file system driver (which supports FAT12, FAT16, and FAT32 drives in Windows 2000) is part of this group. Other file system drivers are part of the File system group, which the standard and networking-enabled safe-mode configurations also include.

When you boot into a safe-mode configuration, the boot loader (Ntldr) passes an associated switch to the kernel (Ntoskrnl.exe) as a command-line parameter, along with any switches you've specified in the Boot.ini file for the installation you're booting. If you boot into any safe mode, Ntldr passes the/SAFEBOOT: switch. Ntldr appends one or more additional strings to/SAFEBOOT:, depending on which type of safe mode you select. For standard safe mode, Ntldr appends MINIMAL, and for networking-enabled safe mode, it adds NETWORK. Ntldr adds MINIMAL(ALTERNATESHELL) for safe mode with command prompt and DSREPAIR for Directory Services Restore mode.

The Windows 2000 kernel scans boot parameters in search of the safe-mode switches early during the boot and sets the internal variable InitSafeBootMode to a value that reflects the switches the kernel finds. The kernel writes theInitSafeBootMode value to the registry value HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Option\OptionValue so that user-mode components, such as the SCM, can determine what boot mode the system is in. In addition,if the system is booting safe mode with command prompt, the kernel sets the HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Option\UseAlternate Shell value to 1. The kernel records the parameters that Ntldr passes to it in the value HKLM\SYSTEM\CurrentControlSet\Control\SystemStartOptions.

When the I/O manager kernel subsystem loads device drivers that HKLM\SYSTEM\CurrentControlSet\Services specifies, the I/O manager executes the function IopLoadDriver. When the Plug and Play manager detects a new device and wants to dynamically load the device driver for the detected device, the Plug and Play manager executes the function IopCallDriverAddDevice. Both these functions call the function IopSafeBootDriverLoad before they load the driver in question. IopSafeBootDriverLoad checks the value of InitSafeBootMode and determines whether the driver should load. For example, if the system boots in standard safe mode, IopSafeBootDriverLoad looks for the driver's group, if the driver has one, under the Minimal subkey. If IopSafeBootDriverLoad finds the driver's group listed, IopSafeBootDriverLoad indicates to its caller that the driver can load. Otherwise, IopSafeBootDriverLoad looks for the driver's name under the Minimal subkey. If the driver's name is listed as a subkey, the driver can load. If IopSafeBootDriverLoad can't find the driver group or driver name subkeys, the driver can't load. If the system boots in networking-enabled safe mode, IopSafeBootDriverLoad performs the searches on the Network subkey. If the system doesn't boot in safe mode, IopSafeBootDriverLoad lets all drivers load.

A loophole exists regarding the drivers that safe mode excludes from a boot: Ntldr, rather than the kernel, loads any drivers with a Start value of 0 in their registry key, which specifies loading the drivers at boot time. Because Ntldr doesn't check the SafeBoot registry key to identify which drivers to load, Ntldr loads all boot-start drivers.

Safe-Mode-Aware User Programs

When the service control manager (SCM) user-mode component (whichServices.exe implements) initializes during the boot process, the SCM checks the value of HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Option\OptionValue to determine whether the system is performing a safe boot. If so, the SCM mirrors the actions of IopSafeBootDriverLoad.Although the SCM processes the services listed under HKLM\SYSTEM\CurrentControlSet\Services, it loads only those services that the appropriate safe-mode subkey specifies by name. You can find more information on the SCM initialization process in the section "Services"in Chapter 5.

Userinit (\Winnt\System32\Userinit.exe) is another user-mode component that needs to know whether the system is booting in safe mode. Userinit, the component that initializes a user's environment when the user logs on, checks HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Option\UseAlternate Value. If this value is set, Userinit runs the program specified as the user's shell in the value HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Alternate Shell rather than executing Explorer.exe. Windows 2000 writes the program name Cmd.exe to the AlternateShell value during installation, making the Win32 command prompt the default shell for safe mode with command prompt. Even though command prompt is the shell, you can type Explorer.exe at the command prompt to start Windows Explorer, and you can run any other GUI program from the command prompt as well.

How does an application determine whether the system is booting in safe mode? By calling the Win32 GetSystemMetrics(SM_CLEANBOOT) function. Batch scripts that need to perform certain operations when the system boots in safe mode look for the SAFEBOOT_OPTION environment variable because the system defines this environment variable only when booting in safe mode.

Boot Logging in Safe Mode

When you direct the system to boot into safe mode, Ntldr hands the string specified by the /BOOTLOG option to the Windows 2000 kernel as a parameter, together with the parameter that requests safe mode. When the kernel initializes, it checks for the presence of the boot log parameter, whether or not any safe-mode parameter is present. If the kernel detects a boot log string, the kernel records the action the kernel takes on every device driver it considers for loading. For example, if IopSafeBootDriverLoad tells the I/O manager not to load a driver, the I/O manager calls IopBootLog to record that the driver wasn't loaded. Likewise, after IopLoadDriver successfully loads a driver that is part of the safe-mode configuration, IopLoadDriver calls IopBootLog to record that the driver loaded. You can examine boot logs to see which device drivers are part of a boot configuration.

Because the kernel wants to avoid modifying the disk until Chkdsk executes, late in the boot process, IopBootLog can't simply dump messages into a log file. Instead, IopBootLog records messages in the HKLM\SYSTEM\CurrentControlSet\BootLog registry value. As the first user-mode component to load during a boot, the Session Manager (\Winnt\System32\Smss.exe) executes Chkdsk to ensure the system drives' consistency and then completes registry initialization by executing the NtInitializeRegistry system call. The kernel takes this action as a cue that it can safely open a log file on the disk, which it does, invoking the function IopCopyBootLogRegistryToFile. This function creates the file Ntbtlog.txt in the Windows 2000 system directory (\Winnt by default) and copies the contents of the BootLog registry value to the file. IopCopyBootLogRegistryToFile also sets a flag for IopBootLog that lets IopBootLog know that writing directly to the log file, rather than recording messages in the registry, is now OK. The following output shows the partial contents of a sample boot log:

 Microsoft (R) Windows 2000 (R) Version 5.0 (Build 2195) 2 11 2000 10:53:27.500 Loaded driver \WINNT\System32\ntoskrnl.exe Loaded driver \WINNT\System32\hal.dll Loaded driver \WINNT\System32\BOOTVID.DLL Loaded driver ACPI.sys Loaded driver \WINNT\System32\DRIVERS\WMILIB.SYS Loaded driver pci.sys Loaded driver isapnp.sys Loaded driver compbatt.sys Loaded driver \WINNT\System32\DRIVERS\BATTC.SYS Loaded driver intelide.sys Loaded driver \WINNT\System32\DRIVERS\PCIIDEX.SYS Loaded driver pcmcia.sys Loaded driver ftdisk.sys Loaded driver Diskperf.sys Loaded driver dmload.sys Loaded driver dmio.sys  Did not load driver Media Control Devices Did not load driver Communications Port Did not load driver Audio Codecs