Advanced Windows internals: boot, registry, services & drivers

The boot sequence, end to end

To diagnose a machine that never reaches the desktop, you must know the order things happen. Firmware (UEFI) hands off to the Windows Boot Manager (bootmgr), which reads the BCD store and starts the Windows OS Loader (winload.efi). The loader pulls in the kernel (ntoskrnl.exe), the HAL, and every Boot-start driver. The kernel initialises, then starts Session Manager (smss.exe) — the first user-mode process. Smss sets up the registry, paging files, and environment, runs autochk, then launches the session leading to Winlogon and the desktop.

If a machine hangs on the spinner, the fault is usually before smss (a Boot/System driver). If it reaches the logon screen and then fails, you are in user-mode service territory.

Control sets and LastKnownGood

The live system configuration lives under HKLM\SYSTEM. Windows keeps multiple numbered control sets and records which is which under HKLM\SYSTEM\Select.

HKLM\SYSTEM\Select\Current        -> e.g. 1  (the ControlSet booted now)
HKLM\SYSTEM\Select\LastKnownGood  -> e.g. 1  (last config that reached logon)
HKLM\SYSTEM\Select\Failed         -> e.g. 2

LastKnownGood is updated to the current set only after a successful interactive logon. That is why “Last Known Good Configuration” can recover a machine that a bad driver just broke — it rolls back to the set that last reached the desktop.

Drivers: Start type and ErrorControl

Every driver and service has a Start type and an ErrorControl value under its Services key:

# Inspect a driver's load behaviour
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\disk' |
  Select-Object Start, Type, ErrorControl, ImagePath

Start: 0 = Boot, 1 = System, 2 = Auto, 3 = Demand, 4 = Disabled. ErrorControl: 0 = Ignore, 1 = Normal, 2 = Severe, 3 = Critical. A Boot-start driver (0) with Critical error control (3) that fails will bugcheck or force a LastKnownGood rollback. A Demand-start driver (3) that fails usually only breaks the feature that needed it. Reading these two numbers tells you whether a fault is a no-boot or a nuisance.

Services and dependency chains

Services start in dependency order under the Service Control Manager (SCM). If service A lists B in DependOnService and B fails, SCM refuses to start A.

# Dump a service's full config including its dependencies
sc.exe qc Netlogon

# List what depends on a given service
Get-Service -Name LanmanWorkstation -DependentServices

A single failed low-level service can cascade into a dozen downstream failures — always trace upstream to the first thing that broke, not the loudest error.

Auditing what actually runs

Autoruns from Sysinternals enumerates every autostart location: drivers, services, Run keys, scheduled tasks, codecs, and more, with signature verification. Use it to spot an unsigned or unexpected driver loading early. Pair it with the boot performance and setup logs:

Get-WinEvent -LogName 'Microsoft-Windows-Diagnostics-Performance/Operational' |
  Where-Object Id -in 100,101,102,103 |
  Select-Object TimeCreated, Id, Message -First 20

Your task

On a test VM, read HKLM\SYSTEM\Select and record which control set is Current and which is LastKnownGood. Pick three drivers and use Get-ItemProperty to list their Start and ErrorControl values; for each, predict in writing what would happen on boot if it failed to load. Run Autoruns, export the list, and identify any unsigned autostart entry. Finally, pick a multi-dependency service (e.g. Netlogon), map its dependency chain with sc.exe qc and Get-Service -DependentServices, and draw the chain.