Revision as of 05:30, 3 April 2024 editLiz (talk | contribs)Autopatrolled, Checkusers, Oversighters, Administrators758,532 edits Misplaced Pages:Articles for deletion/Booting process of Windows NT closed as redirect (XFDcloser)Tags: New redirect Reverted← Previous edit | Revision as of 17:51, 23 April 2024 edit undo82.0.137.113 (talk) Decided to be bringing it back, deletion isn't the first choice.Tags: Removed redirect Manual revert RevertedNext edit → | ||
Line 1: | Line 1: | ||
<!-- Please do not remove or change this AfD message until the discussion has been closed. --> | |||
#REDIRECT ] | |||
{{Article for deletion/dated|page=Booting process of Windows NT|timestamp=20240320061652|year=2024|month=March|day=20|substed=yes|help=off}} | |||
<!-- Once discussion is closed, please place on talk page: {{Old AfD multi|page=Booting process of Windows NT|date=20 March 2024|result='''keep'''}} --> | |||
<!-- End of AfD message, feel free to edit beyond this point --> | |||
{{Use mdy dates|date=April 2012}} | |||
{{multiple issues|{{original research|date=October 2011}} | |||
{{more citations needed|date=October 2011}} | |||
{{technical|date=October 2011}}}} | |||
{{short description|Process by which several Microsoft Windows operating systems initialize}} | |||
The '''booting process of Windows NT''' is the process run to start ]. The process has been changed between releases, with the biggest changes being made with ]. In versions before Vista, the booting process begins when the ] loads the Windows NT ], ]. Starting with Vista, the booting process begins with either the ] or ] loading the ], which replaces NTLDR as the bootloader. Next, the bootloader starts the ], which starts the ], which begins the ]. Once the user is logged in, ], the ] used by ], is started. | |||
== History == | |||
{{Rcat shell| | |||
Windows Vista introduces a complete overhaul of the Windows operating system loader architecture.<ref>{{cite web |title=Inside the Windows Vista Kernel – Startup Processes |url=https://technet.microsoft.com/en-us/magazine/2007.03.vistakernel.aspx |access-date=2010-10-01 |publisher=Microsoft}}</ref><ref name="BCD">{{cite web |author=Microsoft |author-link=Microsoft |date=February 4, 2008 |title=Boot Configuration Data in Windows Vista |url=http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/BCD.docx |access-date=April 18, 2015 |format=DOCX}}</ref> The earliest known reference to this revised architecture is included within ] slides distributed by ] during the ] of 2004, when the operating system was codenamed as "Longhorn". This documentation mentions that the Windows operating system loader would be undergoing a significant restructuring in order to support ] and to "do some major overhaul of legacy code".<ref name="Restructuring">{{cite web |last=Ritz |first=Andrew |date=2004 |title=EFI and Windows 'Longhorn' |url=http://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/TW04022_WINHEC2004.ppt |archive-url=https://web.archive.org/web/20040609090303/http://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/TW04022_WINHEC2004.ppt |archive-date=June 9, 2004 |access-date=April 18, 2015 |publisher=] |format=PPT}}</ref> The new boot architecture completely replaces the ] architecture used in previous versions of ].<ref name="BCD"/> | |||
{{R to related topic}} | |||
}} | |||
Most of the steps that follow the NT kernel being loaded, including kernel initialization and user-space initialization, are kept the same as in earlier NT systems.<ref name="pollard">{{cite web |author-last=de Boyne Pollard |author-first=Jonathan |title=The Windows NT 6 boot process |url=https://jdebp.eu/FGA/windows-nt-6-boot-process.html |work=Frequently Given Answers}}</ref> Refactoring in ] resulted in ] being completely replaced by Credential Providers and graphical components in Windows Vista and later.<ref name=":1">{{Cite web |title=Winlogon and GINA |url=http://msdn.microsoft.com/en-us/library/aa380543.aspx |access-date=4 December 2014 |website=] |publisher=]}}</ref> | |||
== BIOS/UEFI == | |||
On systems with a ], the BIOS invokes ] boot code from a ] at startup. The MBR boot code and the VBR boot code are OS-specific. In Microsoft Windows, the MBR boot code tries to find an ] (the MBR is only 512 bytes), then executes the ] boot code of an active partition. The VBR boot code tries to find and execute ] for Windows XP, Windows Server 2003 and earlier, or the ] for Windows Vista and later, from an active partition.<ref>{{Cite web |title=Boot Sequence of Windows Multi-Boot - Multibooters.com |url=http://www.multibooters.com/guides/boot-sequence-of-mixed-windows-multiboot.html |access-date=2020-11-19 |website=www.multibooters.com}}</ref> | |||
On systems with a ], the UEFI invokes <code>bootmgfw.efi</code> from an ] at startup, starting the Windows Boot Manager. | |||
== Boot loader phase == | |||
{{details|NTLDR|Windows Boot Manager}} | |||
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 ]. Microsoft has also released operating systems for ] processors which use ] architecture. The boot loader of these editions of Windows is IA64ldr.efi (later referred as simply IA64ldr). It is an ] (EFI) program.<ref>{{cite web |title=In Windows Server 2003, you may not be able to start a computer from a GPT disk when the computer has an Itanium processor (Revision: 2.2) |url=http://support.microsoft.com/kb/902195 |access-date=October 29, 2011 |work=Microsoft Support |publisher=Microsoft Corporation}}</ref> Windows Vista and later use the Windows Boot Manager (<code>bootmgr</code>). | |||
=== Operating system selection === | |||
] | |||
The boot loader, once executed, searches for Windows operating systems. Windows Boot Manager does so by reading ] (BCD), a complex firmware-independent database for boot-time configuration data. Its predecessor, <code>NTLDR</code>, does so by reading the simpler <code>]</code>. 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 <code>C:\WINNT</code>. For machines running Windows XP, 2003, and later, it will boot from <code>C:\WINDOWS</code>. | |||
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 ]. NTLDR supports operating systems installed on disks whose file system is ] or ] file systems, CDFS (ISO 9660) or ].<ref>{{cite web |date=October 26, 2007 |title=Unified Extended Firmware Interface support in Windows Vista (Revision: 1.5) |url=http://support.microsoft.com/kb/930061 |access-date=October 30, 2011 |work=Microsoft Support |publisher=Microsoft Corporation}}</ref> Windows Boot Manager also supports operating systems installed inside a ] file, stored on an NTFS disk drive.<ref>{{cite web |date=February 20, 2009 |title=Boot from VHD in Win7 |url=https://technet.microsoft.com/en-us/edge/boot-from-vhd-in-win7.aspx |access-date=October 30, 2011 |work=] |publisher=Microsoft Corporation}}</ref> | |||
In Windows 2000 or in later versions of Windows in which ] is supported, the Windows boot loader starts the search for operating systems by searching for ''hiberfil.sys''. NTLDR looks into the ] 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 by running winresume.exe. | |||
Next, the boot loader looks for a list of installed operating system entries. If ], 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 ] is selected (specified by an ] 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. For Windows Vista and after, this is done through a separate program, <code>winload.exe</code>. | |||
=== 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 ] is displayed, containing various special boot modes including ], with the Last Known Good Configuration, with debugging enabled, and (in the case of Server editions) ]. Starting with Windows Vista, this menu was changed significantly. Once a boot mode has been selected (or if F8 was never pressed) booting continues. | |||
Hardware information about the computer is gathered by ] in Windows XP and earlier or by <code>winload.exe</code> in later versions. This information is stored in the <code>HKLM\HARDWARE\DESCRIPTION</code> key in the ]. | |||
Next the Windows NT kernel ('']''), the ] ('']''), kdcom.dll (Kernel Debugger HW Extension DLL), bootvid.dll (the Windows logo and side-scrolling bar), and config\system (one of the registry hives) are loaded. | |||
For Windows XP and earlier, 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). The required information (along with information on all detected hardware and Windows Services) is stored in the <code>HKEY_LOCAL_MACHINE\SYSTEM</code> portion of the registry, in a set of registry keys collectively called a ''Control Set''. In Windows XP and earlier, multiple control sets are kept, in the event that the settings contained in the currently-used one prohibit the system from booting. <code>HKEY_LOCAL_MACHINE\SYSTEM</code> contains control sets labeled <code>ControlSet001</code>, <code>ControlSet002</code>, etc. Windows uses <code>CurrentControlSet</code> to read and write information, but the key is merely a synthesized link to one of the sets defined by {{code|HKLM\System\Select\Control}}; it does not exist in the Hive file.<ref>{{cite web |title=What are Control Sets? What is CurrentControlSet? |url=http://support.microsoft.com/kb/100010 |website=Microsoft Support |archive-url=https://web.archive.org/web/20150217152952/http://support.microsoft.com/kb/100010 |archive-date=17 February 2015 |url-status=dead}}</ref> | |||
Windows now picks the "real" control set being used based on the values set in the <code>HKEY_LOCAL_MACHINE\SYSTEM\Select</code> registry key: | |||
* <code>Default</code> will be the boot loader's choice if nothing else overrides it. | |||
* If the value of the <code>Failed</code> key matches <code>Default</code>, 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 chooses (or has chosen) Last Known Good Configuration, the control set indicated by the <code>LastKnownGood</code> key is used instead of <code>Default</code>. | |||
When a control set is chosen, the <code>Current</code> key gets set accordingly. The <code>Failed</code> key is also set to the same as <code>Current</code> until the end of the boot process. <code>LastKnownGood</code> is also set to <code>Current</code> 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: | |||
* <code>HKLM\SYSTEM\CurrentControlSet\Services</code> | |||
* <code>HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder</code> | |||
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 (], ], 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 == | |||
{{details|ntoskrnl.exe}} | |||
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 ] is initialized. The memory manager is initialized, creating areas for the file system cache, ] and nonpaged pools of memory. The ] is initialized,<ref>{{Cite web |date=June 3, 2005 |title=Windows, NT Object Manager |url=http://channel9.msdn.com/ShowPost.aspx?PostID=73995 |access-date=October 24, 2011 |work=] |publisher=Microsoft Corporation}}</ref> and creates the initial ] for assignment to the first ] on the system, and the Process Manager itself. The ] as well as the System process are created at this point. | |||
The second phase involves initializing the device drivers which were identified by ] 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 == | |||
{{details|Session Manager Subsystem}} | |||
Once all the Boot and System drivers have been loaded, the kernel (system thread) starts the ] (<code>smss.exe</code>). The Session Manager stores its configuration at <code>HKLM\SYSTEM\CurrentControlSet\Control\Session Manager</code>. The exact operation of most of these items is based on the configuration set in the registry.<ref>{{Cite web |title=Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager |url=https://renenyffenegger.ch/notes/Windows/registry/tree/HKEY_LOCAL_MACHINE/System/CurrentControlSet/Control/Session-Manager/index#:~:text=Registry:%20HKEY_LOCAL_MACHINE%5CSYSTEM%5CCurrentControlSet%5CControl%5CSession%20Manager |access-date=2023-05-13 |website=renenyffenegger.ch}}</ref> | |||
The Session Manager creates the environment variables located at the registry entry <code>HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment</code>. It also creates additional paging files with configuration data from <code>HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management</code>.<ref name="Troubleshooting">{{cite web |date=November 3, 2005 |title=Troubleshooting the Startup Process |url=https://technet.microsoft.com/en-us/library/bb457123.aspx |access-date=October 24, 2011 |work=Windows XP Resource Kit |publisher=Microsoft Technet}}</ref> | |||
The Session Manager Subsystem is then responsible starting the Win32 subsystem. It starts the kernel-mode side of the subsystem implemented by <code>win32k.sys</code>.<ref name="Troubleshooting" /> Once this is done, Windows is able to switch into graphical mode as there is now enough infrastructure in place. The user-mode side of the subsystem, ] (<code>csrss.exe</code>), is also started.<ref name="Troubleshooting" /> This makes the Win32 subsystem available to user-mode applications. | |||
The Session Manager Subsystem is also responsible for doing any operations that are requested to be done at the start of a session. Commands listed in <code>HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute</code>, such as <code>autochk</code> and <code>convert</code>, are executed. These commands are run before services are loaded by later steps of the booting process.<ref name="Troubleshooting" /> Any rename operations queued at <code>HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations</code>. This is used to allow previously in-use files (e.g. drivers) to be replaced as part of a reboot.<ref name=":0">{{cite book |last1=Ionescu |first1=Alex |title=Windows internals, Part 2 |last2=Russinovich |first2=Mark |last3=Solomon |first3=David A. |publisher=Microsoft |year=2012 |isbn=978-0735665873 |edition=6th |location=Redmond, Wash. |pages=522–527}}</ref> | |||
].]] | |||
<code>autochk</code> 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.<ref>{{Cite web |title=Resource Kit |url=http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/prkd_tro_mdca.asp |url-status=dead |archive-url=https://web.archive.org/web/20070311183615/http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/prkd_tro_mdca.asp |archive-date=March 11, 2007 |publisher=Microsoft Corporation}}</ref> | |||
Starting with Windows Vista, the Session Manager Subsystem creates a temporary instance of itself that launches the Windows Startup Application (<code>wininit.exe</code>) and a second Client/Server Runtime Subsystem (<code>csrss.exe</code>) for Session 0, a session decided to system processes. From here, the Windows Startup Application starts the ] (<code>services.exe</code>), which starts all the Windows services that are set to "Auto-Start" and sets the <code>LastKnownGood</code> to the current control set.<ref name=":0" /> The application also starts the ] (<code>lsass.exe</code>). Before Windows Vista, these processes were started by ] instead of the Windows Startup Application, which didn't exist. The dedicated session for system processes also didn't exist.<ref name=":2">{{Cite web |last=Archiveddocs |title=Windows Administration: Inside the Windows Vista Kernel: Part 2 |url=https://learn.microsoft.com/en-us/previous-versions/technet-magazine/cc162480(v=msdn.10) |access-date=2023-05-13 |website=learn.microsoft.com |language=en-us}}</ref> | |||
The Session Manager Subsystem now starts ] (Windows Logon Application), which is responsible for handling interactive logons to a Windows system, either local or remote.<ref name=":2" /> | |||
== Authentication == | |||
{{details|Winlogon}} | |||
The authentication process is implemented by Winlogon. This program is responsible for responding to the ] (SAS), loading the user profile on logon, and optionally locking the computer when a ] is running. | |||
] lock screen, requiring user to press ].]] | |||
Winlogon checks if automatic logon is enabled, and if so, logs in to the specified account automatically.<ref>{{Cite web |last=Deland-Han |title=Configure Windows to automate logon - Windows Server |url=https://learn.microsoft.com/en-us/troubleshoot/windows-server/user-profiles-and-logon/turn-on-automatic-logon |access-date=2023-05-13 |website=learn.microsoft.com |language=en-us}}</ref> If there is not automatic logon enabled, Winlogon starts the process to allow the user to logon. Before Windows Vista this was done by ],<ref name=":4">{{Cite book |last=Russinvoich |first=Mark E. |title=Microsoft Windows Internals |last2=Solomon |first2=David |publisher=] |year=2005 |isbn=978-0735619173 |edition=4th |location=Redmond, Washington |pages=81 |language=en}}</ref> but starting with Vista this is done by LogonUI. If configured, both of these programs display a prompt for the user to enter the Secure Attention Sequence (SAS) (]). They then display the login dialog which prompts the user to enter their credentials. Once the user submits these credentials, they are passed to LSASS and any other additional network credential providers. This allows multiple network providers to authenticate the user at once during normal logon.<ref name=":3">{{cite book |last1=Ionescu |first1=Alex |title=Windows internals, Part 1 |last2=Russinovich |first2=Mark |last3=Solomon |first3=David A. |publisher=Microsoft Press |year=2012 |isbn=978-0735648739 |edition=6th |location=Redmond, Wash. |pages=77}}</ref><ref name=":4" /> | |||
LSASS first tries to use cached data in the LSA database, the SECURITY hive of the registry. If there is none, LSASS determines which account protocol is to be used by using the security packages listed in the key <code>HKLM\SYSTEM\CurrentControlSet\Control\Lsa</code>. There are two standard packages, <code>msv1_0.dll</code>, which implements the ] protocols, and <code>Kerberos.dll</code>, which provides remote login by using ]. <code>msv1_0.dll</code> is used in stand-alone systems and domain-member systems for backward compatibility. If the user is trying to log into the local host then <code>msv1_0.dll</code> uses the ] database located at <code>HKLM/SAM</code>. If the user is trying to log into another host then the NetLogon ] is used to carry the data with the following sequence:<syntaxhighlight lang="text">msv1_0.dll <-> netlogon <-> remote netlogon <-> remote msv1_0.dll <-> remote SAM</syntaxhighlight>After the user is authenticated, LSASS enforces the local security policy (checking user permissions, creating audit trails, doling out security tokens, etc.) and passes control pack to Winlogon. Winlogon creates and opens an interactive windows station, <code>WinSta0</code>,<ref>{{cite web |title=Window Stations |url=http://msdn.microsoft.com/en-us/library/windows/desktop/ms687096%28v=vs.85%29.aspx |access-date=19 April 2014 |work=MSDN |publisher=Microsoft Corporation}}</ref> and creates three desktops, <code>Winlogon</code>, <code>Default</code> and <code>ScreenSaver</code>. Winlogon switches from the Winlogon desktop to the <code>Default</code> desktop when the shell indicates that it is ready to display something for the user, or after thirty seconds, whichever comes first. The system switches back to the <code>Winlogon</code> desktop if the user presses ] or when a ] prompt is shown.<ref>{{cite web |title=Desktops |url=http://msdn.microsoft.com/en-us/library/windows/desktop/ms682573%28v=vs.85%29.aspx |access-date=19 April 2014 |work=MSDN |publisher=Microsoft Corporation}}</ref> Winlogon now starts the program specified in the Userinit value which defaults to <code>userinit.exe</code>. This value supports multiple executables.<ref name=":3" /> | |||
== Shell == | |||
{{details|File Explorer}} | |||
<code>Userinit</code> 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 <code>Explorer.exe</code>) is started from the registry entry <code>Shell=</code> pointed to by the same registry entry in key <code>HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\system.ini\Boot</code>; its default value is <code>SYS:Microsoft\Windows NT\CurrentVersion\Winlogon</code>, which evaluates to <code>HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon</code>.<ref>{{cite web |title=Different Shells for Different Users |url=http://msdn.microsoft.com/en-us/library/ms838576.aspx |access-date=16 March 2014 |publisher=Microsoft Corporation}}</ref> | |||
<code>Userinit</code> starts by loading 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 ] settings are then applied and user scripts, machine scripts, and <code>proquota.exe</code> are run. Startup programs are started and then the shell configured in registry, which defaults to <code>explorer.exe</code>. Now <code>Userinit</code> exits and the shell program continues running without a parent process. | |||
<code>Userinit</code> runs startup programs from the following locations:<ref name="Troubleshooting" /> | |||
* <code>HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce</code> | |||
* <code>HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run</code> | |||
* <code>HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run</code> | |||
* <code>HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Load</code> | |||
* <code>HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run</code> | |||
* <code>HKCU\Software\Microsoft\Windows\CurrentVersion\Run</code> | |||
* <code>HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce</code> | |||
* <code>%ALLUSERSPROFILE%\Start Menu\Programs\Startup\</code> (this path is localized on non-English versions of Windows before Vista) | |||
* <code>%USERPROFILE%\Start Menu\Programs\Startup\</code> (this path is localized on non-English versions of Windows before Vista) | |||
== Advanced options == | |||
With the advent of the new boot manager in ], many components have been changed; one is the Advanced Boot Options menu that provides options for advanced boot modes (e.g., Safe Mode). Due to the implementation of ] in ] and up, access to the Advanced Boot Options menu has been disabled by default. However, access is still possible with a BCD modification. These are the possible boot modes: | |||
* Repair Your Computer - Boots ] (WinRE or Windows RE) | |||
* Safe Mode - Loads Safe Mode, a boot mode with minimal drivers and resources intended for malware removal or replacing faulty drivers. | |||
* Safe Mode with Networking - Loads Safe Mode along with the network drivers. | |||
* Safe Mode with Command Prompt - Loads Safe Mode with the ] as the shell instead of ]. Windows Explorer can still be loaded by typing <code>explorer</code> at the command prompt. | |||
* Enable Boot Logging - Enables writing of <code>ntbtlog.txt</code>, a file that will log the boot process; listing drivers that loaded and drivers that did not. | |||
* Enable low resolution video - Disables the default graphics driver and uses the standard ] driver. Intended in case the user changed the resolution to an unusable level (i.e. 320×200 at low refresh rates <24 Hz, 60 Hz>) | |||
* Last Known Good Configuration - Loads configuration based on the last successful boot process. Intended for ] corruptions. This mode is removed in Windows 8 and later versions of Windows. | |||
* ] - Boot mode used to reboot the ] in case it is not working as intended. | |||
* Debugging Mode - Boots while loading the kernel debugger. | |||
* Disable automatic restart on system failure - Disables the auto-reboot function after a ] is experienced. | |||
* Disable early launch anti-malware driver - ELAM prechecks boot required drivers for signatures and tampering. Disabling ELAM is intended to allow booting on false positive driver checks but could also allow a tampered driver to load.<ref>{{Cite web |last=QuinnRadich |title=Early launch antimalware - Win32 apps |url=https://docs.microsoft.com/en-us/windows/win32/w8cookbook/secured-boot |access-date=2021-12-14 |website=docs.microsoft.com |language=en-us}}</ref> | |||
* Disable Driver Signature Enforcement - Disables the kernel setting that prohibits unsigned drivers from loading. | |||
* Start Windows Normally | |||
The ABO menu is accessible by rapidly pressing or holding the <code>F8</code> key before Windows boots. Starting from Windows 8 on UEFI, it can only be accessed by clicking <code>Restart</code> while holding the <code>Shift</code> key. | |||
== Remote booting and installation == | |||
{{details|Windows Deployment Services}} | |||
To successfully boot, the client must support ] booting and the ] (WDS) ] must be installed on the server. It is not installed by default. WDS is the successor of ] (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<ref>{{cite web |title=Deploying Windows XP Embedded Remote Boot |url=http://msdn.microsoft.com/en-us/library/ms838569%28v=winembedded.5%29.aspx |access-date=18 April 2014 |work=MSDN |publisher=Microsoft Corporation}}</ref> and is only available for this flavor of Windows.<ref>{{cite web |title=Remote Boot Overview |url=http://msdn.microsoft.com/en-us/library/ms852360.aspx |access-date=19 April 2014 |work=MSDN |publisher=Microsoft Corporation}}</ref> | |||
The general process for both methods is as follows: | |||
* PXE boots | |||
* ] request broadcast | |||
* Optionally DHCP router redirects to the server | |||
* The server sends the ] (NBP) (<code>PXEboot.com</code>)<ref>{{cite web |title=Managing Network Boot Programs |url=https://technet.microsoft.com/en-us/library/cc732351%28v=ws.10%29.aspx |access-date=18 April 2014 |work=TechNet |publisher=Microsoft Corporation}}</ref> through ] | |||
* The NBP program downloads the required files through the BINL protocol | |||
The Boot Information Negotiation Layer (BINL) is a ] ] running on the server that communicates with the client after the NBP was already loaded by the PXE. | |||
== See also == | |||
* ] | |||
* ] | |||
* ] | |||
* ] | |||
* ] | |||
* ] | |||
* ] | |||
== References == | |||
<references /> | |||
== Further reading == | |||
{{Refbegin}} | |||
#{{cite book |last1=Russinovich |first1=Mark |url=https://archive.org/details/isbn_9780735619173/page/251 |title=Microsoft Windows Internals |last2=Solomon |first2=David A. |publisher=Microsoft Press |year=2005 |isbn=0-7356-1917-4 |edition=4th |pages= |chapter=Startup and Shutdown |author-link1=Mark Russinovich}} | |||
#{{cite book |last1=Minasi |first1=Mark |url=https://archive.org/details/windowsntmagazin00john |title=Administrator's Survival Guide: System Management and Security |last2=Enck |first2=John |date=June 1998 |publisher=Windows IT Library |isbn=1-882419-88-X |chapter=Troubleshooting NT Boot Failures |access-date=February 15, 2006}} | |||
#{{cite web |date=February 28, 2007 |title=Description of PXE Interaction Among PXE Client, DHCP, and RIS Server (Revision 2.4) |url=http://support.microsoft.com/kb/244036/ |access-date=October 24, 2011 |work=Microsoft Support |publisher=Microsoft Corporation}} | |||
#{{Cite web |date=January 19, 2007 |title=Definition of the RunOnce Keys in the Registry (revision 2.3) |url=http://support.microsoft.com/kb/137367 |access-date=October 24, 2011 |work=Microsoft Support |publisher=Microsoft Corporation}} | |||
#{{Cite web |date=November 28, 2007 |title=Available switch options for the Windows XP and the Windows Server 2003 Boot.ini files (revision 6.3) |url=http://support.microsoft.com/kb/833721 |access-date=October 24, 2011 |work=Microsoft Support |publisher=Microsoft Corporation}} | |||
{{Refend}} | |||
== External links == | |||
* | |||
* {{Webarchive|url=https://web.archive.org/web/20190106121821/http://www.vorck.com/windows/edit-setupapi.html |date=January 6, 2019 }} | |||
{{Windows Components}} | |||
{{Firmware and booting}} | |||
] | |||
] |
Revision as of 17:51, 23 April 2024
An editor has nominated this article for deletion. You are welcome to participate in the deletion discussion, which will decide whether or not to retain it.Feel free to improve the article, but do not remove this notice before the discussion is closed. For more information, see the guide to deletion. Find sources: "Booting process of Windows NT" – news · newspapers · books · scholar · JSTOR%5B%5BWikipedia%3AArticles+for+deletion%2FBooting+process+of+Windows+NT%5D%5DAFD |
This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
The booting process of Windows NT is the process run to start Windows NT. The process has been changed between releases, with the biggest changes being made with Windows Vista. In versions before Vista, the booting process begins when the BIOS loads the Windows NT bootloader, NTLDR. Starting with Vista, the booting process begins with either the BIOS or UEFI loading the Windows Boot Manager, which replaces NTLDR as the bootloader. Next, the bootloader starts the kernel, which starts the session manager, which begins the login process. Once the user is logged in, File Explorer, the graphical user interface used by Windows NT, is started.
History
Windows Vista introduces a complete overhaul of the Windows operating system loader architecture. The earliest known reference to this revised architecture is included within PowerPoint slides distributed by Microsoft during the Windows Hardware Engineering Conference of 2004, when the operating system was codenamed as "Longhorn". This documentation mentions that the Windows operating system loader would be undergoing a significant restructuring in order to support EFI and to "do some major overhaul of legacy code". The new boot architecture completely replaces the NTLDR architecture used in previous versions of Windows NT.
Most of the steps that follow the NT kernel being loaded, including kernel initialization and user-space initialization, are kept the same as in earlier NT systems. Refactoring in Winlogon resulted in GINA being completely replaced by Credential Providers and graphical components in Windows Vista and later.
BIOS/UEFI
On systems with a BIOS, the BIOS invokes MBR boot code from a hard disk drive at startup. The MBR boot code and the VBR boot code are OS-specific. In Microsoft Windows, the MBR boot code tries to find an active partition (the MBR is only 512 bytes), then executes the VBR boot code of an active partition. The VBR boot code tries to find and execute NTLDR for Windows XP, Windows Server 2003 and earlier, or the Windows Boot Manager for Windows Vista and later, from an active partition.
On systems with a UEFI, the UEFI invokes bootmgfw.efi
from an EFI system partition at startup, starting the Windows Boot Manager.
Boot loader phase
Further information: NTLDR and Windows Boot ManagerThe 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. Windows Vista and later use the Windows Boot Manager (bootmgr
).
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 machines running Windows XP, 2003, and later, 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 by running winresume.exe.
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. For Windows Vista and after, this is done through a separate program, winload.exe
.
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 options 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. Starting with Windows Vista, this menu was changed significantly. Once a boot mode has been selected (or if F8 was never pressed) booting continues.
Hardware information about the computer is gathered by NTDETECT.COM in Windows XP and earlier or by winload.exe
in later versions. This information is stored in the HKLM\HARDWARE\DESCRIPTION
key in the Windows Registry.
Next the Windows NT kernel (Ntoskrnl.exe), the Hardware Abstraction Layer (hal.dll), kdcom.dll (Kernel Debugger HW Extension DLL), bootvid.dll (the Windows logo and side-scrolling bar), and config\system (one of the registry hives) are loaded.
For Windows XP and earlier, 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). 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. In Windows XP and earlier, multiple control sets 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. Windows uses CurrentControlSet
to read and write information, but the key is merely a synthesized link to one of the sets defined by HKLM\System\Select\Control
; it does not exist in the Hive file.
Windows now picks the "real" control set being used based on the values set in the HKEY_LOCAL_MACHINE\SYSTEM\Select
registry key:
Default
will be the boot loader's choice if nothing else overrides it.- If the value of the
Failed
key matchesDefault
, 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 chooses (or has chosen) Last Known Good Configuration, the control set indicated by the
LastKnownGood
key is used instead ofDefault
.
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
Further information: ntoskrnl.exeThe 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 nonpaged pools of memory. The Object Manager is initialized, and creates the 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
Further information: Session Manager SubsystemOnce all the Boot and System drivers have been loaded, the kernel (system thread) starts the Session Manager Subsystem (smss.exe
). 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.
The Session Manager creates the environment variables located at the registry entry HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
. It also creates additional paging files with configuration data from HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
.
The Session Manager Subsystem is then responsible starting the Win32 subsystem. It starts the kernel-mode side of the subsystem implemented by win32k.sys
. Once this is done, Windows is able to switch into graphical mode as there is now enough infrastructure in place. The user-mode side of the subsystem, Client/Server Runtime Subsystem (csrss.exe
), is also started. This makes the Win32 subsystem available to user-mode applications.
The Session Manager Subsystem is also responsible for doing any operations that are requested to be done at the start of a session. Commands listed in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute
, such as autochk
and convert
, are executed. These commands are run before services are loaded by later steps of the booting process. Any rename operations queued at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
. This is used to allow previously in-use files (e.g. drivers) to be replaced as part of a reboot.
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.
Starting with Windows Vista, the Session Manager Subsystem creates a temporary instance of itself that launches the Windows Startup Application (wininit.exe
) and a second Client/Server Runtime Subsystem (csrss.exe
) for Session 0, a session decided to system processes. From here, the Windows Startup Application starts the Service Control Manager (services.exe
), which starts all the Windows services that are set to "Auto-Start" and sets the LastKnownGood
to the current control set. The application also starts the Local Security Authority Subsystem Service (lsass.exe
). Before Windows Vista, these processes were started by Windows Logon instead of the Windows Startup Application, which didn't exist. The dedicated session for system processes also didn't exist.
The Session Manager Subsystem now starts Winlogon (Windows Logon Application), which is responsible for handling interactive logons to a Windows system, either local or remote.
Authentication
Further information: WinlogonThe authentication process is implemented by Winlogon. This program is 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.
Winlogon checks if automatic logon is enabled, and if so, logs in to the specified account automatically. If there is not automatic logon enabled, Winlogon starts the process to allow the user to logon. Before Windows Vista this was done by GINA, but starting with Vista this is done by LogonUI. If configured, both of these programs display a prompt for the user to enter the Secure Attention Sequence (SAS) (Control-Alt-Delete). They then display the login dialog which prompts the user to enter their credentials. Once the user submits these credentials, they are passed to LSASS and any other additional network credential providers. This allows multiple network providers to authenticate the user at once during normal logon.
LSASS first tries to use cached data in the LSA database, the SECURITY hive of the registry. 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
. There are two standard packages, msv1_0.dll
, which implements the NTLM protocols, and Kerberos.dll
, which provides remote login by using Active Directory. msv1_0.dll
is used in stand-alone systems and domain-member systems for backward compatibility. If the user is trying to log into the local host then msv1_0.dll
uses the Security Account Manager database located at HKLM/SAM
. If the user is trying to log into another host then the NetLogon service is used to carry the data with the following sequence:
msv1_0.dll <-> netlogon <-> remote netlogon <-> remote msv1_0.dll <-> remote SAM
After the user is authenticated, LSASS enforces the local security policy (checking user permissions, creating audit trails, doling out security tokens, etc.) and passes control pack to Winlogon. Winlogon creates and opens an interactive windows station, WinSta0
, and creates three desktops, Winlogon
, Default
and ScreenSaver
. Winlogon switches from the Winlogon desktop to the Default
desktop when the shell indicates that it is ready to display something for the user, or after thirty seconds, whichever comes first. The system switches back to the Winlogon
desktop if the user presses Control-Alt-Delete or when a User Account Control prompt is shown. Winlogon now starts the program specified in the Userinit value which defaults to userinit.exe
. This value supports multiple executables.
Shell
Further information: File ExplorerUserinit
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
starts by loading 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 then applied and user scripts, machine scripts, and proquota.exe
are run. Startup programs are started and then the shell configured in registry, which defaults to explorer.exe
. Now 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)
Advanced options
With the advent of the new boot manager in Windows Vista, many components have been changed; one is the Advanced Boot Options menu that provides options for advanced boot modes (e.g., Safe Mode). Due to the implementation of fast startup in Windows 8 and up, access to the Advanced Boot Options menu has been disabled by default. However, access is still possible with a BCD modification. These are the possible boot modes:
- Repair Your Computer - Boots Windows Recovery Environment (WinRE or Windows RE)
- Safe Mode - Loads Safe Mode, a boot mode with minimal drivers and resources intended for malware removal or replacing faulty drivers.
- Safe Mode with Networking - Loads Safe Mode along with the network drivers.
- Safe Mode with Command Prompt - Loads Safe Mode with the Command Prompt as the shell instead of Windows Explorer. Windows Explorer can still be loaded by typing
explorer
at the command prompt. - Enable Boot Logging - Enables writing of
ntbtlog.txt
, a file that will log the boot process; listing drivers that loaded and drivers that did not. - Enable low resolution video - Disables the default graphics driver and uses the standard VGA driver. Intended in case the user changed the resolution to an unusable level (i.e. 320×200 at low refresh rates <24 Hz, 60 Hz>)
- Last Known Good Configuration - Loads configuration based on the last successful boot process. Intended for Registry corruptions. This mode is removed in Windows 8 and later versions of Windows.
- Directory Services Restore Mode - Boot mode used to reboot the Domain Controller in case it is not working as intended.
- Debugging Mode - Boots while loading the kernel debugger.
- Disable automatic restart on system failure - Disables the auto-reboot function after a Blue Screen of Death is experienced.
- Disable early launch anti-malware driver - ELAM prechecks boot required drivers for signatures and tampering. Disabling ELAM is intended to allow booting on false positive driver checks but could also allow a tampered driver to load.
- Disable Driver Signature Enforcement - Disables the kernel setting that prohibits unsigned drivers from loading.
- Start Windows Normally
The ABO menu is accessible by rapidly pressing or holding the F8
key before Windows boots. Starting from Windows 8 on UEFI, it can only be accessed by clicking Restart
while holding the Shift
key.
Remote booting and installation
Further information: Windows Deployment ServicesTo 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 boots
- DHCP request broadcast
- Optionally 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 Setup
- Booting process of DOS-based Windows
- Booting process of Linux
- Master boot record
- Power-on self-test
- BootVis
References
- "Inside the Windows Vista Kernel – Startup Processes". Microsoft. Retrieved October 1, 2010.
- ^ Microsoft (February 4, 2008). "Boot Configuration Data in Windows Vista" (DOCX). Retrieved April 18, 2015.
- Ritz, Andrew (2004). "EFI and Windows 'Longhorn'". Microsoft. Archived from the original (PPT) on June 9, 2004. Retrieved April 18, 2015.
- de Boyne Pollard, Jonathan. "The Windows NT 6 boot process". Frequently Given Answers.
- "Winlogon and GINA". MSDN. Microsoft. Retrieved December 4, 2014.
- "Boot Sequence of Windows Multi-Boot - Multibooters.com". www.multibooters.com. Retrieved November 19, 2020.
- "In Windows Server 2003, you may not be able to start a computer from a GPT disk when the computer has an Itanium processor (Revision: 2.2)". Microsoft Support. Microsoft Corporation. Retrieved October 29, 2011.
- "Unified Extended Firmware Interface support in Windows Vista (Revision: 1.5)". Microsoft Support. Microsoft Corporation. October 26, 2007. Retrieved October 30, 2011.
- "Boot from VHD in Win7". TechNet Edge. Microsoft Corporation. February 20, 2009. Retrieved October 30, 2011.
- "What are Control Sets? What is CurrentControlSet?". Microsoft Support. Archived from the original on February 17, 2015.
- "Windows, NT Object Manager". Channel 9. Microsoft Corporation. June 3, 2005. Retrieved October 24, 2011.
- "Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager". renenyffenegger.ch. Retrieved May 13, 2023.
- ^ "Troubleshooting the Startup Process". Windows XP Resource Kit. Microsoft Technet. November 3, 2005. Retrieved October 24, 2011.
- ^ Ionescu, Alex; Russinovich, Mark; Solomon, David A. (2012). Windows internals, Part 2 (6th ed.). Redmond, Wash.: Microsoft. pp. 522–527. ISBN 978-0735665873.
- "Resource Kit". Microsoft Corporation. Archived from the original on March 11, 2007.
- ^ Archiveddocs. "Windows Administration: Inside the Windows Vista Kernel: Part 2". learn.microsoft.com. Retrieved May 13, 2023.
- Deland-Han. "Configure Windows to automate logon - Windows Server". learn.microsoft.com. Retrieved May 13, 2023.
- ^ Russinvoich, Mark E.; Solomon, David (2005). Microsoft Windows Internals (4th ed.). Redmond, Washington: Microsoft Press. p. 81. ISBN 978-0735619173.
- ^ Ionescu, Alex; Russinovich, Mark; Solomon, David A. (2012). Windows internals, Part 1 (6th ed.). Redmond, Wash.: Microsoft Press. p. 77. ISBN 978-0735648739.
- "Window Stations". MSDN. Microsoft Corporation. Retrieved April 19, 2014.
- "Desktops". MSDN. Microsoft Corporation. Retrieved April 19, 2014.
- "Different Shells for Different Users". Microsoft Corporation. Retrieved March 16, 2014.
- QuinnRadich. "Early launch antimalware - Win32 apps". docs.microsoft.com. Retrieved December 14, 2021.
- "Deploying Windows XP Embedded Remote Boot". MSDN. Microsoft Corporation. Retrieved April 18, 2014.
- "Remote Boot Overview". MSDN. Microsoft Corporation. Retrieved April 19, 2014.
- "Managing Network Boot Programs". TechNet. Microsoft Corporation. Retrieved April 18, 2014.
Further reading
- Russinovich, Mark; Solomon, David A. (2005). "Startup and Shutdown". Microsoft Windows Internals (4th ed.). Microsoft Press. pp. 251–273. ISBN 0-7356-1917-4.
- Minasi, Mark; Enck, John (June 1998). "Troubleshooting NT Boot Failures". Administrator's Survival Guide: System Management and Security. Windows IT Library. ISBN 1-882419-88-X. Retrieved February 15, 2006.
- "Description of PXE Interaction Among PXE Client, DHCP, and RIS Server (Revision 2.4)". Microsoft Support. Microsoft Corporation. February 28, 2007. Retrieved October 24, 2011.
- "Definition of the RunOnce Keys in the Registry (revision 2.3)". Microsoft Support. Microsoft Corporation. January 19, 2007. Retrieved October 24, 2011.
- "Available switch options for the Windows XP and the Windows Server 2003 Boot.ini files (revision 6.3)". Microsoft Support. Microsoft Corporation. November 28, 2007. Retrieved October 24, 2011.
External links
- Startup Applications List
- How to edit SETUPAPI.DLL Archived January 6, 2019, at the Wayback Machine
Firmware and booting | |||||||
---|---|---|---|---|---|---|---|
Processes | |||||||
Booting firmware |
| ||||||
Hybrid firmware bootloader | |||||||
Bootloaders |
| ||||||
Partition layouts | |||||||
Partitions | |||||||
Utilities |
| ||||||
Network boot | |||||||
ROM variants | |||||||
Related |