Functional Description of the Windows Server 2003 Boot Process

Functional Description of the Windows Server 2003 Boot Process

Computers are like airplanes: they are most prone to accidents during takeoffs and landings. This topic contains a detailed analysis of the Windows Server 2003 boot process for use in troubleshooting upgrade and setup problems.

What follows is the IA32 boot process. The IA64 boot process is much simpler because EFI locates and launches the secondary bootstrap loader, Ia64ldr.efi, using information stored in Non-Volatile RAM (NVRAM). If you have an IA64 system, skip to the "System Kernel" topic later in this chapter.

Initial Bootstrap

When you turn on any IA32 computer, the system starts out with a Power On Self Test (POST). Specific actions during the POST vary from system to system. A short beep at the end indicates a successful completion. For IA64 computers, the POST includes a full system configuration check done by the Extensible Firmware Interface (EFI).

The final step in the POST for IA32 machines is a handoff to an INT13 routine in BIOS that checks for a bootable device. For IA64 machines, the EFI finds the bootstrap loader using information in the boot menu.

Depending on your BIOS settings, the boot routine usually starts at the A: drive followed by the drive determined by the system BIOS to be the boot drive. This is the master drive on the primary IDE interface, if one exists, followed by the SCSI drive designated as the boot drive in the SCSI BIOS. You cannot boot to a SCSI drive if a bootable IDE drive is present. The system loads the Master Boot Record (MBR) from this drive.

There is executable code in the MBR that is just smart enough to scan the partition table at the end of the MBR to find the sector/offset of the active boot partition. If the code cannot find suitable entries in the partition table, it displays the error Invalid Partition Table. If the code finds a partition table but cannot locate the start of the active partition, it displays either the error Error Loading Operating System or the error Missing Operating System.

Secondary Bootstrap

When the executable code in the MBR finds the start of the active partition, it loads the first sector (512 bytes) into memory at location 0x700h. This is the called the partition boot sector, or more commonly just the boot sector. The boot sector contains executable code designed to find and load a secondary bootstrap loader. The executable code in the boot sector cannot read a file system, so the secondary bootstrap loader must be at the root of the boot drive.

On a DOS machine, the secondary bootstrap loader is IO.SYS. On IA32 versions of Windows Server 2003 and XP, Windows 2000, and NT, the secondary bootstrap loader is Ntldr. If Ntldr is missing or will not load, the boot sector code displays error messages such as A disk read error has occurred or Ntldr is missing or Ntldr is compressed. In all these events, the message includes the instructions Press Ctrl+Alt+Del to restart.


When Ntldr executes, it initializes the video hardware and puts the screen in 80x25 mode with a black background. It then switches the processor to Protected mode to support 32-bit memory addressing and initializes miniature versions of the NTFS and FAT file system drivers contained in the Ntldr code itself. These file system drivers permit Ntldr to see enough of the drive to load the remaining Windows Server 2003 system files.

Ntldr now locates a file called Boot.ini, which contains the Windows Server 2003 boot menu. See the "Working with Boot.ini" section later in this chapter for details about the entries in Boot.ini. If Ntldr cannot find Boot.ini, it displays the error Windows Server 2003 could not start because the following file is missing or corrupt: Boot.ini. If Boot.ini is present but does not contain valid entries, any number of errors can appear. Generally, they indicate a problem with default ARC path.

If there is only one entry in the Boot.ini file, Windows Server 2003 automatically uses that entry with no delay time. If there are multiple entries, the delay time is set to 30 seconds by default.

Ntldr Versions

The Windows Server 2003 version of Ntldr can load Windows 2000 and NT4 boot files, but the opposite is not true. Keep this in mind if you apply a service pack or do an emergency repair on a dual-boot machine. If you overwrite Ntldr, you cannot boot to Windows Server 2003. If you accidentally overwrite Ntldr, you can replace it with a copy from another Windows Server 2003 machine. The same Ntldr is used in Windows Server 2003 and XP.

If you install Windows Server 2003 in addition to an existing operating system such as Windows 9x or DOS, the boot sector from the previous operating system is saved in a file called Bootsect.dos. The alternate operating system becomes a selection in the boot menu.

If you select the alternate operating system from the boot menu, Ntldr loads the contents of Bootsect.dos into memory at file location 700h, shifts back to Real mode, and turns control over to the executable code in the boot sector image.

You can quickly change the boot menu delay time in both IA32 and IA64 systems using the new BOOTCFG utility in Windows Server 2003. The syntax is bootcfg /timeout # where # is the number of seconds. You can set the delay time to 0 to avoid the menu entirely.

On IA32 systems, you can manually edit the Boot.ini file to set the timeout value to –1 to disable the countdown timer completely. In this configuration, the system will sit at the boot menu until you make a selection. You can do the same on IA64 systems using the Boot Manager Maintenance utility.

Before Ntldr can execute the kernel image, it needs to know something about the hardware. This is the cue for, which gathers the same kind of information on an IA32 machine that EFI delivers from firmware on an IA64 machine.

Don't confuse Ntdetect with the Plug and Play Manager. PnP enumeration happens much further along in the boot process. Ntdetect looks for the following hardware configurations: (The CPU type and FPU type are detected later on by Ntoskrnl. exe and Hal.dll.)

  • Machine ID

  • Bus/adapter type

  • Video

  • Keyboard

  • Communication port

  • Parallel port

  • Floppy Drive

  • Mouse

Alternative SCSI Driver

If you boot to a SCSI drive, the SCSI interface should have a BIOS that determines the bootable device. If the SCSI adapter does not have a BIOS, or if the BIOS is disabled, the ARC path in Boot.ini will specify the SCSI ID number of the bootable drive. This means Ntldr needs a way to scan the SCSI bus looking for the SCSI ID.

If Setup detects that a SCSI interface does not have a functioning BIOS, it copies the SCSI miniport driver to the root of the boot partition and renames it Ntbootdd.sys. Ntldr loads Ntbootdd.sys and uses the miniport driver to communicate with the drives. The Ntbootdd.sys file must be at the root of the drive because Ntldr must be able to find it using straight INT13 calls.

Ntdetect uses this information to build a data structure in memory that is used later on by the kernel driver to construct the Hardware hive in the Registry.

System Kernel

If you select a Windows Server 2003 operating system from the boot menu, the secondary bootstrap loader (Ntldr for IA32 and Ia64ldr for IA64) uses that partition to load the operating system kernel, Ntoskrnl.exe, and its associate Hardware Abstraction Layer library, Hal.dll, along with a video driver, Bootvid.dll. The secondary bootstrap loader puts the images of the kernel files in memory but does not execute them quite yet. First, it searches out and loads the service drivers.

If the secondary bootstrap loader does not find Ntoskrnl.exe, it gives the error Windows Server 2003 could not start because the following file is missing or corrupt:\<systemroot>\system32\Ntoskrnl.exe. The most likely cause of this error is an incorrect path in the boot menu entry, although corruption of the file system on the volume can also be the culprit.

If Boot.ini is missing, Ntldr defaults to the drive containing the system partition and searches for a partition containing Ntoskrnl.exe. You'll see this as a "Default" entry in the boot menu.

Initial Service Drivers

The secondary bootstrap loader opens the System hive in the Registry and checks the Select key to find the CurrentControlSet. It then scans the list of Services keys in the CurrentControlSet looking for devices with a Start value of 0, indicating Service_Boot_Start, and 1, indicating Service_System_Start. It loads these drivers in the order specified by the Group value under Control, Service Group Order.

At this point, the console shows a Starting Windows Server 2003 message along the bottom of the screen with a progress bar that slides along as the drivers load. When this is complete, the secondary bootstrap loader initializes Ntoskrnl.exe and hands over the driver images now stored in memory.

Kernel Initialization

When Ntoskrnl starts, it initializes Hal.dll and Bootvid.dll. The screen now shifts to graphic mode. Ntoskrnl then initializes the system drivers and uses information from (IA32) or EFI (IA64) to create a volatile Hardware hive in the Registry. It then calls on the Session Manager, Smss.exe, to do a little preliminary housekeeping.

Session Manager

Session Manager reads its own key in the System hive under HKLM | System | CurrentControlSet | Control | Session Manager to find entries under BootExecute. By default, this includes AUTOCHK, a boot-time version of CHKDSK. Session Manager also sets up the paging file, Pagefile.sys. After Session Manager finishes its chores, it does the following two things simultaneously:

  • Loads the console logon service, Winlogon.exe, to start the authentication verification process. Winlogon starts the Local Security Authority Subsystem, LSASS.EXE, and the print spooler, SPOOLSS.EXE, along with their supporting function libraries.

  • Loads the Services Controller, Screg.exe, to finish loading the rest of the devices and services.

In NT, users were often mystified by the long delay between entering their credentials at the logon window and getting to the desktop. In Windows 2000, Microsoft withheld the logon window until the service drivers initialized. In Windows Server 2003, to speed up access to the console, the user is permitted to log on even though many of the services are still being initialized. As long as the user credentials are correct, there's a happy ending. Bring up the violin music. Fade to credits.

If Screg cannot start a device or service, it takes action as defined in the associated Registry key. This runs the gamut from putting a simple message in the Event log to crashing the system with a stop error. If the problem is not catastrophic, Screg displays a console message telling you that a problem occurred and that you should check the Event log. This console message does not always appear, so you should always check the log when you start a server. Histories of abnormal starts should be investigated and the problem isolated and corrected.

Registry Tip: Forcing AUTOCHK to Repair

AUTOCHK normally runs in read-only mode, so it reports problems but does not repair them. You can force AUTOCHK to repair file system problems (similar to running Chkdsk /f) by putting a /p after the entry in the Registry:


HKLM | System | CurrentControlSet | Control | Session Manager




Autochk * /p

Delaying Initial Console Logon

The Registry entries for the service drivers are stored in a key called the Control Set. By default, there are two Control Set keys, named Control Set 1 and Control Set 2. As we'll see in Chapter 21, "Recovering from System Failures," one of the actions performed by the Session Manager following a successful logon is to copy the Control Set used to boot the system into Control Set 2 and to declare this the Last Known Good Control Set.

It sometimes happens that a problem crops up a little after a successful logon. By that time, it is too late to restart the system using the Last Known Good Control Set option. You can avoid this problem by making a quick network connection (not a remote desktop connection) to the server and checking for errors in the System log prior to performing the console logon.

Working with Boot.ini

The IA32 secondary bootstrap loader, Ntldr, relies on Boot.ini to locate the Windows Server 2003 boot partition and the folder containing the boot files. If you encounter strange behavior during restart following an upgrade, or when adding new mass storage hardware, start your investigations with a look at Boot.ini. For details of the contents of a boot menu entry in an IA64 machine, see Chapter 3, "Adding Hardware." Here is an example of a Boot.ini file for a system that also has a DOS partition:

[boot loader]

[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\Windows="Windows Server 2003, Standard Edition" /
c:\= "MS/DOS"

The long, inscrutable entry under [operating systems] is the Advanced RISC Computing path (ARC path). The ARC path is a pointer that leads Ntldr to a Windows Server 2003 partition. ARC syntax uses this convention:

controller()disk()rdisk()partition()\systemroot="menu listing"

The following subsections explain what each entry means.

controller()—Interface Type

There are three possible entries:

  • multi(). Indicates IDE drives and SCSI drives with an onboard BIOS. The number in parentheses is the ordinal ID of the IDE or SCSI controller. If Windows Server 2003 is installed on a drive connected to the secondary IDE controller, the ARC entry would be multi(1).

  • scsi(). Indicates a SCSI controller with no onboard BIOS or a BIOS that has been disabled. This is a legacy entry from classic NT and no longer used in Windows Server 2003.

  • signature(). Indicates that the drive is not accessible by standard INT13 calls and requires special handling by Ntldr. The number in parentheses is a signature written to the MBR of the disk when it is partitioned during Setup.

System File Attributes and Superhidden Definition

The Boot.ini file attributes are set to System and Read-only by default. This prevents a casual user from modifying or deleting the file. If you need to modify the contents of Boot.ini, use Attrib to toggle the read-only attribute.

The remaining system files, such as Ntldr,, and Ntbootdd.sys, have both the System and Hidden attributes set. This is a superhidden configuration and keeps the files hidden even if users set the User Interface to show hidden files. Superhidden files are not hidden if you run DIR /A from the command line.

If the controller type is signature() and the drive is on a SCSI bus with an interface that does not have a BIOS, Ntldr uses the SCSI miniport driver in Ntbootdd.sys to read the drives and find the matching signature.

disk()—SCSI ID

The disk() entry was used in conjunction with the scsi() controller type to indicate the SCSI ID of the disk where the boot files are located. It is no longer required in Windows Server 2003 because the signature() entry identifies the drive uniquely without the SCSI ID. For controller designations of multi(), the value for disk() is always 0.

rdisk()—Relative Disk Location

The rdisk() entry is used in conjunction with multi() to indicate the relative disk location. For IDE drives, the relative disk location is determined by the master/slave designation. For example, the slave drive on the first IDE controller would have an ARC designator of multi(0)disk(0)rdisk(1).

For SCSI drives, the relative disk location is determined by the device scan performed by the SCSI BIOS during POST. Generally, the scan order matches the SCSI ID order. If the BIOS reports that there are three drives on the bus, for example, the ARC designator for the third drive would be multi(0)disk(0)rdisk(2) regardless of the SCSI ID. If you select a drive other than 0 to be the boot drive, the relative disk locations would change.

For controller designations of signature(), the value for rdisk() is always 0 because the system uses the MBR signature to find the drive.

partition()—Boot Partition Sequence Number

This is the sequential number of the boot partition. Note that this sequence starts with 1, not 0. See the upcoming sidebar, "Automatic Partition Number Changes," for curious aspects to the numbering sequences.

\systemroot—Windows Server 2003 System Directory

The default system directory in Windows Server 2003 is \Windows. That path is used in all examples in this book. A different name can be chosen during Setup. The environment variable %systemroot% displays the name of the system directory. You should have only one system root directory on any given partition. Microsoft strongly discourages having multiple Windows installations in the same partition because there are files in locations other than %systemroot% that are maintained by the operating system.

"menu listing"—Menu Text

The text in quotation marks is displayed as the menu listing in the boot menu. You can change this text if it helps your users to navigate to the right entry; under normal circumstances, however, users could care less and don't want to see the menu anyway.

ARC Path Examples

Assume, for example, that you have a machine configured with several versions of Windows Server 2003 and NT along with a dual-boot to DOS. The drives and partitions are set up as shown in Figure.

Example Partition Tables


Drive #

Partition #


ID 0




ID 0



NTW 4.0

ID 1



NTS 4.0

ID 2



XP Pro

ID 2



Windows Server 2003 Standard Edition

Automatic Partition Number Changes

There are a few subtleties to the way ARC paths are derived. It is possible to cause a change in the partition numbering without realizing it. Windows Server 2003 anticipates this and changes the ARC paths in Boot.ini automatically. Here's how it works.

A basic Intel IA32 disk can have up to four primary partitions. These primary partitions are numbered sequentially. For example, if you install Windows Server 2003 into the second primary partition, the ARC path entry would be partition(2).

In addition to primary partitions, the drive can have a maximum of one extended partition with as many logical drives as you require. These logical drives also act as partitions in the ARC path. For example, if you install Windows Server 2003 into the second logical drive of an extended partition on a drive that has one other primary partition, the ARC path entry would be partition(3).

When calculating ARC path partitions, Windows Server 2003 counts primary partitions first, then logical drives in an extended partition. This is exactly the opposite of the way drive letters are assigned during Setup, so it may or may not be counterintuitive to you.

Let's say you have a multiple boot machine with a primary partition and a secondary partition with a single logical drive. Windows Server 2003 is installed in the second logical drive. Again, the ARC path entry would be partition(3).

You have a few gigabytes of free space beyond the extended partition. You use it to install another copy of Windows Server 2003 in a new primary partition. (It cannot be an extended partition, because you can only have one on a disk.) The ARC path entry for this instance of Windows Server 2003 would be partition(2) because the primary partitions are counted before the logical drives.

You might now expect the partition() entry for the first Windows Server 2003 installation to be invalid. It should be partition(4). Windows Server 2003 anticipates this problem and automatically changes the ARC path to match the new location of the partition.

This is a new trick in Windows Server 2003, and it doesn't always work, so you may need to change the ARC path manually.

You can modify Boot.ini switches using the new BOOTCFG utility in both the IA32 and IA64 versions of Windows Server 2003. This utility has a variety of features for scripting Boot.ini modifications. In addition, the Help and Support Center exposes a GUI-based utility called the System Configuration Utility, or Msconfig, that simplifies making Boot.ini changes.

Here are the ARC paths for each boot partition:

multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows NT Workstation Version 4.0"
multi(0)disk(0)rdisk(1)partition(1)\WINNT="Windows NT Server Version 4.0"
multi(0)disk(0)rdisk(2)partition(1)\WINNT="Windows XP Professional" /fastdetect
multi(0)disk(0)rdisk(2)partition(2)\WINNT="Windows Server 2003 Standard Edition" /
Boot.ini Switches

Here are the major options and switches used in Boot.ini:

  • Timeout. This determines the pause duration before Ntldr goes to the default partition. The default is 30 seconds.

  • Default. This determines the partition that will be used to boot the system if no action is taken.

  • [Operating Systems]. Lists the bootable partitions by their ARC paths.

  • /3GB. Changes the apportionment of virtual memory to give 3GB to user processors and 1GB to the system. This switch only works on Enterprise and Datacenter Editions.

  • /bootlog. Writes a boot log to a file called Ntbtlog.txt in the \Windows directory.

  • /cmdcons. Used in conjunction with loading the Recovery Console.

  • /fastdetect. Skips PnP enumeration of serial interfaces until the graphic portion of the system loads.

  • /maxmem. Used for troubleshooting memory-related problems. This switch limits the amount of real memory the system will use. If you think you have a bad bank of memory, set this value below the second bank. If your problems disappear, replace the memory. You can also use this switch for testing memory-related performance issues.

  • /pae and /nopae. Configures an Enterprise Edition or Datacenter Edition to use the Physical Address Extensions for accessing memory above 4GB. The /nopae switch disables the feature for troubleshooting.

  • /pcilock. Disables most of the automatic resource allocation functions of HAL. This prevents HAL from changing resource allocations made by the PnP BIOS. This is a useful tool for correcting system hangs.

  • /redirect. Used for console redirection in headless servers.

  • /safeboot:. Tells the system to boot in Safe mode. Use in conjunction with these modes: minimal, network, dsrepair. For example /safeboot:minimal. These options correspond to the Safe Mode options listed when you press F8.

  • /safeboot:minimal(alternateshell). This additional switch permits you to boot to the shell defined in HKLM | System | CurrentControlSet | Control | Safeboot | AlternateShell. By default, this is the command shell, CMD.EXE. If you want to, you can specify another shell here such as PROGMAN.EXE, the original program manager shell.

  • /scsiordinal:x. Differentiates between identical SCSI controllers. If you add a second controller and boot to a Blue Screen stop, the SCSI driver may be binding to the wrong controller. Set the x value to 1 if the Windows Server 2003 files are on the second controller.

  • /sos. Displays the name of the drivers as they load along with the results of the AUTOCHK scan that is done at each system boot. Think of this switch as "Show Our System."

  • win95dos and /win95. These switches emulate the dual-boot features in Windows 9x. They are used in conjunction with Bootsect.dos files that contain Windows 95 bootstrap.

An additional set of Boot.ini switches are used for headless server operation and kernel-mode debugging. See Chapter 2, "Performing Upgrades and Automated Installations," for headless server operation and Chapter 21, "Recovering from System Failures," for information on kernel-mode debugging.

Special ARC Paths

Ntldr makes INT13 fixed disk function calls to find the boot drive and files at the root of the boot partition. There are a couple of situations where a standard ARC path is insufficient for Ntldr to use INT13 calls.

No Support for INT13 Extensions

In classic NT, the boot partition could not be larger than 7.8GB and the ending cylinder number could not be greater than 1024. This was due to a limitation in the INT13 function call.

The original INT13 specification assumed a certain set of Cylinder/Head/Sector (CHS) limitations. The CHS limitations have been revised as drive technology supported larger and larger capacities. The PC97 specification included a set of INT13 extensions to accommodate larger drive geometries. Windows 2000 and later support these INT13 extensions, so boot partitions can be larger than 7.8GB.

If you have a system that does not support the INT13 extensions and the boot partition is larger than 7.8GB or lies outside the 1024 cylinder limit, Ntldr needs a different way to find the boot drive.


A SCSI controller supports INT13 calls via special interfaces in the controller's BIOS. If the SCSI controller does not have a BIOS, or the BIOS has been disabled, Ntldr needs an alternate means of locating the boot drive. Classic NT solved this problem by loading the SCSI miniport driver packaged in Ntbootdd.sys. Ntldr used the miniport driver to scan the SCSI bus. The ARC path entries scsi()disk() told Ntldr the ordinal number of the SCSI controller and the SCSI ID of the boot disk.

Because Windows Server 2003 uses Plug and Play, it's possible that the ordinal number assigned to the SCSI controller could change. This would keep Ntldr from finding the boot drive using a classic ARC path. For that reason, Ntldr needs a more reliable means for identifying the boot drive than the SCSI ID.

Signature() Entry

Windows Server 2003 (and Windows 2000) deals with the lack of full INT13 support by using a controller type in the ARC path called signature(). Here is an example ARC path using this controller type:

signature(ea1aa9c7)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows Server 2003" /

The number in the parentheses, ea1aa9c7, is a random number written to the MBR of the boot drive during Setup. It is sometimes called a fault tolerant boot signature, a holdover term from classic NT.

When Ntldr sees a signature() entry in an ARC path, it scans the mass storage devices looking for a drive with an MBR that contains the signature. For IDE drives, it uses standard INT13 calls to do this scan. For SCSI drives, it loads the miniport driver in Ntbootdd.sys. The signature uniquely identifies the boot drive regardless of the SCSI ordinal number.

Signature() Limitations

The signature() method of identifying drives in Boot.ini has its drawbacks. If the disk signature is overwritten by a virus or the MBR is corrupted and must be overwritten, Ntldr cannot locate the drive and will give the error Windows Server 2003 could not start because of a computer disk hardware configuration problem.

If you encounter this kind of problem, you can correct it as shown in Procedure 1.4.

Procedure 1.4 Correcting Lost Drive Signatures

  1. Correct the source of the corruption in the MBR. You can use the Recovery Console to write a new MBR. See Chapter 21, "Recovering from System Failures," for details.

  2. Then use a tool like Disk Probe from the Resource Kit to write a new fault tolerant signature to the MBR. Chapter 3, "Adding Hardware," discusses the physical location of the signature. Any 4-byte number will suffice.

  3. Create a fault tolerant boot disk using instructions in Chapter 3, "Adding Hardware." Modify the ARC path in Boot.ini to have a signature() entry that matches your new fault tolerant signature. Then, boot the system using that boot disk.

  4. After the system is up and running, correct the ARC path in the Boot.ini on the boot drive.

     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows