The registry boot steps require NTLDR, ntdetect.com, and boot.ini be present in the root directory of the active partition, the system partition.

The PC boot sequence starts when power-on self-test (POST) loads the BIOS in memory. BIOS reads the MBR, the first physical (the master boot) sector on the hard disk. BIOS executes the MBR bootstrap code which finds the active partition, the root directory and loads NTLDR which

• switches the processor(s) to a 32-bit flat memory mode and loads itself into high memory to maximize memory available to the boot process.
• starts the appropriate minifile system depending whether the active partition is FAT or NTFS. The minifile drivers are built into NTDLR and can read either FAT or NTFS.
• parses boot.ini and displays OS choices. If boot.ini is missing, ntldr assumes C:\WINNT is the location for NT.
• NTLDR starts loading the OS selected. If this is a dual-boot PC, an additional file, BOOTSECT.DOS, is required. Control is passed to BOOTSECT.DOS if the other OS is selected. BOOTSECT.DOS is the bootsector required by the other OS and may have nothing to do with the DOS operating system. When an alternate OS is picked, the bootsec.dos is moved the the hard disk's boot sector and the OS-specific loader takes over. For example, IO.SYS for MS-DOS or OS2LDR.EXE for OS/2.
• If OS selected was NT, NTLDR shifts to 16-bit memory mode and loads ntdetect.com, a 16-bit application, which queries the hardware components of the PC and builds a dynamic registry subtree, HARDWARE, which is passed back to NTLDR. The HARDWARE subtree of HKEY_LOCAL_MACHINE exists only in memory, is read-only by nature and is regenerated at each reboot. The other subtrees are generated by reading the appropriate hive and hive.log files and are by nature designed to be modified. See Registry Tip: Files used to construct the registry for more information about the correspondance between the hard drive hive files and registry subtrees.
• NTLDR loades the boot-level drivers, that is those drivers with a Start value=0. These drivers are loaded but not initialized. An additional file, NTBOOTDD.SYS, will be present for systems that boot from SCSI and SCSI BIOS is enabled.
• ntoskrnl.exe
  The kernel portion of the load starts when NTLDR executes ntoskrnl.exeand the screen turns blue. At this point ntldr has switched back to protect memory mode and the kernel is at ring 0. The kernel initializes the boot-level drivers which had been loaded by NTLDR. The HKEY_LOCAL_MACHINE\SYSTEM\currentcontrolset\Control\ServiceGroupOrderspecifies the drive order of initialization. See below for an explanation of how currentcontrolsetbecomes CurrentControlSet. At this point its ControlSet001, ControlSet002or ControlSet001. On my PC the contents of ServiceGroupOrder value is: System Reserved, Boot Bus Extender, System Bus Extender. SCSI miniport, port, Primary disk, SCSI class, SCSI CDROM class, filter, boot file system, Base, Pointer Port, Keyboard Port, Pointer Class, Keyboard Class, Video Init, Video, Video Save, file system, Event log, Streams Drivers, NDIS Wrapper, PNP_TDI, NDIS, TDI, NetBIOSGroup, PlugPlay, SpoolerGroup, NetDDEGroup, Parallel arbitrator, extended base, RemoteValidation, PCI Configuration, and MS Transactions. A complex process certainly.
  • After the boot-level drivers load, kernel-level drivers in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services are loaded - that is drivers with a Start value=1.

    If you check the HKEY_LOCAL_MACHINE\SYSTEM subtree, you will see a set of subtrees such as ControlSet001, ControlSet002, ControlSet003, CurrentControlSet and Select. The Select key records the selection process - which subtree was used to control the current boot (ControlSet001 or ControlSet002 or ...). Select has values Current, Default, Failed, and LastKnownGood. Current will either match Default or LastKnownGood depending on whether you chose to boot using the LastKnownGood controlset. If you selected LastKnowGood, the Failed value will indicate which controlset had been the default controlset and was declared "failed" by your selection of LastKnownGood. If its a normal boot, Default and Current point to the same controlset (lets say 0x1) and LastKnownGood is controlset 0x2. The controlset subtree used during the boot is made accessible via the name CurrentControlSet for our convenience. At this point, the controlset pointed to as LastKnownGood is copied into the newly created Clone controlset. Thus a copy of the controlset used to boot is kept isolated and unchanged. When you successfully logon, the booting controlset is considered "good" and the Clone controlset becomes the controlset pointed to as LastKnownGood. It is declared good by the fact that the logon process succeeded. If there were non-fatal errors which you ignored or were unaware of, or if automatic or manual drivers fail after the logon, the LastKnownGood may not be very "good". The criterion for the creation of the LastKnowGood control set is fairly early and somewhat superficial.

    Error control for drivers: if a service or driver encounters an error, the kernel will act depending on the drivers ErrorControl value. The kernel will ignore the error if ErrorControl=0; the kernel will generate a warning of the error and continue loading if ErrorControl=1; the kernel will panic if ErrorControl=2 and switch to LastKnownGood or ignore the error if control set is already LastKnownGood; and the kernel will mark controlset as failed if ErrorControl=3 and switch to LastKnownGood or if its already LastKnownGood, kernel will generate a diagnostic (BSOD).

• Session Manager (smss.exe) starts.
  • executes the programs listed under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute. This is usually autocheck autochk * which does a chkdsk on each disk partition. This is a system level run key. If successful Session Manager
  • sets up the pagefiles defined under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PagingFiles.
  • writes CurrentControlSet and CloneControlSet to the Registry. CloneControlSet becomes ControlSet00x and later the LastKnowGood controlset if the logon is successful.
  • creates DOS devices defined in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices (AUX, MAILSLOT, NUL, PIPE, PRN, UNC).
  • loads Win32 subsystems defined in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems . Default is csrss.exe which controls all access to the screen.
  Last step of Session Manager starts first Win32 subsystem.
• The Win32 subsystem starts winlogon.exe and control moves from the SYSTEM portion of the registry to the Software portion, specifically:
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon.Winlogon
  • starts Local Security Authority (lsass.exe) and the print spooler (spoolss.exe)
  • When alt-ctl-del is pressed, the
• Service Controller (screg.exe) is executed.

  The Service Controller makes a pass through the SYSTEM\CurrentControlSet\Services looking for services with Start=2 (automatic). Thus NTLDR handled drivers with Start=0 and the Kernel handled those with Start=1 and the Win32 subsystem handles those with Start=2. The Win32 subsystem is kicked off when you start the logon process. Thats why its during or just after the logon process that you get messages about failed services. Services loading is more complex than driver loading since Services are loaded according to the DependOnGroup and DependOnService values in parallel (meaning that dependencies must be completed prior to starting a service) whereas the drivers initialized by the kernel were loaded in serial order.