Inside the Boot Process, Part 2

Driver Initialization
The I/O Manager's initialization is particularly interesting, because it is dur-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 script or program can direct NT to define three Registry values in the driver's Registry key in addition to the Start value. These values are Group, Tag, and DependOnGroup. The first two values further refine the decision as to when the I/O Manager should initialize the driver, and the I/O Manager uses the third value when deciding whether to start a particular driver.

Before the I/O Manager initializes the boot drivers, it sorts them according to their Group values and sends drivers with no Group value to the end of the list. The Registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder determines group precedence in the sorting process. Screen 1 shows ServiceGroupOrder values. Groups at the top of the list have higher precedence than groups at the bottom of the list have.

After the I/O Manager sorts drivers by group, it sorts the drivers within each 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 assume that the I/O Manager initializes drivers with lower-number tags before drivers with higher-number tags, but that isn't necessarily the case. The Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GroupOrderList defines tag precedence within a group; with this key, Microsoft and device driver developers can take liberties with redefining the integer number system.

After the I/O Manager finishes sorting drivers, it traverses the lists it has 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 load that driver unless it has already loaded at least one driver that belongs to the specified group. The DependOnGroup value makes it easy to define a driver that must not load if its operation requires another driver that isn't present on the system.

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

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

As device drivers initialize during the boot, they work in a restricted environment: NTLDR and the Configuration Manager have defined only the HKEY_LOCAL_MACHINE\SYSTEM and HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION parts of the Registry, and boot drivers cannot access files on the disk. After the I/O Manager initializes the system-start drivers, it calls the HAL to define the drive-letter mappings, in which it links drive letters to the partitions the letters reference. For example, C:\ might be linked to \harddisk\0\partition1. The HAL honors any drive-letter assignments a user makes using Disk Administrator, and reads this information from HKEY_LOCAL_MACHINE\SYSTEM\Disk.

At the end of the Phase1Initialization function, the NT Kernel and Executive subsystems are fully operational. The function's last action is to launch the Session Manager Subsystem (SMSS, which is in \winnt\system32\smss.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, NT considers SMSS a trusted part of the OS. Second, SMSS is a native application. 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_MACHINE\SYSTEM\CurrentControlSet\Session Manager\BootExecute. Typically, this value contains one command to run the CHKDSK disk consistency checking application. As CHKDSK runs, it prints two periods on the screen for each partition it examines. SMSS creates page files after CHKDSK runs so that larger applications can begin to execute. Then, SMSS calls the Configuration Manager Executive subsystem to finish initializing the Registry, fleshing the Registry out to include all its keys. To do so, the Configuration Manager loads the Registry hives for the HKEY_LOCAL_MACHINE\SAM, HKEY_LOCAL_MACHINE\SAM\SECURITY, and HKEY_LOCAL_MACHINE\SOFTWARE keys. The Configuration Manager looks in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hivelist key to find out where the hives are located on disk.

SMSS then loads the win32k.sys device driver, which implements the kernel-mode portion of the Win32 subsystem. SMSS determines the location of win32k.sys and other components it loads by looking for their paths in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Session Manager. Finally, SMSS launches csrss.exe and winlogon.exe. CSRSS is the user-mode portion of the Win32 subsystem, and Winlogon is the logon manager.