IBM PC-AT‎ > ‎Windows‎ > ‎Boot Process (detailed)‎ > ‎

Phase 7 - Device Drivers & Kernel

At this point, the desired "control set" from the SYSTEM registry has been determined.  Now the computer scans a sub-key called Services.  For example, if the "control set" is 003, then it will look under HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Services.  Trouble-shooting note: when the system is up and running, you can open REGEDIT and find this as an alias under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.
 
The computer will scan through the "Services" key of the registry looking in each sub-key for a value named "Start".  If this is found, and has DWORD data of zero (0x000000), then it will load the file specified under the value "Driver" in the key ...ControlSet00x\Enum\Root\LEGACY_YYYY\0000.  Where YYYY is the name of the device driver.  For example, HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Enum\Root\LEGACY_VOLSNAP\0000 for the VolSnap driver.  The value "Driver" under this key may be a literal filename, but is more likely a GUID listed under ...ControlSet00x\Control\Class\{GUID}.  Sorry I can't be more specific... the Windows registry is not officially documented you know!
 
The important thing is the computer is looking for those "services" (which in this phase are usually device drivers in reality) which have a start type of 0 (boot); other start types occur in latter Phases.  If you are starting "safe mode" or specified /SOS or /BOOTLOG (maybe some other options), then instead of the normal Windows splash screen, you will get a list of each driver that is being loaded as it occurs.  You will get a nice error if any of the files can not be loaded.  Important!  This phase just loads the drivers into RAM (Random Access Memory); the drivers are not actually started yet!
 
Once all the critical/boot "device drivers" (some of them are abstractions / services) are loaded, the final task of Winload/NTLDR is to start the Windows kernel (loaded in Phase 6).  The optional arguments (if any) from the BOOT.INI / BCD entry are passed to the kernal start-up routine (much like a "command line" in a DOS box).  The following assumes the "standard" NTOSKRNL.EXE is used.
 
The kernel initializes internal data structures and starts the Plug-and-Play (PnP) Manager (see also ACPI).  For each "boot" driver loaded in Phase 6 (which primarily relied on the BIOS), the following occurs:
  • It checks the device is actually present (presumably it checks the PnP device ID in hardware).
  • Calls the "DriverEntry" function of the driver (initialize the driver software)
  • Sends a "Start Device" I/O Request Packet (IRP) to the driver.  The driver/service enters the running state (unless an error happens)
  • Sends a "Querry Device Relations" IRP to enumerate any child nodes of the device, if found the process repeats recursively.  That is, it checks the device, loads a driver if needed, calls "DriverEntry" and sends "Start Device" and "Querry Device Relations" IRPs to the child(ren).

With the boot drivers running, it now scans the registry services key again, but this time looking for entries with a start type value of 0x00000001 indicating "system".  These are loaded and initialized like described above, but using the Windows device drivers just loaded (instead of the BIOS). Next it does more internal initialization and then checks the file system on all mounted devices; the computer proceeds to Phase 8.

Trouble-shooting note: the system drivers may themselves load files.  If they fail to load their required files (missing or corrupt), you will often get bogus error messages!  I spent days trying to fix a "Corrupt NLS Setting" ... I tried changing the BCD language options, the System registry NLS options, etc. as described by various not-so-helpful web sources... it turns out the problem was a corrupt font file (the old .FON format, not the new .TTF) used by VgaSave.sys (I think).  Unfortunately the error logging service is not running yet, so it may take a very long time to guess what the error is!  This means you may have to do a full re-install if errors occur at this stage. 
 
When loading drivers, Windows may attempt to validate the code, depending if the device has a digital signature on file and the version of Windows and flags present in BOOT.INI / BCD hive. Windows Vista and later "require" signed drivers, however I believe it is possible to generate a fake signature for testing and also completely disable it on 1-shot basis with BOOT.INI / BCD settings.  "1-Shot" means the setting will be deleted from the BCD hive so it will resume with integretity checks on the next boot... in theory!  In may be possible to set the file security settings such that the BCD file can not be updated (untested theory).  On Windows 2K/XP you have the option to enable / require driver signatures in the "System" settings of control panel.  Unfortunately I am not sure where Windows stores the integrety hashes, and it seems only to apply to the executible code files, but not any data files (based on real world experience described above).
 
It would be a LOT easier to track down the problem if Windows would tell which drivers it is trying to start... unfortunately the /SOS option only lists the "boot" drivers that are loaded in bulk in the prior phase.  This phase starts them all without notice!   Not to mention the "system" drivers loaded in this phase which are never listed.  So yeah, near impossible to diagnose.

© H2Obsession, 2014
References: "Windows On/Off Transition Performance Analysis" Microsoft. April 11, 2011.
Comments