To diagnose and correct a startup problem, you need to understand what occurs during startup. The first step in isolating startup problems is for you to determine whether the problem occurs before, during, or after Microsoft Windows XP Professional starts up.
The root cause of startup failure, including contributing factors, can stem from a variety of problems, such as user error, application faults, hardware failures, or virus activity. If the condition is serious enough, you might need to reinstall Windows XP Professional or restore files from backup media.
In x86-based systems, startup failures that occur before the operating system loader (Ntldr) starts could indicate missing or deleted files, or damage to the hard disk master boot record (MBR), partition table, or boot sector. If a problem occurs during startup, the system might have incompatible software or drivers, incompatible or improperly configured hardware, or corrupted system files.
The startup process for Itanium-based computers is similar to that of x86-based computers. For more information, see Startup Phases for Itanium-based Systems later in this chapter.
The Windows XP Professional startup process closely resembles that of Microsoft Windows NT version 4.0 and Microsoft Windows 2000, but significantly differs from Microsoft MS DOS , Microsoft Windows 95, Microsoft Windows 98, and Microsoft Windows Millennium Edition (Windows Me).
All computers running Windows XP Professional share the same startup sequence:
Power-on self test (POST) phase
Initial startup phase
Boot loader phase
Detect and configure hardware phase
Kernel loading phase
Logon phase
The preceding startup sequence applies to systems started or restarted after a normal shutdown, and does not apply when you bring your computer out of hibernation or standby. See Resolving Power Management Problems on x86-based Systems later in this chapter for more information about problems that might occur when you bring your computer out of standby or hibernation.
For Windows XP Professional to start, the system and boot partitions must contain the files listed in Table 27-1.
File Name | Disk Location | Description |
---|---|---|
Ntldr | Root of the system partition | The operating system loader. |
Boot.ini | Root of the system partition | A file that specifies the paths to Windows XP Professional installations. For multiple-boot systems, Boot.ini contains the operating system choices that display on the startup menu. |
Bootsect.dos (multiple-boot systems only) | Root of the system partition | A hidden system file that Ntldr loads for a Windows XP Professional multiple-boot configuration that includes MS DOS, Windows 95, Windows 98, or Windows Me. Bootsect.dos contains the boot sector for these operating systems. |
Ntdetect.com | Root of the system partition | The file that passes information about the hardware configuration to Ntldr. |
Ntbootdd.sys | Root of the system partition (required for SCSI or Advanced Technology Attachment (ATA) controllers with firmware disabled or that do not support extended INT-13 calls). | The device driver used to access devices attached to a SCSI or ATA hard disk whose adapter is not using BIOS. The contents of this file depend on the startup controller used. |
Ntoskrnl.exe | systemroot\System32 | The core (also called the kernel) of the Windows XP Professional operating system. Code that runs as part of the kernel does so in privileged processor mode and has direct access to system data and hardware. During installation on single processor systems, Windows XP Professional Setup copies Ntoskrnl.exe from the operating system CD. During installation on multi-processor systems, Windows XP Professional Setup copies Ntoskrnlmp.exe and renames it Ntoskrnl.exe. |
Hal.dll | systemroot\System32 | The Hardware abstraction layer (HAL) dynamic-link library file. The HAL abstracts low-level hardware details from the operating system and provides a common programming interface to devices of the same type (such as video adapters). The Microsoft Windows XP Professional operating system CD contains several Hal files. Setup copies to your computer the file that fits your hardware configuration and then renames the file as Hal.dll. |
System registry file | systemroot\System32\Config\System | The registry file that contains the data used to create the registry key HKEY_LOCAL_ MACHINE\SYSTEM. This key contains information that the operating system requires to start devices and system services. |
Device drivers | systemroot\System32\Drivers | Driver files for hardware devices, such as keyboard, mouse, and video. |
Note | Windows NT 4.0, Windows 2000, and Windows XP Professional define the system and boot partitions differently from other operating systems. The system volume contains files that are needed to start Windows XP Professional, such as the Windows loader (Ntldr). The boot volume contains Windows XP Professional operating system files and folders such as systemroot and systemroot\System32. In x86-based computers, the boot volume can be, but does not have to be, the same volume as the system volume. |
In Table 27-1, the term systemroot is one of many environment variables used to associate string values, such as folder or file paths, to variables that Windows XP Professional applications and services use. For example, by using environment variables, scripts can run without modification on computers that have different configurations. To obtain a list of environment variables that you can use for troubleshooting, type set at the command line.
For more information about environment variables, see To add or change the values of environment variables in Windows XP Professional Help and Support Center. For more information about system files, see System Files Reference in this book.
As soon as you turn on a computer, its central processing unit (CPU) begins to carry out the programming instructions contained in the basic input/output system (BIOS). The BIOS, which is a type of firmware, contains the processor dependent code that starts the computer regardless of the operating system installed. The first set of startup instructions is the power-on self test (POST). The POST is responsible for the following system and diagnostic functions:
Performs initial hardware checks, such as determining the amount of memory present.
Verifies that the devices needed to start an operating system, such as a hard disk, are present.
Retrieves system configuration settings from non-volatile complementary metal-oxide semiconductor (CMOS) memory, which is located on the motherboard.
The contents of CMOS memory remain even after you shut down the computer. Examples of hardware settings stored in CMOS memory include boot order and Plug and Play information.
After the motherboard POST completes, add-on adapters that have their own firmware (for example, video and hard drive controllers) carry out internal diagnostic tests.
To access and change system and peripheral firmware settings, consult the system documentation provided by the manufacturer.
After the POST, the settings that are stored in CMOS memory, such as boot order, determine the devices that the computer can use to start an operating system. For example, if the boot order specifies the floppy disk as the first startup device and the hard disk as second (some firmware displays this order as A, C ), the following scenarios might occur at startup:
The BIOS searches the floppy disk drive for a bootable floppy disk. If one is present, the first sector (the floppy disk boot sector) loads into memory. If the floppy disk is not bootable, an error message similar to the following appears:
Non-system disk or disk error
Replace and press any key when ready
The computer displays the preceding message until you insert a bootable floppy disk or until you remove the floppy disk and restart the computer.
If you restart the computer without a floppy disk, the computer reads the boot code instructions located on the master boot record (MBR). The MBR is the first sector of data on the startup hard disk and contains instructions (called boot code) and a table (called a partition table) that identify primary and extended partitions. The BIOS reads the MBR into memory and transfers control to the code in the MBR.
The computer then searches the partition table for the active partition. The first sector of the active partition contains boot code that enables the computer to do the following:
Determine the file system used.
Locate and start the operating system loader file, Ntldr.
If an active partition does not exist or if boot sector information is missing or corrupt, a message similar to any of the following might appear:
Invalid partition table
Error loading operating system
Missing operating system
BOOT: Couldn't find NTLDR
NTLDR is missing
If an active partition is successfully located, the code in the boot sector locates and starts Ntldr and the BIOS releases control to it.
For more information about disks and file systems, including information about the MBR, partitions, and boot sectors, see File Systems and Troubleshooting Disks and File Systems in this book.
In addition to floppy disks or hard disks attached to SCSI and ATA controllers, some computer firmware can start an operating system from other devices, such as:
CD ROMs
Network adapters
Removable disks, such as LS-120 disks or Iomega Zip disks
Secondary storage devices installed in docking stations for portable computers
It is possible to specify a custom boot order, such as CDROM, A, C . When you specify CDROM, A, C as a boot order, the following events occur at startup:
The computer searches the CD ROM for bootable media. If a bootable CD is present, the computer uses the CD ROM as the startup device. Otherwise, the computer searches the next device in the boot order.
The computer searches the floppy disk for bootable media. If a bootable floppy is present, the computer uses the floppy disk as the startup device. Otherwise, the computer searches the next device in the boot order or displays an error message.
The computer uses the hard disk as the startup device. The computer typically uses the hard disk as the startup device only when the CD ROM drive and the floppy disk drive are empty.
There are exceptions where code on bootable media transfers control to the hard disk. For example, when you start your system by using the bootable Windows XP Professional operating system CD, Setup checks the hard disk for Windows XP Professional installations. If one is found, you have the option of bypassing CD ROM startup by not responding to the Press any key to boot from CD prompt that appears.
You cannot use a nonbootable CD to start your system. The presence of a nonbootable CD in the CD ROM drive can add to the time the system requires to start. If you do not intend to start the system from CD, remove all CDs from the CD ROM drive before restarting.
For more information about boot order options, consult your system documentation.
Ntldr loads startup files from the boot partition and then does the following:
An x86-based computer first starts in real mode. In real mode, the processor disables certain features in order to allow compatibility with software designed to run on 8-bit and 16-bit processors. Ntldr then switches the processor to 32-bit mode, which allows access to large amounts of memory and enables Windows XP Professional to start.
Ntldr contains the program code that Windows XP Professional needs to read and write to disks formatted by using the NTFS or file allocation table (FAT16 or FAT32) file systems.
Ntldr parses the Boot.ini file to determine the location of the operating system boot partition. For systems that use a single-boot configuration, Ntldr initiates the hardware detection phase by starting Ntdetect.com. For multiple-boot configurations that include Windows XP Professional, Windows 2000, Windows NT 4.0, Windows 95, Windows 98, Windows Me, or MS DOS, you receive a menu of operating system choices at startup.
Note | Computers running Windows NT 4.0 require Service Pack 4 or later to access NTFS volumes previously mounted by Windows 2000 or Windows XP Professional. For more information about NTFS interoperability, see File Systems in this book. |
If you choose Windows XP Professional, Windows 2000, or Windows NT 4.0, Ntldr proceeds with the hardware detection phase. If you do not select Windows XP Professional, Windows 2000, or Windows NT 4.0, control is passed to the boot sector for the other operating system. For example, if you select Windows 95, Windows 98, Windows Me, or MS DOS, Ntldr passes control to Bootsect.dos by reading MBR code that Bootsect.dos contains. This action causes the MBR code in Bootsect.dos to execute as if the instructions were read from the disk. For more information about Boot.ini, see Reviewing and Correcting Boot.ini Settings on x86-based Systems later in this chapter.
For x86-based systems, Ntldr starts Ntdetect.com, a program that performs basic device detection. Ntldr then passes Boot.ini information, as well as hardware and software data in the registry, to Ntoskrnl.exe. Ntdetect.com detects hardware profile information (for example, docked and undocked configurations for portable computers) and also checks for information stored in Advanced Configuration and Power Interface (ACPI) tables. ACPI compliant firmware enables Windows XP Professional to detect device power management features and determine device resource requirements.
For more information about ACPI, see the ACPI link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources
After processing the Boot.ini file, Ntldr starts Ntdetect.com. For x86-based systems, Ntdetect.com collects information about installed hardware by using calls to system firmware routines. Ntdetect.com then passes this information back to Ntldr. Ntldr gathers the data received from Ntdetect.com and organizes the information into internal data structures. Ntldr then starts Ntoskrnl.exe and provides it with information obtained from Ntdetect.com.
Ntdetect.com collects the following type of hardware and device information:
System firmware information, such as time and date
Bus and adapter types
Video adapters
Keyboard
Communication ports
Disks
Floppy disks
Input devices (such as mouse devices)
Parallel ports
Devices installed on the Industry Standard Architecture (ISA) bus
Ntdetect.com plays a greater role for device enumeration in computers that are not ACPI compliant because in those computers, the firmware, not the operating system, determines the resources assigned to devices. For computers with ACPI firmware, Windows XP Professional assigns the hardware resources to use.
During this phase, Ntdetect.com searches for hardware profile information. Windows XP Professional creates a single default profile for desktop computers and creates two default profiles for portable computers. For portable computers, the operating system selects the appropriate profile based on the hardware state of the computer:
Desktop computer. Profile 1
Portable computer.
Docked Profile
Undocked Profile
Hardware profiles are especially useful for portable computers because the hardware state of these computers is not static. Drivers for devices not listed in a particular hardware profile are not loaded during startup.
For more information about creating and using hardware profiles, see Windows XP Professional Help and Support Center. Also see article Q225810, How to Create Hardware Profiles on Windows 2000 Based Mobile Computers, in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources Also, see Managing Devices and Supporting Mobile Users in this book.
Ntldr is responsible for loading the Windows kernel (Ntoskrnl.exe) and the hardware abstraction layer (HAL) into memory. The Hal.dll file that your computer uses can vary. During installation, Windows XP Professional Setup copies one of several HAL files (see Table 27-2 for a list of these files) and renames the file Hal.dll.
To view the computer description in Device Manager
In the Run dialog box, type devmgmt.msc, and then click OK.
In Device Manager, expand Computer to view the description of your computer.
By comparing the description that Device Manager uses to the descriptions listed in Table 27-2, you can determine the HAL file that is copied to your computer from the Windows XP Professional operating system CD.
Computer Description in Device Manager | HAL File Copied |
---|---|
ACPI Multiprocessor PC | Halmacpi.dll |
ACPI Uniprocessor PC | Halaacpi.dll |
Advanced Configuration and Power Interface (ACPI) PC | Halacpi.dll |
MPS Multiprocessor PC | Halmps.dll |
MPS Uniprocessor PC | Halapic.dll |
Standard PC | Hal.dll |
Compaq SystemPro Multiprocessor or 100% Compatible | Halsp.dll |
Together, the kernel and the HAL initialize a group of software components that are called the Windows executive. The Windows executive processes the configuration information stored in registry control sets, and starts services and drivers.
For more information about Windows executive services, see Common Stop Messages for Troubleshooting in this book.
Ntldr reads control set information from the HKEY_LOCAL_ MACHINE\SYSTEM registry key, which is created from information in the systemroot\System32\Config\System file, so that Ntldr can determine which device drivers need to be loaded during startup. Typically, several control sets exist, with the actual number depending on how often system configuration settings change.
Caution | Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference in the Microsoft Windows 2000 Server Resource Kit at http://www.microsoft.com/windows . |
Typical registry control set subkeys are:
\CurrentControlSet, a pointer to a ControlSetxxx subkey (xxx represents a control set number, such as 001) designated in the \Select\Current entry.
\Clone, a copy of \CurrentControlSet, created each time you start your computer.
\Select, which contains the following entries:
Default, which points to the control set number (for example, 001=ControlSet001) that the system has specified for use at the next startup. If no error or manual invocation of the LastKnownGood startup option occurs, this control set number is designated as the value of the Default, Current, and LastKnownGood entries (assuming that a user is able to log on successfully).
Current, which points to the last control set that was used to start the system.
Failed, which points to a control set that did not start Windows XP Professional successfully. This value is updated when the LastKnownGood option is used to start the system.
LastKnownGood, which points to the control set that was used during the last user session. When a user logs on, the LastKnownGood control set is updated with configuration information from the previous user session.
Ntldr uses the control set identified by the Default value unless you choose the Last Known Good Configuration from the Windows Advanced Options menu.
The kernel uses the internal data structures provided by Ntldr to create the HKEY_LOCAL_MACHINE\HARDWARE key, which contains the hardware data collected at system startup. The data includes information about various hardware components and system resources allocated to each device. You can monitor the kernel load process by viewing the Starting up progress indicator that appears during startup. For more information about Last Known Good Configuration, see Tools for Troubleshooting in this book.
Windows XP Professional supports an extensive set of devices. New or updated drivers that are not on the Windows XP Professional operating system CD are provided by hardware manufacturers. Drivers are kernel-mode components required by devices to function within an operating system. Services are components that support operating system functions and applications. Services can run in a different context than user applications and typically do not offer many user-configurable options. Services, such as the Print Spooler, do not require a user to be logged on to run and act independently of the user who is logged on to the system. Windows XP Professional driver and service files are typically stored in the systemroot\System32 and systemroot\System32\Drivers folders and use .exe, .sys, or .dll file name extensions.
Drivers are also services. Therefore, during kernel initialization, Ntldr and Ntoskrnl.exe use the information stored in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\servicename registry subkeys to determine both the drivers and services to load. For example, Ntldr searches the Services subkey for drivers with a Start value of 0, such as hard disk controllers. After Ntldr starts Ntoskrnl.exe, an Ntoskrnl.exe component searches for and starts drivers, such as network protocols, that have a Start value of 1.
Table 27-3 lists the values (in decimal) for the Start entry. Boot drivers (those with a Start value of 0) and file system drivers are always loaded regardless of their Start value because they are required to start Windows XP Professional.
Value | Start Type | Value Descriptions for Start Entries |
---|---|---|
0 | Boot | Specifies a driver that is loaded (but not started) by firmware calls made by the x86-based Ntldr or Itanium-based IA64ldr boot loader. If no errors occur, the kernel starts the driver. |
1 | System | Specifies a driver that loads at kernel initialization during the startup sequence by calling Windows XP Professional boot drivers. |
2 | Auto load | Specifies a driver or service that is initialized at system startup by Session Manager (Smss.exe) or Service Controller (Services.exe). |
3 | Load on demand | Specifies a driver or service that is manually started by a user, a process, or another service. |
4 | Disabled | Specifies a disabled (not started) driver or service. |
Table 27-4 lists some of the values (in decimal) for the Type entry.
Value | Value Descriptions for Type Entries |
---|---|
1 | Specifies a kernel device driver. |
2 | Specifies a file system driver (also a kernel device driver). |
4 | Specifies parameters passed to the device driver. |
16 | Specifies a service that obeys the service control protocol, can run in a process by itself, and can be started by the Services Controller. |
32 | Specifies a service that can share a process with other services. |
Some drivers and services require that certain dependencies be met before they start. You can find dependencies listed under the DependOnGroup and DependOnService entries in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\servicename subkey for each service or driver. For more information about using dependencies to prevent or delay a driver or service from starting, see Temporarily Disabling Services later in this chapter. The Services subkey also contains information that affects how drivers and services are loaded, a few of which are listed in Table 27-5.
Entry | Description |
---|---|
DependOnGroup | At least one item from this group must start before this service is loaded. The subkey SYSTEM\CurrentControlSet\Control\ServiceGroupOrder contains the service group load order. |
DependOnService | Lists the specific services that must load before this service loads. |
Description | Describes the component. |
DisplayName | Specifies the display name of the component. |
ErrorControl | Controls whether a driver error requires the system to use the LastKnownGood control set or to display a Stop message.
|
Group | Designates the group that the driver or service belongs to. This allows related drivers or services to start together (for example, file system drivers). The registry entry List in the subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder specifies the group startup order. |
ImagePath | Identifies the path and file name of the driver or service if the ImagePath entry is present. You can use Windows Explorer to verify the path and file name. |
ObjectName | Specifies an object name. If the Type entry specifies a Windows XP Professional service, it represents the account name that the service uses to log on when it runs. |
Tag | Designates the order in which a driver starts within a driver group. |
After all entries that have Boot and Startup data types are processed, the kernel starts Session Manager. Session Manager (Smss.exe) performs important initialization functions, such as:
Creating system environment variables.
Starting the kernel-mode portion of the Windows subsystem (implemented by systemroot\System32\Win32k.sys), which causes Windows XP Professional to switch from text mode to graphics mode. Windows-based applications run in the Windows subsystem. This environment allows applications to access operating system functions, such as displaying information to the screen.
Starting the user-mode portion of the Windows subsystem (implemented by systemroot\System32\Csrss.exe).
Starting the Logon Manager (systemroot\System32\Winlogon.exe).
Creating additional virtual memory paging files.
Performing delayed rename operations for files listed in the registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations. For example, you might be prompted to restart the computer after installing a new driver or application so that Windows XP Professional can replace the file in use.
The Windows subsystem and the applications that run within it are user mode processes; they do not have direct access to hardware or device drivers. User-mode processes run at a lower priority than kernel-mode processes. When the operating system needs more memory, it can page to disk the memory that is used by user-mode processes. For more information about user-mode and kernel-mode components, see Common Stop Messages for Troubleshooting in this book.
Session Manager searches the registry for service information that is contained in the following subkeys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager contains a list of commands to run before loading services. The Autochk.exe tool is specified by the value of the BootExecute entry and virtual memory (paging file) settings stored in the Memory Management subkey. Autochk, which is a version of the Chkdsk tool, runs at startup if the operating system detects a file system problem that requires repair before completing the startup process. For more information about Autochk and Chkdsk, see Troubleshooting Disks and File Systems in this book.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Subsystems contains a list of available subsystems. For example, Csrss.exe contains the user-mode portion of the Windows subsystem.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\servicename. The Service Control Manager initializes services that the Start entry designates as Auto-load.
The Windows subsystem starts Winlogon.exe, a system service that enables logging on and off. Winlogon.exe then does the following:
Starts the Services subsystem (Services.exe), also known as the Service Control Manager (SCM).
Starts the Local Security Authority (LSA) process (Lsass.exe).
Parses the CTRL+ALT+DEL key combination at the Begin Logon prompt.
The Graphical Identification and Authentication (GINA) component collects the user name and password, and passes this information securely to the LSA for authentication. If the user supplied valid credentials, access is granted by using either the Kerberos V 5 authentication protocol or NTLM. For more information about security components, such as LSA, Kerberos V5 protocol, or NTLM, see the Distributed Systems Guide of the Microsoft Windows 2000 Server Resource Kit.
Winlogon initializes security and authentication components while the Service Control Manager initializes Auto-load services and drivers. After the user logs on, the following events occur:
Control sets are updated. The control set referenced by the LastKnownGood registry entry is updated with the contents in the Clone entry. Clone, which is a copy of the CurrentControlSet entry, is created each time you start your computer. When a user logs on, the LastKnownGood control set is updated with configuration information from the previous user session.
Group Policy settings take effect. Group Policy settings that apply to the user and computer take effect. For more information about Group Policy, see Planning Deployments, Managing Desktops, and Authorization and Access Control in this book, and see Group Policy in the Distributed Systems Guide of the Microsoft Windows 2000 Server Resource Kit. Also, see the Change and Configuration Management Deployment Guide link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources
Startup programs run. Windows XP Professional starts logon scripts, startup programs, and services referenced in these registry subkeys and folder locations:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Runonce
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer\Run
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\ Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
systemdrive\Documents and Settings\All Users\Start Menu\Programs\ Startup
systemdrive\Documents and Settings\username\Start Menu\Programs\ Startup
windir\Profiles\All Users\Start Menu\Programs\Startup
windir\Profiles\username\Start Menu\Programs\Startup
The windir\Profiles folders exist only on systems that are upgraded from Windows NT 4.0.
Windows XP Professional startup is not complete until a user successfully logs on to the computer.
Plug and Play detection runs asynchronously with the logon process and relies on system firmware, hardware, device driver, and operating system features to detect and enumerate new devices. Windows XP Professional optimizes Plug and Play support for computers equipped with ACPI firmware and enables enhanced features, such as hardware resource sharing.
When Plug and Play components are well coordinated, Windows XP Professional can detect new devices, allocate system resources, and install or request drivers with minimal user intervention. ACPI features are especially useful for mobile users who use portable computers that support standby, hibernation, hot and warm docking, or undocking features.
For more information about Plug and Play device detection and system resources, see Managing Devices and Supporting Mobile Users in this book.
Windows XP Professional also runs on Itanium-based systems. The startup process for Itanium-based computers is similar to that of x86-based systems. Itanium-based systems proceed through the following startup stages:
Power-on self test (POST) phase
Initial startup and boot manager phase
Kernel loading phase
Device driver and service initialization phase
Logon phase
Plug and Play device detection phase
The POST process for Itanium-based systems is similar to x86-based systems. The Extensible Firmware Interface (EFI) performs rudimentary hardware checks, similar to those performed by BIOS, and verifies that devices needed to start the system are present.
Note | The EFI specification, currently implemented for Itanium-based systems only, defines a new model for the interface between operating systems and platform firmware. For more information about EFI, see the Extensible Firmware Interface link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources |
After the POST finishes and before Windows XP Professional loads, the boot manager (a part of the EFI) determines the EFI drivers to use, the EFI tool set that is available to the user, and the EFI startup options to display.
The specific set of boot manager features that are available on your computer can vary from one Itanium-based system to another. Check your system documentation for information about additional tools, which might include Nvrboot.efi, Format.efi, Fdisk.efi, Diskpart.efi, and an EFI shell. These tools are either included with the EFI image or can be run from a floppy disk or other removable disks.
You might be able to use these additional tools to perform system tasks, such as restoring the boot manager startup menu, mapping disks, performing file maintenance, updating system firmware, and doing recovery operations.
To start Windows XP Professional, the boot manager performs the following tasks:
Reads EFI configuration settings, such as the boot order sequence, from non-volatile memory (NVRAM). As with the CMOS settings for x86-based systems, the contents of NVRAM are preserved even when you turn off the computer. For more information about boot order options in firmware, see Startup Phases for x86-based Systems and Initial Startup Phase earlier in this chapter.
Initializes essential devices needed to start Windows XP Professional. Configuration information for storage and possibly other devices are also kept in non-volatile memory. Before Windows XP Professional starts, only basic functionality (the minimum required to start an operating system) is available for these devices. Devices detected at this stage include the following if they are present:
Network adapters
Video adapters
Keyboard
Drive controllers (SCSI or ATA)
Storage devices
Determines which device holds the EFI System partition image. The EFI System partition can range in size from a minimum of 100 megabytes (MB) up to one percent of the available hard disk space or a maximum of 1000 MB. The EFI System partition contains the files required to start Windows XP Professional. The remaining system files in the systemroot folder must reside on another partition.
For more information about Windows XP Professional disk partitions, including a discussion about the structure of the new Itanium globally unique identifier (GUID) partition table, see Windows XP Professional Help and Support Center. Also, see in File Systems, Disk Management, and Troubleshooting Disks and File Systems this book.
Locates the operating system partition and locates directories containing Windows XP Professional files.
Locates and starts the loader file called IA64ldr.efi. IA64ldr.efi starts the 64-bit Windows kernel.
Table 27-6 lists the names and locations of the startup files for Itanium-based systems. The EFI System partition is the first partition of the startup drive.
File and Folder Names | Disk Location | Description |
---|---|---|
BootNNNN | EFI\Microsoft\WINNT 50.x folder on the EFI System partition | A file that contains a saved copy of the EFI boot manager NVRAM settings. A WINNT50.x folder exists for each Windows XP Professional installation on your system. The value of x indicates the order in which you installed the instance of Windows XP Professional. A corresponding BootNNNN file exists for each Windows XP Professional installation. Setup generates a BootNNNN file during installation. The value of NNNN corresponds to the installation s NVRAM boot ID entry. For more information about BootNNNN files, see Reviewing and Correcting NVRAM Startup Settings on Itanium-based Systems later in this chapter. |
FPSWA.efi | EFI\Microsoft\WINNT 50.x folder on the EFI System partition | A file that supports EFI floating point operations. |
MSUtil (folder) | Resides on the root of the EFI System partition | A folder that contains EFI tools. |
Nvrboot.efi | MSUtil folder on the EFI System partition | A tool that enables you to restore boot manager startup options saved to BootNNNN files. It also allows you to back up NVRAM boot entries and edit startup parameters. Whenever possible, use Bootcfg.exe to make changes. For more information about Bootcfg.exe, see Windows XP Professional Help and Support Center. For more information about Nvrboot.efi, see Reviewing and Correcting NVRAM Startup Settings on Itanium-based Systems later in this chapter. |
IA64ldr.efi | EFI\Microsoft\WINNT 50.x folder on the EFI System partition | The operating system loader. |
Ntoskrnl.exe | systemroot\System32 | The core (also called the kernel) of the Windows XP Professional operating system. Operating system code that runs as part of the kernel does so in a special privileged processor mode, with direct access to system data and hardware. During installation, Windows XP Professional Setup copies Ntoskrnl.exe from the operating system CD for single processor systems, or for multi-processor systems, copies Ntoskrnlmp.exe and renames it to Ntoskrnl.exe. |
Hal.dll | systemroot\System32 | The hardware abstraction layer (HAL) dynamic-link library file. The HAL abstracts low-level hardware details from the operating system and provides a common programming interface to devices of the same type (such as video adapters). |
System registry file | systemroot\System32\Config\System file | The registry file that contains the data used to create the registry key HKEY_LOCAL_MACHINE\SYSTEM. This key contains information that the operating system requires to start devices and system services. |
Device drivers | systemroot\System32\Drivers folder | Driver files for hardware devices. |
Due to the differences between Itanium-based and x86-based systems, certain files required for the x86-based startup process are not required for Itanium-based computers. Table 27-7 lists x86-based files not required by Itanium-based systems.
File not used | Description |
---|---|
Boot.ini | The Boot.ini file is not required for Itanium-based systems because information previously contained in the file, such as startup options and descriptive menu text, is stored in NVRAM. |
Ntdetect.com | Windows XP Professional detects hardware according to the ACPI specification rather than by using Ntdetect.com. |
Ntldr | The x86-based loader. The loader for Itanium-based versions is IA64ldr.efi. |
For more information about system files, see System Files Reference in this book.
IA64ldr.efi performs a function similar to that of Ntldr for x86-based systems. IA64ldr.efi is responsible for loading the kernel (Ntoskrnl.exe) and the hardware abstraction layer (Hal.dll) into memory.
IA64ldr.efi loads control set information and uses it to initialize hardware and software components. For more information about the kernel loading phase, see Startup Phases for x86-Based Systems and Kernel Loading Phase earlier in this chapter.
The processes that occur for Itanium-based systems during this phase closely resemble the processes for x86-based computers. For more information about the device drivers and services phase, see Startup Phases for x86-based Systems and Kernel Loading Phase earlier in this chapter.
During this phase, the processes that occur for Itanium-based systems closely resemble the processes for x86-based computers. For more information about the operating system logon phase, see Startup Phases for x86-based Systems and Logon Phase earlier in this chapter.
The processes that occur for Itanium-based systems during this phase closely resemble the processes for x86-based computers. For more information, see Startup Phases for x86-based Systems and Plug and Play Device Detection earlier in this chapter.
Table 27-8 lists the startup phases and provides a descriptive summary of each one.
Startup Stage | x86-based Systems | Itanium-based Systems |
---|---|---|
Power-on self test (POST) | CPU initiates motherboard POST routines. Individual adapter POST routines start after the motherboard POST is complete. | CPU initiates motherboard POST routines. Individual adapter POST routines start after the motherboard POST is complete. |
Initial startup (before the-operating system loads) | The system searches for a boot device according to the boot order setting stored in CMOS. If the boot device is a hard disk, Ntldr starts. | The EFI starts and the boot manager searches for a boot device according to the boot order settings stored in NVRAM. |
Ntldr starts | Ntldr switches the CPU to protected mode, starts the file system, and then reads the contents of the Boot.ini file. This information determines the startup options and initial boot menu selections. | Global system variables and settings are read from NVRAM and boot manager information is used to determine the startup options. |
Hardware detection occurs | Ntdetect.com gathers basic hardware configuration data and passes this information to Ntldr. If more than one hardware profile exists, Windows XP Professional attempts to use the one that is correct for the current configuration. If the firmware complies with ACPI specifications, Windows XP Professional uses ACPI functionality to enumerate and initialize devices. | The boot manager searches for and starts IA64ldr.efi. The operating system starts devices by using ACPI functionality. |
Kernel loads | Ntldr passes the information collected by Ntdetect.com to Ntoskrnl.exe. Ntoskrnl then loads the kernel, HAL, and registry information. A progress indicator appears near the bottom of the screen. | IA64ldr.efi loads the kernel, the HAL, and registry information. A progress indicator appears near the bottom of the screen. |
Drivers load and the user logs on | Networking-related components, such as TCP/IP, load asynchronously with other services and the Begin Logon prompt appears on screen. After a user logs on successfully, Windows XP Professional updates the Last Known Good Configuration information to reflect the current state. | |
Plug and Play detects and configures new devices | If Windows XP Professional detects new devices, they are assigned system resources. Windows XP Professional extracts the needed driver files from the Driver.cab file or if the driver files are not found, prompts the user to provide them. Device detection occurs asynchronously with the operating system logon process. |
Table 27-9 lists the files that are processed by x86-based and Itanium-based systems during the startup process. This information is useful if your organization uses Windows XP Professional on x86-based and Itanium-based computers. For example, when diagnosing a problem on an Itanium-based system, you can immediately eliminate Boot.ini and Ntdetect.com from your list of potential causes.
File Name | x86-based Systems | Itanium-based Systems |
---|---|---|
Boot.ini | X | |
Bootsect.dos (multiple-boot systems only) | X | |
FPSWA.efi | X | |
Hal.dll | X | X |
IA64ldr.efi | X | |
Ntbootdd.sys | X | |
Ntdetect.com | X | |
Ntldr | X | |
Ntoskrnl.exe | X | X |
Files in the systemroot\System32\Config folder | X | X |
Files in thesystemroot\System32\Drivers folder | X | X |