Inside the Boot Process, Part 2

In November, I began this two-part series on the Windows NT boot process. I described the way NT's Setup program prepares a hard disk for a boot by placing NT code in the disk's Master Boot Record (MBR) and boot sectors. When the system boots, the NT code loads the NTLDR boot file and executes the file's code. NTLDR is responsible for the pre-NT Kernel portion of the boot; part of NTLDR's responsibility is to prepare a data structure with information about the system and to construct the HKEY_LOCAL_MACHINE\HARDWARE and HKEY_LOCAL_MACHINE\SYSTEM Registry keys. NTLDR later gives this information to the Kernel, together with images for hal.dll and the boot-start device drivers.

This month, I resume my description of the boot process at the point at which NTLDR has finished its role in the boot by calling the NT Kernel's entry point. I'll walk you through the rest of the boot process, including the initialization steps each Executive subsystem takes. I'll describe how and when device drivers from each of the start categories--­Boot, System, and Auto--­initialize. I'll conclude by describing how the Kernel finishes a boot by loading user-mode code that presents the logon screen display and launches the Win32 subsystem. The sidebar "Windows 2000 and the Boot," page 60, explains how the NT boot process will change in Windows 2000 (Win2K--­formerly NT 5.0).

Initializing the Kernel and Executive Subsystems
The NT Kernel goes through two phases in its boot process: phase 0 and phase 1. Phase 0 initializes just enough of the Kernel and Executive subsystems so that basic services required for the completion of initialization become operational in phase 1. NT keeps interrupts disabled during phase 0 and enables them before phase 1. Most Executive subsystems implement their initialization code by having one function take a parameter that identifies which phase is executing.

The function responsible for orchestrating phase 0 is called ExpInitializeExecutive. This function starts by calling the hardware abstraction layer (HAL) function HallnitSystem. HallnitSystem gives proprietary versions of the HAL that various OEMs develop a chance to gain system control before NT performs significant initialization. One HallnitSystem responsibility is to prepare the system interrupt controller for interrupts and to configure the clock tick interrupt. When HallnitSystem returns control, ExpInitializeExecutive proceeds by honoring the /BURNMEMORY BOOT.INI switch (if the switch is present in the selection the user made in the boot.ini file for which installation to boot) and discarding the amount of memory the switch specifies. Next, ExpInitializeExecutive calls initialization routines for the Memory Manager, Object Manager, Security Reference Monitor, and Process Manager. The Memory Manager gets the ball rolling by constructing page tables and internal data structures that are necessary to provide basic memory services. The Memory Manager builds and reserves an area for the system file cache and creates memory areas for the paged and nonpaged pools. The other Executive subsystems, the Kernel, and the device drivers use these two memory pools for allocating their data structures.

After the Memory Manager finishes phase 0, ExpInitializeExecutive prints the text Microsoft (R) Windows NT (TM) Version 4.0 (Build 1381) to the initial blue screen you see during a boot. Build 1381 is the build number for NT 4.0 without service packs. For NT 4.0 with service packs applied, text similar to Service Pack 3 follows the build number on the initial blue screen. The system obtains the service pack number from HKEY_LOCAL_MACHINE\SYSTEMCurrentControlSet\Control\Windows\CSDVersion, where the number is encoded as a hexadecimal value that can identify interim service packs (e.g., Service Pack 1a).

During phase 0 of Object Manager initialization, NT defines the objects that are necessary to construct the Object Manager namespace so that other subsystems can insert objects into it. NT also creates a handle table so that resource tracking can begin. The Security Reference Monitor initializes the token type object and then uses the object to create and prepare the first token for assignment to the initial process. The last Executive subsystem to initialize in phase 0 is the Process Manager. The Process Manager performs most of its initialization in phase 0, defining the process and thread object types and setting up lists to track active processes and threads. The Process Manager also creates a process object for the initial process and names it Idle. As its last step, the Process Manager creates the System process and launches a thread for this process that will direct phase 1 initialization in the Kernel's Phase1Initialization function.

When control returns to it, ExpInitializeExecutive has become a thread in the Idle process and immediately becomes the system's idle thread. ExpInitializeExecutive sets its priority to 0 (the lowest possible) and begins executing a loop that will run only if no other thread in the system can run.

Phase 1 starts when Phase1Initialization calls the HAL to prepare the system to accept interrupts from devices and to enable interrupts. Phase1Initialization notes the time and stores it as the time the system booted. Up to this point, only one CPU has been active. In a symmetric multiprocessing (SMP) system, the boot process has left other CPUs off. Now, with the aid of the HAL, Phase1Initialization turns on the remaining CPUs. NT prints text similar to 2 System Processors [128 MB Memory] Multiprocessor Kernel to the blue screen after all CPUs have initialized.

Phase1Initialization continues by calling every Executive subsystem in the order Table 1 shows, so that they can execute phase 1 initialization. The order in which Phase1Initialization calls the subsystems is important because of system interdependencies. For example, the Executive must define type objects like mutexes, semaphores, events, and timers because other subsystems use these objects.