Windows NT Startup Process

The booting process of Windows NT includes Windows NT 4.0, Windows 2000, Windows XP and Windows Server 2003. In Windows Vista and later, this process has changed significantly; see Windows NT 6 startup process for information about what has changed.

Installer

The Windows NT installer works very similarly to a regular Windows NT boot except that it runs from a CD-ROM. For this boot method to work, the BIOS must be compatible with the El Torito file system on the install CD is not fully compatible with the standard. Although it is "Level 1", the file names don't have the file version appended to it. The boot image is of the "no emulation" type, 1 sector long (2048 bytes) and is loaded at segment 0x7c0. It can be extracted from an ISO image by using a file-extraction program such as 7-Zip or WinZip. The ISO image is also not hybridized like ISO images from most Linux distributions and therefore it does not contain any master boot record (MBR) which makes it unable to boot by just copying the image over a block device such as a pen drive.

The installer can also be run from a MS-DOS command prompt so previous versions of Microsoft Windows that are already installed can be upgraded. To run the installer from a MS-DOS based operating system such as Windows 98 or Windows ME, the user must start the system "in DOS mode" and then execute I386/WINNT.EXE on the CD-ROM.

A floppy disk containing MS-DOS can be used to start the installer. Versions of the installer in floppies were also available for sale. From Windows Vista onwards, the installer runs from BOOT.WIM which contains a bootable version of Windows PE. Windows PE 2.0 is based on the Windows Vista kernel, later Windows PE versions are based on later Windows versions.

CD-ROM boot image phase

On a regular CD-ROM install, the BIOS executes the POST and then searches for a boot descriptor on the CD-ROM. The boot descriptor points to a boot catalog file on the ISO 9660 file system. The BIOS searches for a boot image compatible with the current architecture, loads it into memory and then runs it. The boot image is analogous to the boot sector on a hard drive. The boot image loads SETUPLDR.BIN which is analogous to NTLDR. If this fails for any reason, a message is displayed saying that NTLDR was not found, which may of itself be misleading; moreover, the NTLDR on the CD is never used during the loading phase of the installer. The process also assumes that file versions are unavailable.

Before starting the boot loader, the boot image checks whether there is a Windows install (system) already present and, if so, it starts BOOTFIX.BIN. If no install is found, or if the disk does not have an MBR, then it starts the boot loader directly, thus obviating the need for BOOTFIX.BIN. If BOOTFIX.BIN is started, it displays the string "Press any key to boot from CD." and waits for user input. If none is detected for some seconds, then it boots the next device, and so on. This behavior is essential for booting the second stage of the installer, which starts from the hard disk.

Boot loader phase

Both SETUPLDR.BIN and NTLDR are composed of two binary files concatenated.
They also can be found on the installation CD as compressed CAB files.
The first file is STPBOOT.BIN, which is a flat binary file that just loads the second file. The second file is a regular EXE file in the Portable Executable format.
In SETUPLDR.BIN the second file is SETUPLDR.EXE and in NTLDR the second file is OSLOADER.EXE. Both SETUPLDR.EXE and OSLOADER.EXE have embedded file system drivers for basic access on FAT, NTFS and ISO 9660. Differently from regular *.SYS drivers, the boot loader uses BIOS interrupts to access the boot disk. It also contains a built-in INI parser and CAB decompressor.

After the installer starts running, it prints the string "Setup is inspecting your computer's hardware configuration...". NTDETECT.COM is called and the system information is stored in memory. It then displays a blue screen in VGA text mode with the title "Windows Setup", or "Windows *version name here* Setup", with a white line on the bottom that serves as a status bar.NTDETECT.COMthen looks for TXTSETUP.SIF and parses it. This file works as a key-value database just like the registry or an *.INI or *.INF file. The keys may either contain a list of files associated with their install location or a script line. Therefore, the database stores data and code. During the parsing, the blank lines are ignored and sections with the same name are merged.

The file BIOSINFO.INF is also loaded to resolve hardware quirks.

The key-value syntax in the SourceDisksFiles section is as follows:
filename_on_source = disk_id,subdir,upgrade_code,new_install_code,spare,spare,new_filename

The installer asks if any additional drivers need to be loaded and loads text mode drivers.
* "Press F6 if you need to install a third party SCSI or RAID driver..."
* "Press F2 to run Automated System Recovery (ASR)..."

If so, they can be loaded from a floppy disk only. There is a hidden feature that shows a screen prompting the user to select a computer type if F5 is pressed during the first message.

Text mode drivers are a different from PnP drivers as they are loaded regardless if the hardware is present or not. The loading phase of the installer displays some messages on the screen about the current file being loaded. The message is "Setup is loading files ( he file description...". The files loaded in this phase are those located in sections ending in .Load. In those sections, the key gives a driver name and the value gives a file. The driver name is then looked up in the same section without the .Load suffix to find the driver's user-friendly name. The kernel also needs a registry hive mounted to load the registry from, so SETUPREG.HIV is also loaded. All the file names of the files loaded by the boot loader are hard-coded except for the drivers.

As for PnP devices, after being identified by a bus driver, the address in checked in the section HardwareIdsDatabase and a corresponding driver name is given. But those are not used in this step.

Kernel phase

After all boot files are loaded by the boot loader, the message "Setup is starting Windows" is displayed and the kernel starts. Just like a normal install, it starts the drivers and loads the only service which is setupdd.sys. It runs in kernel mode and starts a GUI still in text mode. From now on, all the drivers are NT based and BIOS interrupts are not used anymore.

The user is asked to choose a file system layout. The selected partition is formatted if necessary and the files from TXTSETUP.SIF are copied to the system. Then it creates the registry hives and automatically restarts the system so the NT system can start and bootstrap itself. The section HiveInfs points to the files used to fill the hives with the default values. On a fresh install this section is named HiveInfs.Fresh. The files are not reg files but are also ini files that can be understood by the ini interpreter bundled with the installer. The disk formatter program is statically linked with setupdd.sys.

Remastering

There are many freeware tools available on the internet that customize TXTSETUP.SIF for the creation of unattended installs or to integrate drivers and hotfixes. This process is sometimes referred as slipstreaming.

The following command shows how a remastered CD can be created with a minimum set of options on Linux. It assumes that the current directory is the CD mount point. The image will be created at the home directory.

mkisofs -b Bootable_NoEmulation.img -no-emul-boot -N . > ~/ntsetup.iso

The file winnt.sif can be used to make the install unattended but it is not required to be present. There is a model file on the CD named UNATTEND.TXT. Setup tries to detect winnt.sif in the I386 directory or on the root directory of a floppy disk.

Boot loader phase

The Windows NT startup process starts when the computer finds a ''Windows boot loader'', a portion of the Windows operating system responsible for finding Microsoft Windows and starting it up. Prior to Windows Vista, the boot loader was NTLDR. Microsoft has also released operating systems for Intel Itanium processors which use IA-64 architecture. The boot loader of these editions of Windows is IA64ldr.efi (later referred as simply IA64ldr). It is an Extensible Firmware Interface (EFI) program.

Operating system selection

The boot loader, once executed, searches for Windows operating systems. Windows Boot Manager does so by reading Boot Configuration Data (BCD), a complex firmware-independent database for boot-time configuration data. Its predecessor, NTLDR, does so by reading the simpler boot.ini. If the boot.ini file is missing, the boot loader will attempt to locate information from the standard installation directory. For Windows NT and 2000 machines, it will attempt to boot from C:\WINNT. For Windows XP and 2003 machines, it will boot from C:\WINDOWS.

Both databases may contain a list of installed Microsoft operating systems that may be loaded from the local hard disk drive or a remote computer on the local network. NTLDR supports operating systems installed on disks whose file system is NTFS or FAT file systems, CDFS (ISO 9660) or UDFS. Windows Boot Manager also supports operating systems installed inside a VHD file, stored on an NTFS disk drive.

In Windows 2000 or in later versions of Windows in which hibernation is supported, the Windows boot loader starts the search for operating systems by searching for ''hiberfil.sys''. NTLDR looks into the root folder of the default volume specified in boot.ini. Windows Boot Manager looks up the location of hiberfil.sys in BCD. If this file is found and an active memory set is found in it, the boot loader loads the contents of the file (which is a compressed version of a physical memory dump of the machine) into memory and restores the computer to the state that it was in prior to hibernation.

Next, the boot loader looks for a list of installed operating system entries. If more than one operating system is installed, the boot loader shows a boot menu and allow the user to select an operating system. If a non NT-based operating system such as Windows 98 is selected (specified by an MS-DOS style of path, e.g. C:\), then the boot loader loads the associated "boot sector" file listed in ''boot.ini'' or BCD (by default, this is ''bootsect.dos'' if no file name is specified) and passes execution control to it. Otherwise, the boot process continues.

Loading the Windows NT kernel

The operating system starts when certain basic drivers flagged as "Boot" are loaded into memory.
The appropriate file system driver for the partition type (NTFS, FAT, or FAT32) which the Windows installation resides in is amongst them. At this point in the boot process, the boot loader clears the screen and displays a textual progress bar (which is often not seen due to the initialization speed); Windows 2000 also displays the text "Starting Windows..." underneath. If the user presses F8 during this phase, the advanced boot menu is displayed, containing various special boot modes including Safe mode, with the Last Known Good Configuration, with debugging enabled, and (in the case of Server editions) Directory Services Restore Mode. Once a boot mode has been selected (or if F8 was never pressed) booting continues.

The following files are loaded sequentially.
# ntoskrnl.exe (the kernel)
# hal.dll (type of hardware abstraction layer)
# kdcom.dll (Kernel Debugger HW Extension DLL)
# bootvid.dll (for the Windows logo and side-scrolling bar)
# config\system (one of the registry hives)

Next, NTDETECT.COM and the Windows NT kernel (''Ntoskrnl.exe'') and the Hardware Abstraction Layer (''hal.dll'') are loaded into memory. If multiple hardware configurations are defined in the Windows Registry, the user is prompted at this point to choose one.

With the kernel in memory, boot-time device drivers are loaded (but not yet initialized). The required information (along with information on all detected hardware and Windows Services) is stored in the HKEY_LOCAL_MACHINE\System portion of the registry, in a set of registry keys collectively called a ''Control Set''. Multiple control sets (typically two) are kept, in the event that the settings contained in the currently-used one prohibit the system from booting. HKEY_LOCAL_MACHINE\System contains control sets labeled ControlSet001, ControlSet002, etc., as well as CurrentControlSet. During regular operation, Windows uses CurrentControlSet to read and write information. CurrentControlSet is a reference to one of the control sets stored in the registry. Windows picks the "real" control set being used based on the values set in the HKLM\SYSTEM\Select registry key:
* Default will be the boot loader's choice if nothing else overrides this
* If the value of the Failed key matches Default, then the boot loader displays an error message, indicating that the last boot failed, and gives the user the option to try booting anyway, or to use the "Last Known Good Configuration".
* If the user choose (or has chosen) Last Known Good Configuration, the control set indicated by the LastKnownGood key is used instead of Default.

When a control set is chosen, the Current key gets set accordingly. The Failed key is also set to the same as Current until the end of the boot process. LastKnownGood is also set to Current if the boot process completes successfully.

Which services are started and the order which each group is started in are provided by the following keys:
* HKLM\SYSTEM\CurrentControlSet\Services
* HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder

For the purposes of booting, a driver may be one of the following:
#A "Boot" driver that is loaded by the boot loader prior to starting the kernel. "Boot" drivers are almost exclusively drivers for hard-disk controllers and file systems ( ATA, SCSI, file system filter manager, etc.); in other words, they are the absolute minimum that the kernel will need to get started with loading other drivers, and the rest of the operating system.
#A "System" driver which is loaded and started by the kernel after the boot drivers. "System" drivers cover a wider range of core functionality, including the display driver, CD-ROM support, and the TCP/IP stack.
#An "Automatic" driver which is loaded much later when the GUI already has been started.

With this finished, control is then passed from the boot loader to the kernel.

Kernel phase

The initialization of the kernel subsystem and the Windows Executive subsystems is done in two phases.

During the first phase, basic internal memory structures are created, and each CPU's interrupt controller is initialized. The memory manager is initialized, creating areas for the file system cache, paged and non-paged pools of memory. The Object Manager, initial security token for assignment to the first process on the system, and the Process Manager itself. The System idle process as well as the System process are created at this point.

The second phase involves initializing the device drivers which were identified by NTLDR as being system drivers.

Through the process of loading device drivers, a "progress bar" is visible at the bottom of the display on Windows 2000 systems; in Windows XP and Windows Server 2003, this was replaced by an animated bar which does not represent actual progress. Prior to Windows XP, this part of the boot process took significantly longer; this is because the drivers would be initialized one at a time. On Windows XP and Server 2003, the drivers are all initialized asynchronously.

Session Manager

Once all the Boot and System drivers have been loaded, the kernel (system thread) starts the Session Manager Subsystem (smss.exe).

Before any files are opened, Autochk is started by ''smss.exe''. Autochk mounts all drives and checks them one at a time to see whether or not they were cleanly unmounted. If autochk determines one or more volumes are dirty, it will automatically run chkdsk and provides the user with a short window to abort the repair process by pressing a key within 10 seconds (introduced in Windows NT 4.0 Service Pack 4; earlier versions would not allow the user to abort chkdsk). Since Windows 2000, XP and 2003 show no text screen at that point (unlike NT 3.1 to 4.0, which displayed a blue text screen), the user will see a different background picture holding a mini-text-screen in the center of the screen and show the progress of chkdsk there.

At boot time, the Session Manager Subsystem:
* Creates environment variables (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment)
* Starts the kernel-mode side of the Win32 subsystem (win32k.sys). This allows Windows to switch into graphical mode as there is now enough infrastructure in place.
* Starts the user-mode side of the Win32 subsystem, the Client/Server Runtime Server Subsystem (csrss.exe). This makes Win32 available to user-mode applications.
* Creates virtual memory paging files (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management)
* Performs any rename operations (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations) that are queued up. This allows previously in-use files (e.g. drivers) to be replaced as part of a reboot.
* Executes any programs listed in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute such as autocheck and convert.
* Starts the Windows Logon Manager (winlogon.exe). Winlogon is responsible for handling interactive logons to a Windows system (local or remote). The Graphical Identification aNd Authentication (GINA) library is loaded inside the Winlogon process, and provides support for logging in as a local or Windows domain user.

The Session Manager stores its configuration at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager. The exact operation of most of these items is based on the configuration set in the registry.

Authentication

Winlogon starts the Local Security Authority Subsystem Service (LSASS) and Service Control Manager (SCM), which in turn will start all the Windows services that are set to ''Auto-Start''. It is also responsible for responding to the secure attention sequence (SAS), loading the user profile on logon, and optionally locking the computer when a screensaver is running.

The login process is as follows:
*The Session Manager Subsystem starts Winlogon.
*Winlogon starts the Service Control Manager (services.exe).
**Starts the ''auto-start'' services.
**Updates the Control Sets; the LastKnownGood control set is updated to reflect the current control set.
*(Windows XP) Winlogon starts UIHost (logonui.exe), a full-screen graphical UI.
*Winlogon loads GinaDll (msgina.dll)
**(Optional) Login prompt is displayed by GINA, and the user presses the Secure Attention Sequence (SAS) (Control-Alt-Delete). Winlogon checks if the system is configured to log into a specific account automatically (AutoAdminLogon).
**Login dialog is displayed by GINA
**User enters credentials (username, password, and domain)
**GINA passes credentials back to Winlogon
*Winlogon passes credentials to LSASS
*LSASS tries to use cached data in the LSA database (SYSTEM hive)
*If there is none, LSASS determines which account protocol is to be used by using the Security Packages listed in the key HKLM/SYSTEM/CurrentControlSet/Control/Lsa:
**msv1_0.dll implements the NT LAN Manager protocols. This package is used in stand-alone systems and domain-member systems for backward compatibility.
**Kerberos.dll provides remote login by using Active Directory.
*LSASS enforces the local security policy (checking user permissions, creating audit trails, doling out security tokens, etc.).
*Control is passed back to Winlogon to prepare for passing the control to the user.
**Create Windows Stations (WinSta0)
**Create the desktops (Winlogon, Default and ScreenSaver)
**It then starts the program specified in the Userinit value which defaults to userinit.exe. This value supports multiple executables.

If the user is trying to log into the local host then the HKLM/SAM key will be used as database. If the user is trying to log into another host then the NetLogon service is used to carry the data.
msv1_0.dll<->netlogon<->remote netlogon<->remote msv1_0.dll<->remote SAM
On Windows XP, GINA is only shown if the user presses the secure attention sequence.

Winlogon has support for plugins that get loaded and notified about specific events and LSASS also supports plugins (security packages). Some rootkits bundle Winlogon plugins because they are loaded before any user logs in. Some keys allow multiple comma-separated values to be supplied that allow a malicious program to be executed at the same time as a legitimate system file. The hashing algorithms used to store credentials in the SAM database are weak and can be brute-forced quickly on consumer hardware.

Winlogon's responsibilities and the login process have changed significantly from the above in Windows Vista.

Shell

Userinit is the first program that runs with the user credentials. It is responsible to start all the other programs that compose the user shell environment.

The shell program (typically Explorer.exe) is started from the registry entry Shell= pointed to by the same registry entry in key
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\system.ini\Boot; its default value is SYS:Microsoft\Windows NT\CurrentVersion\Winlogon, which evaluates to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.

*Userinit loads the user profile. There are a few types of user profiles and it can be local or remote. This process can be very slow if the user profile is of the "roaming" type.
*User and Computer Group Policy settings are applied.
**Run user scripts
**Run machine scripts
**Run proquota.exe
*Runs the startup programs ''before'' the shell gets started.
*Starts the shell configured in registry, which defaults to explorer.exe.
*Userinit exits and the shell program continues running without a parent process.

Userinit runs startup programs from the following locations:
*HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
*HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
*HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
*HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Load
*HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
*HKCU\Software\Microsoft\Windows\CurrentVersion\Run
*HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
*%ALLUSERSPROFILE%\Start Menu\Programs\Startup\ (this path is localized on non-English versions of Windows before Vista)
*%USERPROFILE%\Start Menu\Programs\Startup\ (this path is localized on non-English versions of Windows before Vista)

Remote booting and installation

To successfully boot, the client must support PXE booting and the Windows Deployment Services (WDS) component must be installed on the server. It is not installed by default. WDS is the successor of Remote Installation Services (RIS).

The PXE program is found on the BIOS or on a ROM chip on the network card.

PXE booting is not a technology specific to Windows and can also be used to start a Linux system. In fact, a Linux system can act as a server to service DHCP or TFTP.

PXE can be used to start Windows Setup to install the system on the client computer or to run the operating system from RAM. The latter, called Remote Boot, was introduced by Windows XP Embedded SP1 and is only available for this flavor of Windows.

The general process for both methods is as follows:
*PXE boot
**DHCP request broadcast
**(Optional) DHCP router redirects to the server
**The server sends the Network Bootstrap Program (NBP) (PXEboot.com) through TFTP
*The NBP program downloads the required files through the BINL protocol

The Boot Information Negotiation Layer (BINL) is a Windows 2000 service running on the server that communicates with the client after the NBP was already loaded by the PXE.

See also

* Architecture of Windows NT
* Windows Startup Process
* Linux startup process
* Booting
* Master boot record
* Power-on self-test
* BootVis

References

Further reading

#
#
#
#
#

External links

Startup Applications List

{{DEFAULTSORT:Windows Nt Startup Process
Windows NT architecture
Booting