Inside the Boot Process, Part 2

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 theHKEY_LOCAL_MACHINEHARDWARE and HKEY_LOCAL_MACHINESYSTEM Registrykeys. 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 loadinguser-mode code that presents the logon screen display and launches theWin32 subsystem. The sidebar "Windows 2000 and the Boot," page60, 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 calledExpInitializeExecutive. This function starts by calling the hardware abstractionlayer (HAL) function HallnitSystem. HallnitSystem gives proprietary versions ofthe HAL that various OEMs develop a chance to gain system control before NTperforms significant initialization. One HallnitSystem responsibility is toprepare the system interrupt controller for interrupts and to configure theclock tick interrupt. When HallnitSystem returns control, ExpInitializeExecutiveproceeds by honoring the /BURNMEMORY BOOT.INI switch (if the switch is presentin the selection the user made in the boot.ini file for which installation toboot) 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 MemoryManager gets the ball rolling by constructing page tables and internal datastructures that are necessary to provide basic memory services. The MemoryManager builds and reserves an area for the system file cache and creates memoryareas for the paged and nonpaged pools. The other Executive subsystems, theKernel, and the device drivers use these two memory pools for allocating theirdata structures.

After the Memory Manager finishes phase 0, ExpInitializeExecutive printsthe text Microsoft (R) Windows NT (TM) Version 4.0 (Build 1381) to theinitial blue screen you see during a boot. Build 1381 is the build number for NT4.0 without service packs. For NT 4.0 with service packs applied, text similarto Service Pack 3 follows the build number on the initial blue screen.The system obtains the service pack number from HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlWindowsCSDVersion, where the number is encoded as ahexadecimal value that can identify interim service packs (e.g., Service Pack1a).

During phase 0 of Object Manager initialization, NT defines the objectsthat are necessary to construct the Object Manager namespace so that othersubsystems can insert objects into it. NT also creates a handle table so thatresource tracking can begin. The Security Reference Monitor initializes thetoken type object and then uses the object to create and prepare the first tokenfor assignment to the initial process. The last Executive subsystem toinitialize in phase 0 is the Process Manager. The Process Manager performs mostof its initialization in phase 0, defining the process and thread object typesand setting up lists to track active processes and threads. The Process Manageralso creates a process object for the initial process and names it Idle. As itslast step, the Process Manager creates the System process and launches a threadfor this process that will direct phase 1 initialization in the Kernel'sPhase1Initialization function.

When control returns to it, ExpInitializeExecutive has become a thread inthe Idle process and immediately becomes the system's idle thread.ExpInitializeExecutive sets its priority to 0 (the lowest possible) and beginsexecuting 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 thesystem 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 theHAL, Phase1Initialization turns on the remaining CPUs. NT prints text similar to2 System Processors [128 MB Memory] Multiprocessor Kernel to the bluescreen after all CPUs have initialized.

Phase1Initialization continues by calling every Executive subsystem in theorder Table 1 shows, so that they can execute phase 1 initialization. The orderin which Phase1Initialization calls the subsystems is important because ofsystem interdependencies. For example, the Executive must define type objectslike mutexes, semaphores, events, and timers because other subsystems use theseobjects.

Driver Initialization
The I/O Manager's initialization is particularly interesting, because it isdur-ing phase 1 initialization that the boot drivers that NTLDR loaded finally start. When you or NT installs a device driver, the driver's Setup scriptor program can direct NT to define three Registry values in the driver'sRegistry key in addition to the Start value. These values are Group, Tag,and DependOnGroup. The first two values further refine the decision as to whenthe I/O Manager should initialize the driver, and the I/O Manager uses the third valuewhen deciding whether to start a particular driver.

Before the I/O Manager initializes the boot drivers, it sorts themaccording to their Group values and sends drivers with no Group value to the endof the list. The Registry value HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlServiceGroupOrder determinesgroup precedence in the sorting process. Screen 1 shows ServiceGroupOrdervalues. Groups at the top of the list have higher precedence than groups at thebottom of the list have.

After the I/O Manager sorts drivers by group, it sorts the drivers withineach group according to the Tag values defined in the drivers' Registry keys.Drivers without a tag go to the end of the list in their group. You might assumethat the I/O Manager initializes drivers with lower-number tags before driverswith higher-number tags, but that isn't necessarily the case. The Registry keyHKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlGroupOrderListdefines tag precedence within a group; with this key, Microsoft and devicedriver developers can take liberties with redefining the integer number system.

After the I/O Manager finishes sorting drivers, it traverses the lists ithas made and initializes each driver according to its place on the list.However, if a driver has a DependOnGroup value, the I/O Manager will not loadthat driver unless it has already loaded at least one driver that belongs to thespecified group. The DependOnGroup value makes it easy to define a driver thatmust not load if its operation requires another driver that isn't present on thesystem.

As the I/O Manager initializes each driver, it checks the return status ofthe driver's initialization function. If a driver reports an error, the actionthe I/O Manager takes depends on the ErrorControl value in the driver's Registrykey. Table 2 shows possible ErrorControl values and the actions the I/O Managertakes when a driver with a particular value reports an error. In some cases, anerror causes NT to reboot and try a previous version of the Registry's Controlsubkey in an attempt to boot successfully.

Immediately after initializing the boot drivers, the I/O Manager loads andinitializes all drivers marked as SERVICE_SYSTEM_START (system start). TheI/O Manager processes the system-start driver initialization order anddependencies in the same way it processed the order for the boot-start drivers.Thus, the only difference between boot-start drivers and system-startdrivers is that NTLDR preloads the boot-start drivers and NT initializes themfirst. When the boot-start drivers (specifically, the file system and diskdrivers responsible for the system partition) are active, the I/O Managercan use them to load the system-start drivers.

As device drivers initialize during the boot, they work in a restrictedenvironment: NTLDR and the Configuration Manager have defined only the HKEY_LOCAL_MACHINESYSTEM and HKEY_LOCAL_MACHINEHARDWAREDESCRIPTION parts ofthe Registry, and boot drivers cannot access files on the disk. After the I/OManager initializes the system-start drivers, it calls the HAL to define thedrive-letter mappings, in which it links drive letters to the partitions theletters reference. For example, C: might be linked to harddiskpartition1.The HAL honors any drive-letter assignments a user makes using DiskAdministrator, and reads this information from HKEY_LOCAL_MACHINESYSTEMDisk.

At the end of the Phase1Initialization function, the NT Kernel andExecutive subsystems are fully operational. The function's last action is to launch the Session Manager Subsystem (SMSS, which is inwinntsystem32smss.exe) user-mode process. SMSS is responsible for creating the user-mode environment that provides the visible interface to NT.

SMSS, CSRSS, and Winlogon
SMSS is like any other user-mode process except for two things: First, NTconsiders SMSS a trusted part of the OS. Second, SMSS is a nativeapplication. Because it's a trusted OS component, SMSS can perform actions few other processes can perform, such as creating security tokens. Because it's a native application, SMSS doesn't use Win32 APIs--­it uses only core Executive APIs known collectively as NT's Native API. SMSS doesn't use the Win32 APIs because the Win32 subsystem isn't executing when SMSS launches. In fact, one of SMSS's tasks is to start the Win32 subsystem.

SMSS first processes commands in the Registry value HKEY_LOCAL_MACHINESYSTEMCurrentControlSetSession ManagerBootExecute. Typically,this value contains one command to run the CHKDSK disk consistency checkingapplication. As CHKDSK runs, it prints two periods on the screen for eachpartition it examines. SMSS creates page files after CHKDSK runs so that largerapplications can begin to execute. Then, SMSS calls the Configuration ManagerExecutive subsystem to finish initializing the Registry, fleshing the Registryout to include all its keys. To do so, the Configuration Manager loads theRegistry hives for the HKEY_LOCAL_MACHINESAM, HKEY_LOCAL_MACHINESAMSECURITY,and HKEY_LOCAL_MACHINESOFTWARE keys. The Configuration Manager looks inthe HKEY_LOCAL_MACHINESYSTEMCurrentControlSetHivelist key to findout where the hives are located on disk.

SMSS then loads the win32k.sys device driver, which implements thekernel-mode portion of the Win32 subsystem. SMSS determines the location ofwin32k.sys and other components it loads by looking for their paths inHKEY_LOCAL_MACHINESYSTEMCurrentControlSetSession Manager. Finally, SMSSlaunches csrss.exe and winlogon.exe. CSRSS is the user-mode portion of the Win32subsystem, and Winlogon is the logon manager.

Shortly after win32k.sys starts, it switches the screen to graphics mode. Alittle later, Winlogon starts the Services subsystem (winntsystem32services.exe), which loads all services and device drivers marked Auto Start. (TheServices subsystem is also known as the Service Control Manager--­SCM.)Auto Start drivers and services can specify a dependency on a specific serviceby including a DependOnService value in their Registry keys in a manner similarto the way boot drivers use the DependOnGroup value. The SCM sorts and theninitializes the Auto Start drivers and services according to their group and tagvalues in the same way the I/O Manager sorts the boot- and system-start drivers.

After the SCM initializes the Auto Start services and drivers, it deems theboot successful. The Registry subkey HKEY_LOCAL_MACHINESYSTEMCurrentControlSet becomes the Last Known Good control set, because the systembooted successfully to this point. Earlier in the boot, NT made a copy of thissubkey and named the copy HKEY_LOCAL_MACHINESYSTEMCLONE. Any changesdrivers make to the current control set during the boot do not change the CLONEsubkey copy. The SCM copies the CLONE subkey to another control set subkey(e.g., HKEY_LOCAL_MACHINESYSTEMControlSet001), and the SCM marks thatcontrol set subkey as Last Known Good. The SCM marks the subkey by setting theHKEY_LOCAL_MACHINESYSTEMSelectLastKnownGood value to specify thethree-digit identifier at the end of the control set's subkey name (e.g., 001).If a user chooses to boot to the Last Known Good menu during the first steps ofa boot, or if a driver returns a severe or critical error, the system usesthe Last Known Good profile subkey asHKEY_LOCAL_MACHINESYSTEMCurrentControlSet. Doing so increases the chances thatthe system will boot successfully, because at least one previous boot using theLast Known Good profile was successful.

At approximately the time the Services subsystem is starting networkingservices, Winlogon presents users with the initial logon dialog box. That actionbrings us to the end of the boot process.

Shutdown
In contrast to the boot process, system shutdown is straightforward. First, the Win32 subsystem informs all Windows applications that the system is going down. Most applications exit voluntarily, and Winlogon stops any stragglers. Winlogon is in charge of finishing the shutdown process by calling the Executive subsystem function NtShutdownSystem. This function calls the I/O Manager, the Configuration Manager, the Memory Manager, and then the I/O Manager again, and informs them that they should prepare for the shutdown.

The first time NtShutdownSystem calls the I/O Manager, the I/O Managersends shutdown I/O packets to all device drivers that have requested shutdown notification. This action gives device drivers a chance to perform any special processing their device might require before NT exits. The Configuration Manager flushes any modified Registry data to disk, and the Memory Manager writes all modified pages containing file data back to their respective files. If the option to clear the paging file at shutdown is enabled, the Memory Manager clears the paging file at this time. The second time NtShutdownSystem calls the I/O Manager, the I/O Manager informs the file system drivers that the system is shutting down. Finally, if the system's user specified a reboot after the shutdown, the system calls the HAL to reboot the computer.

We've arrived at shutdown for this month's column. This two-column series about the boot process is a roadmap with visual cues to the operations that take place behind the scenes when your system boots. Table 3 presents a summary ofboot-process components with their execution modes and responsibilities.Understanding the details of the boot process helps you to diagnose problems that can arise during a boot, and gives you insight into the way NT pulls itself up by its bootstraps.