SQL Server Magazine

As Windows NT has become more widely adopted, the number of NT applications has increased dramatically. In addition, virtually every x86 hardware device currently available incorporates NT support. Microsoft estimates that about 12,000 NT-compatible applications and 24,000 NT-supported hardware devices exist. Although these ubiquitous applications and hardware devices make NT an attractive OS that is easy to use and deploy, they're also causing NT to experience growing pains. Misbehaving applications and poorly written device drivers give users the impression that NT is an unstable OS. To date, Microsoft has provided systems administrators only limited tools for system recovery and has largely moved the burden of developing correct applications and drivers to developers. But with Windows 2000 (Win2K), Microsoft has formulated goals to help developers help Microsoft make Win2K an OS with zero unplanned downtime and to help administrators address downtime problems when the problems arise.

How will Microsoft accomplish this? By introducing built-in reliability enhancements in Win2K, and by giving developers tools with which to catch problems in applications and drivers before end users do. However, Microsoft also recognizes that even with development-side efforts, systems will occasionally become unbootable. To address the need for better system recovery than NT 4.0's Emergency Repair Disk (ERD) offers, Microsoft is giving administrators some powerful new tools.

This month, I take you on a tour of the new system-recovery options in Win2K, including safe mode, the Recovery Console (RC), and a new crash dump option. Over the next 2 months, I'll describe the reliability features that Microsoft has added to Win2K (such as Windows File Protection) that protect against unruly applications. I'll conclude Part 3 by describing the Driver Verifier, a powerful tool that helps device driver developers quickly find bugs in their drivers that they might not have noticed before, and that helps administrators identify device drivers that are responsible for system crashes.

Safe Mode
Perhaps the most common reason NT 4.0 systems become unbootable is that a device driver, either right after installation or for no apparent reason after having worked satisfactorily for a time, prevents a successful boot by crashing the machine during the boot sequence. Because software or hardware configurations can change over time, latent bugs can surface in drivers. If a driver crashes during the first boot after which the system installed the driver, you're in luck. You can select the Last Known Good configuration during the boot sequence to restore the HKEY_LOCAL_MACHINESYSTEM\CurrentControlSet Registry key to the version that NT used during the last successful boot of the computer. If the Last Known Good configuration can't help, you sometimes have other options. For example, for a FAT system drive, you can boot off a DOS boot disk and manually delete or rename the driver file. If the system drive is NTFS, you must use a third-party recovery tool or load the computer with a parallel installation of NT so that you can access the NTFS drive.

Win2K is susceptible to device drivers that prevent a system from booting, but Win2K offers another way for an administrator to attack the problem: booting in safe mode. Safe mode is a concept Win2K borrows from Windows 9x—a boot configuration consisting of the minimal set of device drivers and services. By relying on only the drivers and services that are necessary for booting, Win2K avoids loading third-party and other nonessential drivers that might crash.

When Win2K 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: standard, networking-enabled, 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 those that standard safe mode includes. Finally, safe mode with command prompt is identical to standard safe mode, except that Win2K runs the command prompt application (i.e., cmd.exe) instead of Windows Explorer as the shell when the system enables GUI mode.

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

How does Win2K know which device drivers and services are part of standard and networking-enabled safe boots? The answer lies in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\SafeBoot Registry key. This key, which Screen 1 shows, contains the Minimal and Network subkeys. Each subkey contains a list of subkeys that specify the name either of a device driver or service or of a group of drivers. For example, in Screen 1 you can see the vga.sys subkey. This subkey identifies the VGA display device driver that the start-up 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.

You can also see the Boot file system subkey, whose default value is Driver Group. When developers design a device driver's installation script, they can specify that the device driver belongs to a driver group. The driver groups that a system defines are listed in HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\ Control\ServiceGroupOrder. Developers specify a driver as a member of a group to indicate to NT or Win2K when to start the driver during the boot process. The ServiceGroupOrder key's primary purpose is to define group load ordering; 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 HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\ Services. Thus, if you look under this key, you'll find the VgaSave key for the VGA display device driver. Any file system drivers that Win2K requires for access to the Win2K system drive are in the Boot file system group. If the system drive is NTFS, then the NTFS driver is part of this group; otherwise, the Fastfat file system driver (which supports FAT12, FAT16, and FAT32 drives in Win2K) is part of this group. Other file system drivers are part of the FileSystem group, which the standard and networking-enabled safe-mode configurations also include. (For more detailed information about driver loading and the boot process, see NT Internals, "Inside the Boot Process, Part 1," November 1998, and "Inside the Boot Process, Part 2," January 1999.)

When you boot into a safe-mode configuration, the boot loader NT Loader (NTLDR) passes to the kernel (ntoskrnl.exe) an associated switch as a command-line parameter, with any switches you have specified in the boot.ini file for the installation you are 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 adds NETWORK for networking-enabled safe mode. NTLDR adds MINIMAL(ALTERNATESHELL) for safe mode with command prompt and DSREPAIR for DS-repair mode.

The Win2K 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 the InitSafeBootMode value to the Registry value HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\ SafeBootOptions\OptionValue so that user-mode components, such as the Service Control Manager (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 HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\ Control\SafeBoot\ Options\UseAlternateShell value to 1. The kernel records the parameters that NTLDR passes to it in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\ Control\SystemStartOptions.

When the I/O Manager kernel subsystem loads device drivers that HKEY_ LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services specifies, the I/O Manager executes the function IopLoadDriver. When the Plug and Play Manager (PnP Manager) detects a new device and wants to dynamically load the device driver for the detected device, the PnP Manager executes the function IopCallDriverAddDevice. Both of these functions call the function IopSafeBootDriverLoad before they load the driver in question. IopSafeBootDriverLoad checks InitSafeBootMode's value 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 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 in their Registry key (value 0) that 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.

When the SCM user-mode component (which services.exe implements) initializes during the boot process, SCM checks the value of HKEY_LOCAL_ MACHINE\SYSTEM\ CurrentControlSet\ Control\SafeBoot\Options\OptionValue to determine whether the system is performing a safe boot. If so, SCM mirrors the actions of IopSafeBootDriverLoad. While SCM processes the services listed under HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\ Services, SCM loads only those services that the appropriate safe-mode subkey specifies by name.

   Prev. page   [1] 2     next page