WINDOWS XP

Startup and Shutdown Boot Process

Start with the installation of Windows XP and proceed through the execution of Ntldr and Ntdetect.

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 XP by starting the Session Manager process (Smss.exe), the Win32 subsystem, and the logon process (Winlogon).

Component Processor

ExecutionResponsibilities

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 protected mode;turns on paging

Reads Boot.ini, presents boot menu, and loads Ntoskrnl.exe, Bootvid.dll, Hal.dll, and boot-start device drivers

Ntoskrnl.exe 32-bit 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

Smss 32-bit native application

Loads Win32 subsystem, including Win32k.sys and Csrss.exe, and starts Winlogon process

Winlogon 32-bit native application

Starts the service control manager (SCM), the Local Security Subsystem (Lsass), and presents interactive logon dialog box

Service control manager (SCM)

32-bit native application

Loads and initializes auto-start device drivers and Win32 services

Boot Process Components

Pre Boot Instalation WXP on the computer the system's primary hard disk is prepared with code that

takes part in the boot process. So what code ? let's look at how and where Windows XP places the code

on a disk Since the early days of MSDOS, 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.

Continued 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 logical drives, including the MS-DOS Fdisk utility or the Windows XP Setup program, write a sector of data called a master boot record (MBR) to the first sector on a hard disk.

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 reads the MBR into memory and transfers control to the code in the MBR.

Continued The MBRs written by Microsoft partitioning tools,

such as the one integrated into Windows XP 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.

Continued Operating systems generally write boot sectors

to disk without a user's involvement. For example, when Windows XP 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 used the MS-DOS sys command to manually write MS-DOS boot sectors to disks.

Windows XP Setup checks to see whether the boot sector it will overwrite with a Windows XP boot sector is a valid MS-DOS boot sector. If it is, Windows XP Setup copies the boot sector's contents to a file named Bootsect.dos in the root directory of the partition.

Continued Before writing to a partition's boot sector,

Windows XP Setup ensures that the partition is formatted with a file system that Windows XP 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 XP uses to the logical disk drive, 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 boot partition. This file contains options for starting the

version of Windows XP that Setup installs and any preexisting Windows XP 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 an example Boot.ini file from a dual-boot computer on which MS-DOS is installed before Windows XP :

Boot.ini[boot loader]

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

C:\="Microsoft Windows"

/FASTDETECT

Default boot option for Windows XP. 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 XP 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 deviceenumeration (actions that are not required when booting Windows XP), whereas omitting the switch causes NTDETECT to perform this enumeration (which isrequired for booting Windows NT 4).

The 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 XP writes code to the boot sector that understands the FAT file system. But if the partition is in NTFS format, Windows XP writes NTFS-capable code.

The role of the boot-sector code is to give Windows XP information about the structure and format of a logical disk drive and to read in the Ntldr file from the root directory of the logical disk drive. 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 logical disk drive's root directory, it displays the error message "BOOT: Couldn't find NTLDR" if the boot file system is FAT or "NTLDR is missing" if the file system is NTFS.

Continued 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 XP executes in normal operation.

Continued 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 boot-code functions briefly switch off paging and switch the processor back to a mode in which services provided by the BIOS can be executed.

If either the boot or system drives are SCSI-based, Ntldr loads a file named Ntbootdd.sys and uses it instead of the boot-code functions for disk access.

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.

Continued Ntldr clears the screen and 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 XP system directory (typically \Winnt) of the selected installation resides. This partition might be the same as the boot partition, or it might be another primary partition.

Continued 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 MSDOSspecific boot, such as is used to boot Microsoft Windows 98 or Microsoft Windows 95 on a computer on which these operating systems are installed with Windows XP.

Continued 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.

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

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

Continued 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 XP, 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.

Cotinued Next, Ntldr begins loading the files from the boot

partition needed to start the kernel initialization:1. 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 XP could not start because the following file was missing or corrupt," followed by the name of the file.

2. Reads in the SYSTEM registry hive, \Winnt\System32\Config\System, so that it can determine which device drivers need to be loaded to accomplish the boot.

3. 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. 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 below.

Continued4. 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.

5. Loads the boot drivers. 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.

6. 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.

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.

Continue 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.

Continue ExpInitializeExecutive starts by calling

the HAL function HalInitSystem, which gives the HAL a chance to gain system control before Windows XP 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.

Continue 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.

Continue 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:

1. 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.

2. 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.

3. 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.

4. 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 creates a system thread to execute the routine Phase1Initialization. This thread doesn't start running right away because interrupts are still disabled.

5. 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.

Continue Phase 1 consists of the following steps :

1. HalInitSystem is called to prepare the system to accept interrupts from devices and to enable interrupts.

2. The boot video driver (\Winnt\System32\Bootvid.dll) is called, which in turn displays the Windows XP startup screen.

3. The power manager's initialization is called. 4. The system time is initialized (by calling HalQueryRealTimeClock)

and then stored as the time the system booted. 5. On a multiprocessor system, the remaining processors are

initialized and execution starts. 6. The progress bar is set to 5 percent. 7. The object manager creates the namespace root directory, \

ObjectTypes directory, \?? directory, and the \DosDevices link to the \?? directory.

8. The executive is called to create the executive object types, including semaphore, mutex, event, and timer.

9. The kernel initializes scheduler (dispatcher) data structures and the system service dispatch table.

10. The security reference monitor creates the \Security directory in the object manager namespace and initializes auditing data structures if auditing is enabled.

Continued11.The progress bar is set to 10 percent. 12.The memory manager is called to create the section object and the

memory manager's system worker threads13.National language support (NLS) tables are mapped into system space. 14.Ntdll.dll is mapped into the system address space. 15.The cache manager initializes the file system cache data structures

and creates its worker threads. 16.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.

17.Global file system driver data structures are initialized. 18.The Plug and Play manager calls the Plug and Play BIOS. 19.The progress bar is set to 20 percent. 20.The local procedure call (LPC) subsystem initializes the LPC port type

object. 21.If the system was booted with boot logging (/BOOTLOG), the boot log

file is initialized. 22.The progress bar is set to 25 percent.

Continue23.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 the HAL to begin the various stages of dynamic device enumeration and initialization. (Because this process is complex and specific to the I/O system) Then the Windows Management Instrumentation (WMI) subsystem is initialized, which provides WMI support for device drivers that adhere to the Windows Driver Model(WDM). Next, all the boot-start drivers are called to perform their driver-specific initialization, and the system-start device drivers are loaded and initialized. Finally, the MS-DOS device names are created as symbolic links in the object manager's namespace.

24.The progress bar is set to 75 percent. 25.If booting in safe mode, this fact is recorded in the registry. 26.Unless explicitly disabled in the registry, paging of kernel-mode code (in

Ntoskrnl and drivers) is enabled.

Continue27.The progress bar is set to 80 percent. 28.The power manager is called to initialize various power management

structures. 29.The progress bar is set to 85 percent. 30.The security reference monitor is called to create the Command Server

Thread that communicates with Lsass. 31.The progress bar is set to 90 percent. 32.The last step is to create the Session Manager subsystem (Smss)

process.Smss is responsible for creating the user-mode environment that provides the visible interface to Windows XP—its initialization steps are covered in the next section.

33.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 on the handle to the Session Manager process with a timeout value of 5 seconds. If the Session Manager process exits before the 5 seconds elapses, 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. 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 XP 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 Win32 APIs—it uses only core executive APIs known collectively as the Windows 2000 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 first tasks is to start the Win32 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 records the paths to the hives it loads in the HKLM\SYSTEM\CurrentControlSet\Control\hivelist key.

Continue The main thread of Smss performs the following initialization steps:

1. 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).

2. Defines the symbolic links for MS-DOS device names (such as COM1 and LPT1). 3. If Terminal Services is installed, creates the \Sessions directory in the object manager's

namespace (for multiple sessions). 4. 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).

5. Performs delayed file rename operations as directed by HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations. Pending file deletes are in PendingFileRenameOperations2.

6. Opens known DLLs. 7. Creates additional paging files. 8. 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 \Winnt\System32\Config.

9. Creates system environment variables. 10.Loads the kernel-mode part of the Win32 subsystem (Win23k.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.

Continue11. Starts the subsystem processes, including Csrss.

(As noted the POSIX and OS/2 subsystems are defined to start on demand.)

12. Starts the logon process (Winlogon). The startup steps of Winlogon are described shortly.

13. Creates LPC ports for debug event messages (DbgSsApiPort and DbgUiApiPort) and threads to listen on those ports.

After performing these initialization steps, the main thread in Smss waits forever on the process handles to Csrss and Winlogon.

If either of these processes terminates unexpectedly, Smss crashes the system, since Windows XP relies on their existence.

Continue Winlogon then performs its startup steps, such as creating the

initial window station and desktop objects, loading GINA DLLs, and so on. It then creates the service control manager (SCM) process (\Winnt\System32\Services.exe), which loads all services and device drivers marked for auto-start, and the local security authentication subsystem (Lsass) process (\Winnt\System32\Lsass.exe).

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 \CurrentControlSet. If a user chooses to boot to the last known good menu during the first steps of a boot, or if a driver returns a severe or critical error, the system uses the LastKnownGood value as the current control set. Doing so increases the chances that the system will boot successfully, because at least one previous boot using the last known good profile was successful.

END OF PROCESS

That action brings us to the end of the boot process.