Inside the Boot Process, Part 1

Now the user has the option to select the Last Known Good configuration by pressing the spacebar. After a successful boot completes, NT makes a copy of the Registry tree that contains static and dynamic system and driver configuration information, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet, and marks it as the Last Known Good configuration. Because device drivers load based on information under the Services Registry key, this key is especially crucial. If a driver installs and at the next reboot prevents the system from starting, when the user selects the Last Known Good configuration, NT reverts to using the copy of the Registry tree that existed before the driver installed. Because the good copy does not include commands to load the driver, a boot using that copy will likely succeed.

After the user selects the Last Known Good configuration or a timeout of a few seconds expires, NTLDR proceeds to read in the HKEY_LOCAL_MACHINE\SYSTEM Registry hive (a hive is a file that contains a Registry subtree) that is located at <winnt>\system32\config\system. NTLDR splices the hardware configuration information it gathered earlier into the in-memory image of the SYSTEM Registry key, then NTLDR begins to load other files necessary for the boot.

The next files NTLDR loads are device drivers that function as boot drivers. Every device driver has a Registry subkey under HKEY_LOCAL_MACHINE\SYSTEM\Services. For example, NTFS has a subkey named Ntfs, which Screen 1 shows. A driver's subkey contains several values that NT examines when it determines when to load the driver. The value with the most general effect on the driver's load time is that driver's Start value. A Start value can have one of five possible settings, which Table 2, page 66, shows. NTLDR scans the in-memory Registry image and locates all drivers that have Start values of SERVICE_BOOT_START (Boot Start) and loads them into memory. NTLDR also loads the file system driver responsible for implementing the code for the file system's type of partition, on which the installation directory resides (FAT or NTFS). NTLDR must load these drivers at this time because otherwise the Kernel would require the drivers to load themselves, a requirement that introduces a circular dependency. Boot drivers include the disk drivers for the system partition. NTLDR prints a period to the screen for every file it loads, unless the /SOS switch is specified in the boot.ini selection, in which case NTLDR displays the filenames. Note that the drivers are loaded but not initialized at this time—they initialize later in the boot sequence.

This action is the end of NTLDR's role in the boot. After preparing processor registers for the Kernel, NTLDR locates the main function in ntoskrnl.exe's in-memory image and transfers control to ntoskrnl.exe. The sole parameter NTLDR passes to the Kernel is a data structure relating to the information NTLDR gathered during its execution. This data structure contains a copy of the line in boot.ini NTLDR selected, a pointer to the memory tables NTLDR generated to describe the physical memory on the system, a pointer to the in-memory HKEY_LOCAL_MACHINE Registry tree (which contains the HARDWARE and SYSTEM subkeys), and a pointer to the list of boot drivers NTLDR loaded.

The process I've described to this point pertains to x86 systems and is only partially applicable to Alpha systems. On an Alpha, the MBR does not contain boot codes. Instead, the Alpha firmware plays an active role in the boot. (Advanced RISC Consortium—ARC—defined functionality in the firmware of RISC computers.) NT Setup programs Alpha firmware to contain the boot menu entries that boot.ini contains on x86 systems. The programmed firmware code understands how to read FAT drives, so that when a user makes a boot selection, the firmware reads the boot partition to load osloader.exe, Alpha's equivalent of NTLDR. The firmware also loads the HAL from the boot partition, rather than from the NT installation directory (where the HAL resides on x86 systems), and reads in a PAL file. A PAL file contains code that NT uses to interface to a specific Alpha machine's microcode. The Alpha firmware doesn't understand NTFS drives, which is why you must create a minimal FAT partition on Alphas to contain osloader.exe and the HAL and PAL code. OSLOADER performs the same steps on Alphas as NTLDR performs on x86 systems, but OSLOADER has no ntdetect.com. Instead, the Alpha firmware's code performs detection and hands the information to OSLOADER after it loads.

Stay Tuned
Next time, I'll pick up where I've left off and discuss the steps ntoskrnl.exe goes through to initialize various Executive subsystems, such as the Memory Manager, Object Manager, and Process Manager. I'll also describe how NTOSKRNL loads more device drivers and initializes them and the boot drivers that NTLDR loaded. I'll conclude this tour of the NT boot process by showing you how ntoskrnl.exe initializes the user-mode side of the boot by loading winlogon, CSRSS (the Win32 subsystem), and services.