The Windows Boot Process: From UEFI to the Session Manager

Windows Internals
Time it takes to read this article 4 minutes.

Almost every advanced Windows topic — driver signing, credential protection, kernel exploitation, rootkits — eventually traces back to a single question: what actually happens between pressing the power button and seeing the logon screen? Understanding the Windows boot process is the foundation for reasoning about where trust is established, where security boundaries are drawn, and where attackers try to insert themselves before defenses load. This article walks the boot path end to end, from UEFI firmware to the Session Manager, and points out the security-relevant checkpoints along the way.

The Firmware Phase: UEFI and Secure Boot

On modern systems, power-on hands control to UEFI firmware rather than a legacy BIOS. The firmware performs hardware initialization (POST), enumerates devices, and then looks for a bootloader on an EFI System Partition (ESP) — a small FAT32 partition containing .efi executables. The default Windows boot manager lives at \EFI\Microsoft\Boot\bootmgfw.efi.

If Secure Boot is enabled, the firmware verifies the digital signature of every executable it loads against keys stored in firmware variables (the Platform Key, Key Exchange Keys, and the db/dbx signature databases). This is the first trust anchor in the chain: an unsigned or revoked bootloader is refused before a single instruction of it runs. Bootkits historically abused the gap between firmware and OS; Secure Boot exists to close it.

The Boot Manager and winload

bootmgfw.efi (the Windows Boot Manager) reads its configuration from the Boot Configuration Data (BCD) store, a registry-hive-format file on the ESP. The BCD describes the available boot entries — which OS loader to run, which kernel and HAL to use, and boot options such as test-signing or debug mode. You can inspect and edit it with bcdedit:

# List every boot entry and option in the BCD store
bcdedit /enum all

# Security-relevant flags worth checking on a suspicious host:
#   testsigning       -> allows unsigned/test-signed kernel drivers
#   nointegritychecks -> disables driver signature enforcement (DSE)
#   debug             -> kernel debugger attached
bcdedit /enum {current}

For the selected entry, the boot manager loads the OS loader, winload.efi. This is where the operating system proper begins to come to life. winload loads the kernel image (ntoskrnl.exe), the Hardware Abstraction Layer (hal.dll), the registry SYSTEM hive, and the set of boot-start drivers — the drivers marked SERVICE_BOOT_START that must be present before the kernel can initialize devices (disk, filesystem, and so on). Under Secure Boot, winload continues the signature-verification chain for each of these images.

Kernel Initialization

Once winload transfers control to ntoskrnl.exe, the kernel initializes in two broad phases. Phase 0 runs on the boot processor with interrupts largely disabled and sets up the most primitive structures: the memory manager’s initial page tables, the Object Manager root namespace, and the executive subsystems needed to bootstrap everything else. Phase 1 brings the system to life more fully — it starts the other processors, initializes the I/O manager (which loads and starts the remaining boot drivers), sets up the scheduler, and creates the first user-mode process.

A key security mechanism initialized here is Driver Signature Enforcement (DSE). On 64-bit Windows, kernel-mode drivers must be signed; the kernel refuses to load unsigned code into ring 0 unless test-signing mode is on or DSE has been tampered with. Early Launch Anti-Malware (ELAM) also runs at this stage: a specially registered anti-malware driver is loaded early enough to evaluate other boot drivers and veto known-bad ones before they initialize.

The First User-Mode Process: Session Manager

The kernel creates the Session Manager Subsystem, smss.exe, as the first user-mode process (traditionally PID 4 is the System process; smss.exe is the first “real” image started from disk). smss.exe is responsible for setting up the user-mode environment:

  • Creating the paging files and initializing the remaining registry hives.
  • Running autochk to check filesystems before they are mounted for normal use.
  • Starting the Client/Server Runtime Subsystem (csrss.exe) for each session.
  • Launching wininit.exe in session 0 (services) and winlogon.exe in interactive sessions.

wininit.exe then starts the Service Control Manager (services.exe), the Local Security Authority (lsass.exe), and the Local Session Manager. winlogon.exe drives the interactive logon experience, coordinating with LSASS and the credential providers to authenticate the user. From here the familiar desktop is only a few steps away.

Following the Chain in WinDbg

The boot process is not just theory — you can observe its artifacts on a live system. In a kernel debugger, the loaded module list and the boot driver set are directly inspectable:

# In WinDbg (kernel mode): list loaded kernel modules
lm k

# Inspect the kernel image and its version
!lmi nt

# View the process list; note smss.exe, csrss.exe, wininit.exe, lsass.exe
!process 0 0

On a running system without a debugger, Autoruns from Sysinternals shows boot-start drivers and early-launch entries, and bcdedit reveals whether integrity checks or test-signing have been weakened — a common tell when someone is trying to load an unsigned driver.

Why This Matters for Security

The boot path is a chain of trust: firmware verifies the boot manager, which verifies the loader, which verifies the kernel and its drivers, which enforce signing on everything that follows. Attackers who want persistence below the OS (bootkits) or who want to load malicious kernel code must break a link in this chain — by disabling Secure Boot, abusing a vulnerable signed driver (a “bring your own vulnerable driver” attack), or convincing an administrator to enable test-signing. Defenders, in turn, rely on Measured Boot and the TPM to record each stage’s hashes into Platform Configuration Registers, so that remote attestation can later prove the machine booted a known-good chain.

Conclusion

From UEFI firmware through the boot manager, winload, kernel initialization, and finally the Session Manager, the Windows boot process is a carefully ordered handoff where each stage validates the next. Knowing the order — and the security checkpoints embedded in it — gives you a mental map for everything that follows in this series, from how processes and memory are structured to how the kernel enforces its security model. In the next articles we will zoom into the objects the kernel builds once it is running, starting with the process itself.

You Might Also Like

This article is part of the Windows Internals series. These related deep-dives cover adjacent parts of the system:

Comments

Copied title and URL