Windows NT Startup Process

Article on other languages:

del.icio.us del.icio.us
Digg Digg
Furl Furl
Reddit Reddit
Rojo Rojo
Add to OnlyWire

The Windows NT startup process is the process by which Microsoft's Windows NT, Windows 2000, Windows XP and Windows Server 2003 operating systems initialize.

In Windows Vista, this process has changed slightly (see Windows Vista startup process).

Contents

Boot Loader Phase

For more details on this topic, see NTLDR.

The boot loader phase varies by platform. Since the earlier phases are not specific to the OS, the boot process is considered to start:

From that point, the boot process continues as follows:

An NTLDR file, located in the root folder of the boot disk, is composed of two parts. The first is the StartUp module and immediately followed by the OS loader (osloader.exe), both stored within that file. When NTLDR is loaded into memory and control is first passed to StartUp module, the CPU is operating in real mode. StartUp module's main task is to switch the processor into protected mode, which facilitates 32-bit memory access, thus allowing it to create the initial Interrupt descriptor table, Global Descriptor Table, page tables and enable paging. This provides the basic operating environment on which the operating system will build. StartUp module then loads and launches OS loader.

NTLDR's OS loader includes basic functionality to access IDE-based disks formatted for NTFS or FAT file systems, or CDFS (ISO 9660), ETFS or UDFS in newer operating system versions. Disks are accessed through the system BIOS, through native ARC routines on ARC systems, or via network using TFTP protocol. It should be noted that all BIOS calls are done through virtual 8086 mode beyond this point, because the BIOS can not be accessed directly within protected mode. If the boot disk is a SCSI disk and the SCSI controller is not using real-mode INT 0x13, an additional file, Ntbootdd.sys is loaded to handle disk access in place of the default routines. This is a copy of the same SCSI miniport driver that is used when Windows is running.

The boot loader then reads the contents of boot.ini to locate information on the system volume. If the boot.ini file is missing, the boot loader will attempt to locate information from the standard installation directory. For Windows NT machines, it will attempt to boot from C:\WINNT. For Windows XP and 2003 machines, it will boot from C:\WINDOWS.

At this point, the screen is cleared, and in the Windows 2000 or later versions of NTLDR and IA64ldr which support system hibernation, the root directory default volume as defined in boot.ini is searched for a hibernation file, hiberfil.sys. If this file is found and an active memory set is found in it, the contents of the file (which will match the amount of physical memory in the machine) are loaded into memory, and control is transferred into the Windows kernel at a point from which hibernation can be resumed[1]. The file is then immediately marked as non-active, so that a crash or other malfunction cannot cause this (now-outdated) memory state to be re-loaded. If a state resume fails, the next time NTLDR runs it will ask the user whether to try resuming again or to discard the file and proceed with normal booting.

If boot.ini contains more than one operating system entry, a boot menu is displayed to the user, allowing the user to choose which operating system is to be loaded. 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 NTLDR loads the associated "boot sector" file listed in boot.ini (by default, this is bootsect.dos if no file name is specified) and passes execution control to it. If an NT-based operating system is selected, NTLDR runs ntdetect.com, which gathers basic information about the computer's hardware as reported by the BIOS.

At this point in the boot process, NTLDR clears the screen and displays a textual progress bar, (which is often not seen on XP or 2003 systems, due to their 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.

If an x64 version of Windows is being booted (Windows XP Professional x64 Edition or Windows Server 2003 x64 Editions), the CPU is now switched into Long mode, enabling 64-bit addressing.

Next, the Windows kernel Ntoskrnl.exe and the Hardware Abstraction Layer hal.dll are read into memory. If either of these files fails to load, the message "Windows could not start because the following file was missing or corrupt" is displayed to the user, and the boot process comes to a halt.

If multiple hardware configurations are defined in the 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). This information (along with information on all detected hardware and Windows Services) is stored in the HKLM\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. HKLM\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 NTLDR or IA64ldr's choice if nothing else overrides this.
  • If the value of the Failed key matches Default, then NTLDR or IA64ldr 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 has chosen Last Known Good Configuration from the boot menu, 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.

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

The appropriate file system driver for the partition type (NTFS, FAT, or FAT32) which the Windows installation resides on is also loaded.

With this finished, control is then passed from NTLDR or IA64ldr to the kernel. At this time, Windows NT shows the famous "blue screen" displaying number of CPUs and the amount of memory installed, whilst Windows 2000, XP and 2003 switch into a graphical display mode to display the Windows logo, unless the /noguiboot or /sos switches are present in boot.ini.

Kernel loading phase

  1. ntoskrnl.exe < the kernel
  2. hal.dll < type of hardware abstraction layer
  3. kdcom.dll < Kernel Debugger HW Extension DLL
  4. bootvid.dll < for the windows logo and side-scrolling bar
  5. config\system registry
    1. HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute
    2. Process services in the order provided
      • HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder

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,[1] 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 [2] is started by smss.exe. Autochk mounts all drives and checks them one at a time whether they were not shut down cleanly before. In that case it will automatically run chkdsk, however just before the user can abort this process by pressing any key within 10 seconds (this was implemented in Windows NT 4.0 Service Pack 4, in earlier versions you could not skip chkdsk). Since Windows 2000, XP and 2003 show no text screen at that point (unlike NT, which still shows the blue text screen), they will show 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)
  • Any rename operations queued up are performed. This allows previously in-use files (e.g. drivers) to be replaced as part of a reboot.
  • 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.

Winlogon

"Begin logon" dialog box in Windows XP.
For more details on this topic, see Winlogon.

Winlogon is responsible for responding to the secure attention key (called secure attention sequence in Windows and it is the Control-Alt-Delete key combination), loading the user profile on logon, and optionally locking the computer when a screensaver is running. In Windows Vista and later operating systems, Winlogon's roles and responsibilities have changed significantly.

  1. Winlogon calls GINA
    1. GINA begin logon prompt is displayed (image)
    2. User presses SAS (Control-Alt-Delete)
    3. GINA logon dialog is displayed
    4. User inputs credentials (Username, Domain and Password)
    5. GINA passes credentials back to Winlogon
  2. Winlogon passes credentials to LSA
  3. Winlogon (loaded by SMSS)
    • At this point, Winlogon starts the Service Control Manager (SCM), which in turn will start all the Windows services that are set to "Auto-Start". The Local Security Authority Subsystem Service (lsass.exe) is also started, which enforces the local security policy (checking user permissions, creating audit trails, doling out security tokens, etc.).
  • userinit.exe

Logon phase

After a user has successfully logged in to the machine, Winlogon does the following:

  • Updates the Control Sets; the LastKnownGood control set is updated to reflect the current control set.
  • User and Computer Group Policy settings are applied.
  • Startup programs are run from the following locations:
    1. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
    2. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer\Run
    3. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
    4. HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
    5. HKCU\Software\Microsoft\Windows\CurrentVersion\Run
    6. HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
    7. All Users ProfilePath\Start Menu\Programs\Startup\ (please note that this path is localized on non-English versions of Windows)
    8. Current User ProfilePath\Start Menu\Programs\Startup\ (please note that this path is localized on non-English versions of Windows)

Remote booting & installation

 Please help improve this section by expanding it. Further information might be found on the talk page or at requests for expansion. (January 2007)
  • The Boot Information Negotiation Layer (BINL) is a Windows 2000 service that makes it possible for installation to be done on computers that are able to remotely boot.
For more details on this topic, see Remote_Installation_Services.

Additional information

The HKLM\HARDWARE section of the registry is populated by the kernel at boot-time with the information about detected hardware that was gathered by ntdetect.com. More specifically:

  • If ACPI is supported by the hardware, the Fixed ACPI Description Table (FADT), Firmware ACPI Control Structure (FACS) and Root System Description Table (RSDT) are written to HKLM\HARDWARE\ACPI.
  • Details about installed CPU(s), such as the brand, speed, and feature set (MMX, SSE, etc.) installed are stored in HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\#.
  • In similar fashion, details about installed FPU(s) are stored in HKLM\HARDWARE\DESCRIPTION\System\FloatingPointProcessor\#.
  • Information about the various multifunction adapters (ISA, PNP, ACPI, etc.) and the devices on them that are detected by ntdetect.com, is stored in HKLM\HARDWARE\DESCRIPTION\System\MultifunctionAdapter\#.

See also

Footnotes

  1. ^ Other boot loaders (typically for other operating systems) may be executed prior to control being passed to NTLDR. This known as a "chained" boot sequence.
  2. ^ This feature is known as hibernation, and was introduced in Windows 2000.

References

  1. ^ Windows, NT Object Manager

External links

Windows Components
Core
Management
tools
Applications
Games
Kernel
Services
File systems
Server
Architecture
Security
Compatibility
Retrieved from "http://en.wikipedia.org/wiki/Windows_NT_startup_process"

This article is from Wikipedia. All text is available under the terms of the GNU Free Documentation License.

Giant Panda

Mercedes Car
James Bond Guide
This site monitored by SitePinger.net