Boot Process

< Day Day Up >

In describing the Windows boot process, we'll start with the installation of Windows and proceed through the execution of boot support files. Device drivers are a crucial part of the boot process, so we'll explain the way that they control the point in the boot process at which they load and initialize. Then we'll describe how the executive subsystems initialize and how the kernel launches the user-mode portion of Windows by starting the Session Manager process (Smss.exe), the Windows subsystem, and the logon process (Winlogon). Along the way, we'll highlight the points at which various text appears on the screen to help you correlate the internal process with what you see when you watch Windows boot.

The early phases of the boot process differ significantly on x86 and x64 systems versus IA64 systems. The next sections describe the portions of the boot process specific to x86 and x64 and follow with a section describing the IA64-specific portions of the boot process.

x86 and x64 Preboot

The Windows boot process doesn't begin when you power on your computer or press the reset button. It begins when you install Windows on your computer. At some point during the execution of the Windows Setup program, the system's primary hard disk is prepared with code that takes part in the boot process. Before we get into what this code does, let's look at how and where Windows places the code on a disk. Since the early days of MS-DOS, a standard has existed on x86 systems for the way physical hard disks are divided into volumes. Microsoft operating systems split hard disks into discrete areas known as partitions and use file systems (such as FAT and NTFS) to format each partition into a volume. A hard disk can contain up to four primary partitions. Because this apportioning scheme would limit a disk to four volumes, a special partition type, called an extended partition, further allocates up to four additional partitions within each primary partition. Extended partitions can contain extended partitions, which can contain extended partitions, and so on, making the number of volumes an operating system can place on a disk effectively infinite. Figure 5-1 shows an example of a hard disk layout, and Table 5-1 summarizes the files involved in the x86 and x64 boot process. (You can learn more about Windows partitioning in Chapter 10, which covers storage management.)

Figure 5-1. Sample hard disk layout

Table 5-1. x86 and x64 Boot Process Components
Component	Processor Execution	Responsibilities
Master Boot Record (MBR) code	16-bit real mode	Reads and loads partition boot sectors.
Boot sector	16-bit real mode	Reads the root directory to load Ntldr.
Ntldr	16-bit real mode and 32-bit or 64-bit protected mode; turns on paging	Reads Boot.ini, presents boot menu, and loads Ntoskrnl.exe, Bootvid.dll, Hal.dll, and boot-start device drivers. If a 32-bit installation is booted, switches to 32-bit protected mode; if a 64-bit installation is booted, switches to 64-bit long mode.
Ntdetect.com	16-bit real mode	Performs hardware detection for Ntldr.
Ntbootdd.sys	Protected mode	Device driver used for disk I/O on SCSI and Advanced Technology Attachment (ATA) systems where the BIOS is not used.
Ntoskrnl.exe	Protected mode with paging	Initializes executive subsystems and boot and system-start device drivers, prepares the system for running native applications, and runs Smss.exe.
Hal.dll	Protected mode with paging	Kernel-mode DLL that interfaces Ntoksnrl and drivers to the hardware.
Smss	Native application	Loads Windows subsystem, including Win32k.sys and Csrss.exe, and starts Winlogon process.
Winlogon	Native application	Starts the service control manager (SCM), starts the Local Security Subsystem (LSASS), and presents interactive logon dialog box.
Service control manager (SCM)	Native application	Loads and initializes auto-start device drivers and Windows services.

Physical disks are addressed in units known as sectors. A hard disk sector on an IBM-compatible PC is typically 512 bytes. Utilities that prepare hard disks for the definition of volumes, including the MS-DOS Fdisk utility or the Windows Setup program, write a sector of data called a Master Boot Record (MBR) to the first sector on a hard disk. (MBR partitioning is described in Chapter 10.) The MBR includes a fixed amount of space that contains executable instructions (called boot code) and a table (called a partition table) with four entries that define the locations of the primary partitions on the disk. When an IBM-compatible computer boots, the first code it executes is called the BIOS, which is encoded into the computer's ROM. The BIOS selects a boot device, reads that device's MBR into memory, and transfers control to the code in the MBR.

The MBRs written by Microsoft partitioning tools, such as the one integrated into Windows Setup and the Disk Management MMC snap-in, go through a similar process of reading and transferring control. First, an MBR's code scans the primary partition table until it locates a partition containing a flag that signals the partition is bootable. When the MBR finds at least one such flag, it reads the first sector from the flagged partition into memory and transfers control to code within the partition. This type of partition is called a boot partition, and the first sector of such a partition is called a boot sector. The volume defined for the boot partition is called the system volume.

Operating systems generally write boot sectors to disk without a user's involvement. For example, when Windows Setup writes the MBR to a hard disk, it also writes a boot sector to the first bootable partition of the disk. You might have created a MS-DOS boot sector during the installation of MS-DOS, Windows Me, Windows 98, or Windows 95. Windows Setup checks to see whether the boot sector it will overwrite with a Windows boot sector is a valid MS-DOS boot sector. If it is, Windows Setup copies the boot sector's contents to a file named Bootsect.dos in the root directory of the partition.

Before writing to a partition's boot sector, Windows Setup ensures that the partition is formatted with a file system that Windows supports (FAT, FAT32, or NTFS) by formatting the boot partition (and any other partition) with a file system type you specify. If partitions are already formatted, you can instruct Setup to skip this step. After Setup formats the boot partition, Setup copies the files Windows uses to the boot partition (the system volume), including two files that are part of the boot sequence, Ntldr and Ntdetect.com.

Another of Setup's roles is to create a boot menu file, Boot.ini, in the root directory of the system volume. This file contains options for starting the version of Windows that Setup installs and any preexisting Windows installations. If Bootsect.dos contains a valid MS-DOS boot sector, one of the entries Boot.ini creates is to boot into MS-DOS. The following output shows a sample Boot.ini file from a dual-boot computer on which MS-DOS is installed before Windows XP:

[boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1) \WINDOWS="Microsoft Windows XP Professional" /fastdetect C:\="Microsoft Windows"

You'll notice in the sample file that the path to the Windows directory is specified in a special syntax that conforms to the Advanced RISC Computing (ARC) naming convention. There are three variants to the syntax used by Windows. The first, shown in the preceding code sample, is the multi() syntax, which instructs Windows to use BIOS INT 13 functions to load system files. Thus, the multi() syntax is present when the disk on which the boot volume is located has a controller that provides INT-13 support. The multi() syntax follows this format:

multi(W)disk(X)rdisk(Y)partition(Z)

W is the disk controller number (also known as the ordinal number) and is typically 0. X is always 0 in the multi() syntax. Y specifies the physical hard disk attached to controller W. For ATA controllers, this number is typically between 0 and 3. For SCSI controllers, the number is typically between 0 and 15. Z indicates the partition number on the physical disk that corresponds to the boot volume. The first partition is assigned the number 1.

The scsi() ARC syntax informs Windows that it should rely on disk I/O services provided by Ntbootdd.sys (described shortly) to access the files on the boot volume. The format of the scsi() syntax is:

scsi(W)disk(X)rdisk(Y)partition(Z)

In this syntax, W is the controller number, and X is the physical hard disk attached to the controller and is typically between 0 and 15. Y specifies the SCSI logical unit number (LUN) of the disk that contains the boot volume and is typically 0. Finally, Z is the partition that corresponds to the boot volume with numbering starting at 1.

The final syntax used by Windows is the signature() syntax. This instructs Windows to locate the disk with the signature that matches the first value in parentheses, regardless of the controller number associated with the disk and to use Ntbootdd.sys to access the boot volume. A disk signature is a globally unique identifier (GUID) that Windows Setup extracts from information in the MBR and writes to the disk. The signature() syntax is as follows:

signature(V)disk(X)rdisk(Y)partition(Z)

V is a 32-bit hexadecimal disk signature that identifies the disk. X is the physical hard disk with the specific signature, and it can be attached to any controller on the system. Y is always 0, and Z is the partition number on which the boot volume is located.

Windows uses the signature() syntax in the following cases:

The boot volume is larger than 7.8 GB in size, and BIOS extended INT-13 functions (those used to access parts of a disk beyond 7.8 GB) cannot access the entire volume.
The BIOS does not support extended INT-13 functions.

The x86/x64 Boot Sector and Ntldr

Setup must know the partition format before it writes a boot sector because the contents of the boot sector vary depending on the format. For example, if the boot partition is a FAT partition, Windows writes code to the boot sector that understands the FAT file system. But if the partition is in NTFS format, Windows writes NTFS-capable code. The role of the boot-sector code is to give Windows information about the structure and format of a volume and to read in the Ntldr file from the root directory of the volume. Thus, the boot-sector code contains just enough read-only file system code to accomplish this task. After the boot-sector code loads Ntldr into memory, it transfers control to Ntldr's entry point. If the boot-sector code can't find Ntldr in the volume's root directory, it displays the error message "BOOT: Couldn't find NTLDRP" if the boot file system is FAT or "NTLDR is missing" if the file system is NTFS.

Ntldr begins its existence while a system is executing in an x86 operating mode called real mode. In real mode, no virtual-to-physical translation of memory addresses occurs, which means that programs that use the memory addresses interpret them as physical addresses and that only the first 1 MB of the computer's physical memory is accessible. Simple MS-DOS programs execute in a real-mode environment. However, the first action Ntldr takes is to switch the system to protected mode. Still no virtual-to-physical translation occurs at this point in the boot process, but a full 32 bits of memory becomes accessible. After the system is in protected mode, Ntldr can access all of physical memory. After creating enough page tables to make memory below 16 MB accessible with paging turned on, Ntldr enables paging. Protected mode with paging enabled is the mode in which Windows executes in normal operation.

After Ntldr enables paging, it is fully operational. However, it still relies on functions supplied by the boot code to access IDE-based system and boot disks as well as the display. The bootcode functions briefly switch off paging and switch the processor back to a mode in which services provided by the BIOS can be executed. If the disk containing the boot volume is SCSIbased and is not accessible using BIOS firmware support, Ntldr loads a file named Ntbootdd.sys and uses it instead of the boot-code functions for disk access. Ntbootdd.sys is a copy of the SCSI miniport driver that Windows uses when its fully operation to access the boot disk. (See Chapter 10 for more information on disk drivers.) Ntldr next reads the Boot.ini file from the root directory using built-in file system code. Like the boot sector's code, Ntldr contains read-only NTFS and FAT code; unlike the boot sector's code, however, Ntldr's file system code can read subdirectories.

Ntldr next clears the screen. If there is a valid Hiberfil.sys file in the root of the system volume, it shortcuts the boot process by reading the contents of the file into memory and transferring control to code in the kernel that resumes a hibernated system. That code is responsible for restarting drivers that were active when the system was shut down. Hiberfil.sys will be valid only if the last time the computer was shut down it was hibernated. (See the section "The Power Manager" in Chapter 11 for information on hibernation.)

If there is more than one boot-selection entry in Boot.ini, it presents the user with the boot-selection menu. (If there is only one entry, Ntldr bypasses the menu and proceeds to displaying the startup progress bar.) Selection entries in Boot.ini direct Ntldr to the partition on which the Windows system directory (typically \Windows) of the selected installation resides. This partition might be the same as the boot partition, or it might be another primary partition.

If the Boot.ini entry refers to an MS-DOS installation (that is, by referring to C:\ as the system partition), Ntldr reads the contents of the Bootsect.dos file into memory, switches back to 16-bit real mode, and calls the MBR code in Bootsect.dos. This action causes the Bootsect.dos code to execute as if the MBR had read the code from disk. Code in Bootsect.dos continues an MS-DOS-specific boot, such as is used to boot Microsoft Windows Me, Windows 98, or Windows 95 on a computer on which these operating systems are installed with Windows.

Entries in Boot.ini can include optional arguments that Ntldr and other components involved in the boot process interpret. Table 5-2 contains a complete list of these options and their effects. The Bootcfg.exe tool, introduced in Windows XP, provides a convenient interface to setting a number of the switches. Any options that are included on the Boot.ini save to the Registry value HKLM\System\CurrentControlSet\Control\SystemStartOptions.

Table 5-2. Boot Options

Boot Qualifier

Meaning

/3GB

Increases the size of the user process address space from 2 GB to 3 GB (and therefore reduces the size of system space from 2 GB to 1 GB). Giving virtual-memory-intensive applications such as database servers a larger address space can improve their performance. For an application to take advantage of this feature, however, two additional conditions must be met: the system must be running Windows XP, Windows Server 2003, Windows 2000 Advanced Server, or Datacenter Server; and the application .exe must be flagged as a 3-GB-aware application (applies to 32-bit systems only). (See the section "Address Space Layout" in Chapter 7 for more information.)

/BASEVIDEO

Causes Windows to use the standard VGA display driver for GUI-mode operations.

/BAUDRATE=

Enables kernel-mode debugging, and specifies an override for the default baud rate (19200) at which a remote kernel debugger host will connect. Example: /BAUDRATE=115200.

/BOOTLOG

Causes Windows to write a log of the boot to the file %System-Root%\Ntbtlog.txt.

/BOOTLOGO

Use this switch to have Windows XP or Windows Server 2003 display an installable splash screen instead of the standard splash screen. First, create a 16-color (any 16 colors) 640x480 bitmap and save it in the Windows directory with the name Boot.bmp. Then add "/bootlogo /noguiboot" to the boot.ini selection.

/BREAK

Causes the hardware abstraction layer (HAL) to stop at a breakpoint at HAL initialization. The first thing the Windows kernel does when it initializes is to initialize the HAL, so this breakpoint is the earliest one possible. The HAL will wait indefinitely at the breakpoint until a kernel-debugger connection is made. If the switch is used without the /DEBUG switch, the system will elicit a blue screen with a STOP code of 0x00000078 (PHASE0_ EXCEPTION).

/BURNMEMORY=

Specifies an amount of memory Windows can't use (similar to the /MAXMEM switch). The value is specified in megabytes. Example: /BURNMEMORY=128 would indicate that Windows can't use 128 MB of the total physical memory on the machine.

/CHANNEL=

Used in conjunction with /DEBUGPORT=1394 to specify the IEEE 1394 channel through which kernel debugging communications will flow. This can be any number between 0 and 62 and defaults to 0 if not set.

/CLKLVL

Causes the standard x86 multiprocessor HAL (Halmps.dll) to configure itself for a level-sensitive system clock rather than an edge-triggered clock. Level-sensitive and edge-triggered are terms used to describe hardware interrupt types.

/CMDCONS

Passed when booting into the Recovery Console (described later in this chapter).

/CRASHDEBUG

Causes the kernel debugger to be loaded when the system boots, but to remain inactive unless a crash occurs. This allows the serial port that the kernel debugger would use to be available for use by the system until the system crashes (vs. /DEBUG, which causes the kernel debugger to use the serial port for the life of the system session).

/DEBUG

Enables kernel-mode debugging.

/DEBUGPORT=

Enables kernel-mode debugging, and specifies an override for the default serial (usually COM2 on systems with at least two serial ports) to which a remote kernel-debugger host is connected. Windows XP and Windows Server 2003 also support debugging through accepted IEEE 1394 ports. Examples: /DEBUGPORT=COM2, /DEBUGPORT=1394.

/EXECUTE

Disables no-execute protection. See the /NOEXECUTE switch for more information.

/FASTDETECT

Default boot option for Windows. Replaces the Windows NT 4 switch /NOSERIALMICE. The reason the qualifier exists (vs. just having NTDETECT perform this operation by default) is so that NTDETECT can support booting Windows NT 4. Windows Plug and Play device drivers perform detection of parallel and serial devices, but Windows NT 4 expects NTDETECT to perform the detection. Thus, specifying /FASTDETECT causes NTDETECT to skip parallel and serial device enumeration (actions that are not required when booting Windows), whereas omitting the switch causes NTDETECT to perform this enumeration (which is required for booting Windows NT 4).

/INTAFFINITY

Directs the standard x86 multiprocessor HAL (Halmps.dll) to set interrupt affinities such that only the highest numbered processor will receive interrupts. Without the switch, the HAL defaults to its normal behavior of letting all processors receive interrupts.

/KERNEL= /HAL=

Enables you to override Ntldr's default filename for the kernel image (Ntoskrnl.exe) and/or the HAL (Hal.dll). These options are useful for alternating between a checked kernel environment and a free (retail) kernel environment or even to manually select a different HAL. If you want to boot a checked environment that consists solely of the checked kernel and HAL, which is typically all that is needed to test drivers, follow these steps on a system installed with the free build:

Copy the checked versions of the kernel images from the checked build CD to your \Windows\System32 directory, giving the images different names than the default. For example, if you're on a uniprocessor, copy Ntoskrnl.exe to Ntoschk.exe and Ntkrnlpa.exe to Ntoschkpa.exe. If you're on a multiprocessor, copy Ntkrnlmp.exe to Ntoschk.exe and Ntkrpamp.exe to Ntoschkpa.exe. The kernel filename must be an 8.3-style short name.
Copy the checked version of the appropriate HAL needed for your system from \I386\Driver.cab on the checked build CD to your \Windows\System32 directory, naming it Halchk.dll. To determine which HAL to copy, open \Windows\Repair\Setup.log and search for Hal.dll; you'll find a line like \WINDOWS\system32\ hal.dll="halacpi.dll","1d8a1". The name immediately to the right of the equals sign is the name of the HAL you should copy. The HAL filename must be an 8.3-style short name.
Make a copy of the default line in the system's Boot.ini file.
In the string description of the boot selection, add something that indicates that the new selection will be for a checked build environment (for example, "Windows XP Professional Checked").
Add the following to the end of the new selection's line: /KERNEL=NTOSCHK.EXE /HAL= HALCHK.DLL

Now when the selection menu appears during the boot process, you can select the new entry to boot a checked environment or select the entry you were using to boot the free build.

/LASTKNOWNGOOD

Causes the system to boot as if the LastKnownGood boot option was selected.

/MAXMEM=

Limits Windows to ignore (not use) physical memory beyond the amount indicated. The number is interpreted in megabytes. Example: /MAXMEM=32 would limit the system to using the first 32 MB of physical memory even if more were present.

/MAXPROCSPERCLUSTER=

For the standard x86 multiprocessor HAL (Halmps.dll), forces cluster-mode Advanced Programmable Interrupt Controller (APIC) addressing (not supported on systems with an 82489DX external APIC interrupt controller).

/MININT

This option is used by Windows PE (Preinstallation Environment) and causes the Configuration Manager to load the Registry SYSTEM hive as a volatile hive such that changes made to it in memory are not saved back to the hive image.

/NODEBUG

Prevents kernel-mode debugging from being initialized. Overrides the specification of any of the three debug-related switches, /DEBUG, /DEBUGPORT, and /BAUDRATE.

/NOEXECUTE

This option is available only on 32-bit versions of Windows when running on AMD64 processors and only when PAE (explained further in the /PAE switch entry) is also enabled. It enables noexecute protection, which results in the Memory Manager marking pages containing data as no-execute so that they cannot be executed as code. This can be useful for preventing malicious code from exploiting buffer overflow bugs with unexpected program input in order to execute arbitrary code. No-execute protection is always enabled on 64-bit versions of Windows on AMD64 processors. There are 4 modifiers that can be specified to the /NOEXECUTE switch: =OPTIN,=OPTOUT,=ALWAYSON,=ALWAYSOFF. See Chapter 7 for a description of their behavior.

/NOGUIBOOT

Instructs Windows not to initialize the VGA video driver responsible for presenting bitmapped graphics during the boot process. The driver is used to display boot progress information, so disabling it will disable the ability of Windows to show this information.

/NOLOWMEM

Requires that the /PAE switch be present and that the system have more than 4 GB of physical memory. If these conditions are met, the PAE-enabled version of the Windows kernel, Ntkrnlpa.exe, won't use the first 4 GB of physical memory. Instead, it will load all applications and device drivers, and allocate all memory pools, from above that boundary. This switch is useful only to test device-driver compatibility with large memory systems.

/NOPAE

Forces Ntldr to load the non Physical Address Extension (PAE) version of the Windows kernel, even if the system is detected as supporting x86 PAEs and has more than 4 GB of physical memory.

/NOSERIALMICE=[COMx | COMx,y,z…]

Obsolete Windows NT 4 qualifier replaced by the absence of the /FASTDETECT switch. Disables serial mouse detection of the specified COM ports. This switch was used if you had a device other than a mouse attached to a serial port during the startup sequence. Using /NOSERIALMICE without specifying a COM port disables serial mouse detection on all COM ports. See Microsoft Knowledge Base article Q131976 for more information.

/NUMPROC=

Specifies the number of CPUs that can be used on a multiprocessor system. Example: /NUMPROC=2 on a four-way system will prevent Windows from using two of the four processors.

/ONECPU

Causes Windows to use only one CPU on a multiprocessor system.

/PAE

Causes Ntldr to load Ntkrnlpa.exe, which is the version of the x86 kernel that is able to take advantage of x86 PAEs. The PAE version of the kernel presents 64-bit physical addresses to device drivers, so this switch is helpful for testing device driver support for large memory systems.

/PCILOCK

Stops Windows from dynamically assigning IO/IRQ resources to PCI devices and leaves the devices configured by the BIOS. See Microsoft Knowledge Base article Q148501 for more information.

/RDPATH=

Specifies the path to a System Disk Image (SDI) file, which can be on the network, that the system will use to boot from. Often used in conjunction with the /RDIMAGEOFFSET= flag to indicate to NTLDR where in the file the system image starts.

/REDIRECT

Introduced with Windows Server 2003. Used to cause Windows to enable Emergency Management Services (EMS), which reports boot information and accepts system management commands through a serial port. Specify serial port and baudrate used in conjunction with EMS with redirect= and redirectbaudrate= lines in the [boot loader] section of the Boot.ini file.

/SAFEBOOT:

Specifies options for a safe mode boot. You should never have to specify this option manually because Ntldr specifies it for you when you use the F8 menu to perform a safe mode boot. (A safe mode boot is a boot in which Windows loads only drivers and services that are specified by name or group under the Minimal or Network registry keys under HKLM\SYSTEM\ CurrentControlSet\Control\SafeBoot.) Following the colon in the option, you must specify one of three additional switches: MINIMAL, NETWORK, or DSREPAIR. The MINIMAL and NETWORK flags correspond to safe mode boot with no network and safe mode boot with network support, respectively. The DSREPAIR (Directory Services Repair) switch causes Windows to boot into a mode in which the Active Directory directory service is offline and the active directory database unopened. This allows an administrator to perform diagnostic, repair, or restore functions on the database. An additional option you can append is (ALTERNATESHELL), which tells Windows to use the program specified by the HKLM\SYSTEM\CurrentControlSet\SafeBoot\ AlternateShell value as the graphical shell rather than to use the default, which is Windows Explorer.

/SCSIORDINAL:

Directs Windows to the SCSI ID of the controller. (Adding a new SCSI device to a system with an on-board SCSI controller can cause the controller's SCSI ID to change.) See Microsoft Knowledge Base article Q103625 for more information.

/SDIBOOT=

Used in Windows XP Embedded systems to have Windows boot from a RAM disk image stored in the specified System Disk Image (SDI) file.

/SOS

Causes Windows to list the device drivers marked to load at boot time and then to display the system version number (including the build number), amount of physical memory, and number of processors.

/TIMERES=

Sets the resolution of the system timer on the standard x86 multiprocessor HAL (Halmps.dll). The argument is a number interpreted in hundreds of nanoseconds, but the rate is set to the closest resolution the HAL supports that isn't larger than the one requested. The HAL supports the following resolutions:

Hundreds of nanoseconds	Milliseconds (ms)
97660.98	195322.00
390633.90	781257.80

The default resolution is 7.8 ms. The system timer resolution affects the resolution of waitable timers. Example: /TIMERES=21000 would set the timer to a resolution of 2.0 ms.

/USERVA=

This switch is supported only on Windows XP and Windows Server 2003. Like the /3GB switch, this switch gives applications a larger address space. Specify the amount in MB between 2048 and 3072. This switch has the same application requirements as the /3GB switch and requires that the /3GB switch also be present (applies to 32-bit systems only).

/WIN95

Directs Ntldr to boot the Consumer Windows boot sector stored in Bootsect.w40. This switch is pertinent only on a triple-boot system that has MS-DOS, Consumer Windows, and Windows installed. See Microsoft Knowledge Base article Q157992 for more information.

/WIN95DOS

/YEAR=

Instructs the Windows core time function to ignore the year that the computer's real-time clock reports and instead use the one indicated. Thus, the year used in the switch affects every piece of software on the system, including the Windows kernel. Example: /YEAR=2001. (This switch was created to assist in Y2K testing.)

If the user doesn't select an entry from the selection menu within the timeout period the Boot.ini file specifies, Ntldr chooses the default selection, which is the top-most entry in boot.ini with a path matching the path specified in the "default=" line. Once the boot selection has been made, Ntldr loads and executes Ntdetect.com, a 16-bit real-mode program that uses a system's BIOS to query the computer for basic device and configuration information. This information includes the following:

The time and date information stored in the system's CMOS (nonvolatile memory)
The types of buses (for example, ISA, PCI, EISA, Micro Channel Architecture [MCA]) on the system and identifiers for devices attached to the buses
The number, size, and type of disk drives on the system
The types of mouse input devices connected to the system
The number and type of parallel ports configured on the system
The types of video adapters present on the system

This information is gathered into internal data structures that will be stored under the HKLM\HARDWARE\DESCRIPTION registry key later in the boot.

On Windows 2000, Ntldr then clears the screen and displays the "Starting Windows" progress bar. This progress bar remains empty until Ntldr begins loading boot drivers. (See step 5 in the following list.) Below the progress bar is the message, "For troubleshooting and advanced startup options for Windows, press F8." If the user presses F8, the advanced boot menu is presented, which allows the user to select such options as booting from last known good, safe mode, debug mode, and so on. On Windows XP and Windows Server 2003, Ntldr presents a logo splash screen instead of a progress bar.

If Ntldr is running on an x64 system and the kernel specified by the entry selected in the boot menu is for x64, Ntldr switches the processor to long mode, where the native word size is 64-bits. Next, Ntldr begins loading the files from the boot volume needed to start the kernel initialization. The boot volume is the volume that corresponds to the partition on which the system directory (usually \Windows) of the installation being booted is located. The steps Ntldr follows here include:

Loads the appropriate kernel and HAL images (Ntoskrnl.exe and Hal.dll by default). If Ntldr fails to load either of these files, it prints the message "Windows could not start because the following file was missing or corrupt", followed by the name of the file.
Reads in the SYSTEM registry hive, \Windows\System32\Config\System, so that it can determine which device drivers need to be loaded to accomplish the boot. (A hive is a file that contains a registry subtree. You'll find more details about the registry in Chapter 4)
Scans the in-memory SYSTEM registry hive and locates all the boot device drivers. Boot device drivers are drivers necessary to boot the system. These drivers are indicated in the registry by a start value of SERVICE_BOOT_START (0). Every device driver has a registry subkey under HKLM\SYSTEM\CurrentControlSet\Services. For example, Services has a subkey named Dmio for the Logical Disk Manager driver, which you can see in Figure 5-2. (For a detailed description of the Services registry entries, see the section "Services" in Chapter 4)

Figure 5-2. Logical Disk Manager driver service settings
Adds the file system driver that's responsible for implementing the code for the type of partition (FAT, FAT32, or NTFS) on which the installation directory resides to the list of boot drivers to load. Ntldr must load this driver at this time; if it didn't, the kernel would require the drivers to load themselves, a requirement that would introduce a circular dependency.
Loads the boot drivers, which should only be drivers that, like the file system driver for the boot volume, would introduce a circular dependency if the kernel was required to load them. To indicate the progress of the loading, Ntldr updates a progress bar displayed below the text "Starting Windows". The progress bar moves for each driver loaded. (It assumes there are 80 boot device drivers each successful load moves the progress bar by 1.25 percent.) If the /SOS switch is specified in the Boot.ini selection, Ntldr doesn't display the progress bar but instead displays the filenames of each boot driver. Keep in mind that the drivers are loaded but not initialized at this time they initialize later in the boot sequence.
Prepares CPU registers for the execution of Ntoskrnl.exe.

This action is the end of Ntldr's role in the boot process. At this point, Ntldr calls the main function in Ntoskrnl.exe to perform the rest of the system initialization.

The IA64 Boot Process

Table 5-3 lists the files involved in the IA64 boot process. IA64 systems conform to the Extensible Firmware Interface (EFI) specification as defined by Intel. An EFI-compliant system has firmware that runs boot loader code that's been programmed into the system's nonvolatile RAM (NVRAM) by Windows Setup. The boot code reads the IA64-equivalent of the x86 and x64 Boot.ini contents, which are also stored in NVRAM. Both Microsoft EFI tools runnable in the EFI console and Bootcfg.exe, a tool included with Windows, allow for modification of the NVRAM boot selections and switches.

Table 5-3. IA64 Boot Process Components
Component	Location	Responsibilities
Fpswa.efi	EFI\Microsoft\Winnt50.x on the EFI System partition	A file that contains support for EFI floating-point operations
Ia64ldr.efi	EFI\Microsoft\Winnt50.x on the EFI System partition	Loads Ntoskrnl.exe, Hal.dll, and boot drivers
Ntoskrnl.exe	\Windows\System32	Initializes executive subsystems and boot and system-start device drivers, prepares the system for running native applications, and runs Smss.exe
Hal.dll	\Windows\System32	Kernel-mode DLL that interfaces Ntoksnrl and drivers to the hardware
Service control manager (SCM)	\Windows\System32	Loads and initializes auto-start device drivers and Windows services
Smss	\Windows\System32	Loads Windows subsystem, including Win32k.sys and Csrss.exe, and starts Winlogon process
Winlogon	\Windows\System32	Starts the service control manager (SCM), the Local Security Authority Subsystem (LSASS), and presents the interactive logon dialog box

Hardware detection occurs next, where the boot loader uses EFI interfaces to determine the number and type of the following devices:

Network adapters
Video adapters
Keyboards
Disk controllers
Storage devices

Just as Ntldr does on x86 and x64 systems, the boot loader then presents a menu of boot selections with an optional timeout. Once a boot selection is made, the loader navigates to the subdirectory on the EFI System partition corresponding to the selection and loads several other files required to continue the boot: Fpswa.efi and Ia64ldr.efi. The EFI specification requires that the system have a partition designated as the EFI System partition that is formatted with the FAT file system and that is between 100 MB and 1 GB in size or up to one percent of the size of the disk, and each Windows installation has a subdirectory on the EFI System partition under EFI\Microsoft. The first installation is assigned the folder Winnt50, the second Winnt50.1, and each subsequent installation has a unique index number following the period in the folder name. Ia64ldr.efi is responsible for loading Ntoskrnl.exe, Hal.dll, and the boot-start drivers, after which the boot proceeds through the same steps as for x86 and x64.

Initializing the Kernel and Executive Subsystems

When Ntldr calls Ntoskrnl, it passes a data structure that contains a copy of the line in Boot.ini that represents the selected menu option for this boot, a pointer to the memory tables Ntldr generated to describe the physical memory on the system, a pointer to the in-memory copy of the HARDWARE and SYSTEM registry hives, and a pointer to the list of boot drivers Ntldr loaded.

Ntoskrnl then begins the first of its two-phase initialization process, called phase 0 and phase 1. Most executive subsystems have an initialization function that takes a parameter that identifies which phase is executing.

During phase 0, interrupts are disabled. The purpose of this phase is to build the rudimentary structures required to allow the services needed in phase 1 to be invoked. Ntoskrnl's main function calls KiSystemStartup, which in turn calls HalInitializeProcessor and KiInitializeKernel for each CPU. KiInitializeKernel, if running on the boot CPU, performs systemwide kernel initialization, such as initializing internal listheads and other data structures that all CPUs share. Each instance of KiInitializeKernel then calls the function responsible for orchestrating phase 0, ExpInitializeExecutive.

ExpInitializeExecutive starts by calling the HAL function HalInitSystem, which gives the HAL a chance to gain system control before Windows performs significant further initialization. One responsibility of HalInitSystem is to prepare the system interrupt controller of each CPU for interrupts and to configure the interval clock timer interrupt, which is used for CPU time accounting. (See the section "Quantum Accounting" in Chapter 6 for more on CPU time accounting.)

Only on the boot processor does ExpInitializeExecutive perform initialization other than calling HalInitSystem. When HalInitSystem returns control, ExpInitializeExecutive on the boot CPU proceeds by processing the /BURNMEMORY Boot.ini switch (if the switch is present in the line from the Boot.ini file that corresponds to the menu selection the user made when choosing which installation to boot) and discarding the amount of memory the switch specifies.

Next, ExpInitializeExecutive calls the phase 0 initialization routines for the memory manager, object manager, security reference monitor, process manager, and Plug and Play manager. These components perform the following initialization steps:

The memory manager constructs page tables and internal data structures that are necessary to provide basic memory services. The memory manager also 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.
During the object manager initialization, the objects that are necessary to construct the object manager namespace are defined so that other subsystems can insert objects into it. A handle table is created 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 local system account token for assignment to the initial process. (See Chapter 8 for a description of the local system account.)
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 a system thread to execute the routine Phase1Initialization. This thread doesn't start running right away because interrupts are still disabled.
The Plug and Play manager's phase 0 initialization then takes place, which involves simply initializing an executive resource used to synchronize bus resources.

When control returns to the KiInitializeKernel function on each processor, control proceeds to the Idle loop, which then causes the system thread created in step 4 of the previous process description to begin executing phase 1. (Secondary processors wait to begin their initialization until step 5 of phase 1, described in the following list.) Phase 1 consists of the following steps. The boot splash screen of Windows 2000 systems includes a progress bar, and the steps at which the progress bar on the screen is updated are included in this list:

HalInitSystem is called to prepare the system to accept interrupts from devices and to enable interrupts.
The boot video driver (\Windows\System32\Bootvid.dll) is called, which in turn displays the Windows startup screen. (On Windows XP and Windows Server 2003 systems, the driver presents the same graphic that Ntldr placed on the screen earlier in the boot.)
The power manager's initialization is called.
The system time is initialized (by calling HalQueryRealTimeClock) and then stored as the time the system booted.
On a multiprocessor system, the remaining processors are initialized and execution starts.
The progress bar is set to 5 percent.
The object manager creates the namespace root directory (\), \ObjectTypes directory, and the DOS device name mapping directory (\?? on Windows 2000, and \Global?? on Windows XP and Windows Server 2003). It then creates the \DosDevices symbolic link that points at the DOS device name mapping directory.
The executive is called to create the executive object types, including semaphore, mutex, event, and timer.
The kernel initializes scheduler (dispatcher) data structures and the system service dispatch table.
The security reference monitor creates the \Security directory in the object manager namespace and initializes auditing data structures if auditing is enabled.
The progress bar is set to 10 percent.
The memory manager is called to create the section object and the memory manager's system worker threads (which are explained in Chapter 7).
National language support (NLS) tables are mapped into system space.
Ntdll.dll is mapped into the system address space.
The cache manager initializes the file system cache data structures and creates its worker threads.
The configuration manager creates the \Registry key object in the object manager namespace and copies the initial registry data passed by Ntldr into the HARDWARE and SYSTEM hives.
Global file system driver data structures are initialized.
The Plug and Play manager calls the Plug and Play BIOS.
The progress bar is set to 20 percent.
The local procedure call (LPC) subsystem initializes the LPC port type object.
If the system was booted with boot logging (/BOOTLOG), the boot log file is initialized.
The progress bar is set to 25 percent.
The I/O manager initialization now takes place. This stage is a complex phase of system startup that accounts for 50 percent of the "progress" reported in the progress bar. The I/O manager considers each successful driver load to be another 2 percent of progress for the boot. (If there are more than 25 drivers to load, the progress bar stops at 75 percent.)
The I/O manager first initializes various internal structures and creates the driver and device object types. It then calls the Plug and Play manager, power manager, and HAL to begin the various stages of dynamic device enumeration and initialization. (Because this process is complex and specific to the I/O system, we'll save the details for Chapter 9.) Then the Windows Management Instrumentation (WMI) subsystem is initialized, which provides WMI support for device drivers. (See the section "Windows Management Instrumentation" in Chapter 4 for more information.) Next, all the boot-start drivers are called to perform their driver-specific initialization, and the system-start device drivers are loaded and initialized. (Details on the processing of the driver load control information on the registry are also covered in Chapter 9.) Finally, the MS-DOS device names are created as symbolic links in the object manager's namespace.
The progress bar is set to 75 percent.
If the computer is booting in safe mode, this fact is recorded in the registry.
Unless explicitly disabled in the registry, paging of kernel-mode code (in Ntoskrnl and drivers) is enabled.
The progress bar is set to 80 percent.
The power manager is called to initialize various power management structures.
The progress bar is set to 85 percent.
The security reference monitor is called to create the Command Server Thread that communicates with Lsass. (See the section "Security System Components" in Chapter 8 for more on how security is enforced in Windows.)
The progress bar is set to 90 percent.
The last step is to create the Session Manager subsystem (Smss) process (introduced in Chapter 2). Smss is responsible for creating the user-mode environment that provides the visible interface to Windows its initialization steps are covered in the next section.
The progress bar is (finally) set to 100%.

As a final step before considering the executive and kernel initialization complete, the phase 1 initialization thread waits for the handle to the Session Manager process with a timeout value of 5 seconds. If the Session Manager process exits before the 5 seconds elapse, the system crashes itself with a SESSION5_ INITIALIZATION_FAILED bug check code.

If the 5-second wait times out (that is, if 5 seconds elapse), the Session Manager is assumed to have started successfully, and the phase 1 initialization function calls the memory manager's zero page thread function (explained in Chapter 7). Thus, this system thread becomes the zero page thread for the remainder of the life of the system.

Smss, Csrss, and Winlogon

Smss is like any other user-mode process except for two differences: First, Windows considers Smss a trusted part of the operating system. Second, Smss is a native application. Because it's a trusted operating system 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 Windows APIs it uses only core executive APIs known collectively as the Windows native API. Smss doesn't use the Windows APIs because the Windows subsystem isn't executing when Smss launches. In fact, one of Smss's first tasks is to start the Windows subsystem.

Smss then calls the configuration manager executive subsystem to finish initializing the registry, fleshing the registry out to include all its keys. The configuration manager is programmed to know where the core registry hives are stored on disk (excluding hives corresponding to user profiles), and it records the paths to the hives it loads in the HKLM\SYSTEM\Current-ControlSet\Control\hivelist key.

The main thread of Smss performs the following initialization steps:

Creates an LPC port object (\SmApiPort) and two threads to wait for client requests (such as to load a new subsystem or create a session).
Defines the symbolic links for MS-DOS device names (such as COM1 and LPT1).
If Terminal Services is installed, creates the \Sessions directory in the object manager's namespace (for multiple sessions).
Runs any programs defined in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute. Typically, this value contains one command to run Autochk (the boot-time version of Chkdsk).
Performs delayed file rename and delete operations as directed by HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations and HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations2.
Opens known DLLs, and creates section objects for them in the \Knowndlls directory of the Object Manager namespace. The list of DLLs considered known is located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs, and the path to the directory in which the DLLs are located is stored in the Dlldirectory value of the key. See Chapter 6 for information on how the Known DLLs sections are used during DLL loading.
Creates additional paging files. Paging file configuration is stored under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PagingFiles.
Initializes the registry. The configuration manager fleshes out the registry by loading the registry hives for the HKLM\SAM, HKLM\SECURITY, and HKLM\SOFTWARE keys. Although HKLM\SYSTEM\CurrentControlSet\Control\hivelist locates the hive files on disk, the configuration manager is coded to look for them in \Windows\System32\Config.
Creates system environment variables that are defined in HKLM\System\CurrentControlSet\Session Manager\Environment.
Loads the kernel-mode part of the Windows subsystem (Win32k.sys). Smss determines the location of Win32k.sys and other components it loads by looking for their paths in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager. The initialization code in Win32k.sys uses the video driver to switch the screen to the resolution defined by the default profile, so this is the point at which the screen changes from the VGA mode the boot video driver uses to the default resolution chosen for the system.
Starts the subsystem processes, including Csrss. (As noted in Chapter 2, on Windows 2000 the POSIX and OS/2 subsystems are defined to start on demand.)
Starts the logon process (Winlogon). The startup steps of Winlogon are described shortly.
Creates LPC ports for debug event messages (DbgSsApiPort and DbgUiApiPort) and threads to listen on those ports.

Pending File Rename Operations

The fact that executable images and DLLs are memory-mapped when they are used makes it impossible to update core system files after Windows has finished booting. The MoveFileEx Windows API has an option to specify that a file move be delayed until the next boot. Service Packs and hotfixes that must update in-use memorymapped files install replacement files onto a system in temporary locations and use the MoveFileEx API to have them replace otherwise in-use files. When used with that option, MoveFileEx simply records commands in the PendingFileRenameOperations and PendingFileRenameOperations2 values under HKLM\SYSTEM\CurrentControlSet\ Control\Session Manager. These registry values are of type MULTI_SZ, where each operation is specified in pairs of file names: the first file name is the source location, and the second is the target location. Delete operations use an empty string as their target path. You can use the Pendmoves utility from http://www.sysinternals.com to view registered delayed rename and delete commands.

After performing these initialization steps, the main thread in Smss waits forever for the process handles to Csrss and Winlogon. If either of these processes terminates unexpectedly, Smss crashes the system, because Windows relies on their existence. (In Windows XP and later, if Csrss exits for any reason, the kernel crashes the system, not the Smss.)

Winlogon then performs its startup steps, such as creating the initial window station and desktop objects. If a DLL is specified in HKLM\Software\Microsoft\Windows NT\Current Version\WinLogon\GinaDLL, Winlogon uses that DLL as the GINA; otherwise, it uses the Microsoft default GINA, Msgina (\Windows\System32\Msgina.dll), which displays the standard Windows logon dialog box. Winlogon then creates the service control manager (SCM) process (\Windows\System32\Services.exe), which loads all services and device drivers marked for auto-start, and the local security authentication subsystem (Lsass) process (\Windows\System32\Lsass.exe). (For more details on the startup sequence for Winlogon and Lsass, see the section "Winlogon Initialization" in Chapter 8.)

After the SCM initializes the auto-start services and drivers and a user has successfully logged on at the console, the SCM deems the boot successful. The registry last known good control set (as indicated by HKLM\SYSTEM\Select\LastKnownGood) is updated to match \Current-ControlSet.

Note

Because noninteractive servers might never have an interactive logon, they might not get LastKnownGood updated to reflect the control set used for a successful boot.

You can override the definition of a successful boot by setting HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ReportBootOk to 0, writing a custom boot verification program that calls the NotifyBootConfigStatus Windows API when a boot is successful, and entering the path to the verification program in HKLM\System\CurrentControlSet\Control\BootVerificationProgram.

After launching the SCM, Winlogon waits for an interactive logon notification from the GINA. When it receives a logon and validates the logon (a process for which you can find more information in the section "User Logon Steps" in Chapter 8), Winlogon loads the registry hive from the profile of the user logging in and maps it to HKCU. It then sets the user's environment variables that are stored in HKCU\Environment and notifies the Winlogon notification packages registered in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify that a logon has occurred.

Winlogon next tells the GINA to start the shell. In response to this request, Msgina launches the executable or executables specified in HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\Userinit (with multiple executables separated by commas) that by default points at \Windows\System32\Userinit.exe. Userinit.exe performs the following steps:

Processes the user scripts specified in HKCU\Software\Policies\Microsoft\Windows\System\Scripts and the machine logon scripts in HKLM\Software\Policies\Microsoft\Windows\System\Scripts. (Because machine scripts run after user scripts, they can override user settings.)
If group policy specifies a user profile quota, starts \Windows\System32\Proquota.exe to enforce the quota for the current user.
Launches the comma-separated shell or shells specified in HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell. If that value doesn't exist, Userinit.exe launches the shell or shell specified in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell, which is by default Explorer.exe.

Winlogon then notifies registered network providers that a user has logged in. The Microsoft network provider, Multiple Provider Router (\Windows\System32\Mpr.dll), restores the user's persistent drive letter and printer mappings stored in HCU\Network and HKCU\ Printers, respectively. Figure 5-3 shows the process tree as seen in Process Explorer during a login before Userinit has exited.

Figure 5-3. Process tree during logon

Images that Start Automatically

In addition to the Userinit and Shell registry values in Winlogon's key, there are many other registry locations and directories that default system components check and process for automatic process startup during the boot and logon process. The Msconfig utility (included in Windows XP and Windows Server 2003 in \Windows\System32\Msconfig.exe) displays the images configured by several of the locations. Sysinternals' Autoruns tool, which you can download from http://www.sysinternals.com and that is shown in Figure 5-4, examines more locations than Msconfig and displays more information about the images configured to automatically run. By default, Autoruns shows only the locations that are configured to automatically execute at least one image, but checking the Include Empty Locations entry in the View menu causes Autoruns to show all the locations it inspects. The View menu also has selections to direct Autoruns to display information about other types of autostarting images, such as Windows services and Explorer add-ons.

Figure 5-4. The Autoruns tool available from http://www.sysinternals.com

EXPERIMENT: Autoruns

Many users are unaware of how many programs execute as part of their logon. Original equipment manufacturers (OEMs) often configure their systems with add-on utilities that execute in the background using registry values or file system directories processed for automatic execution and so are not normally visible. See what programs are configured to start automatically on your computer by running the Autoruns utility from http://www.sysinternals.com. Compare the list shown in Autoruns with that shown in Msconfig (available on Windows XP and Windows Server 2003), and identify any differences. Then ensure that you understand the purpose of each program.