Registry Construction Steps

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.exe and 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\ServiceGroupOrder
  specifies the drive order of initialization. See below for an explanation of how
  currentcontrolset becomes CurrentControlSet. At this point its ControlSet001, ControlSet002 or
  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.