Learn how NT initializes
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.