Understanding the Windows Boot Process: UEFI, Boot Manager, and Winload
How a modern Windows machine goes from firmware to a running kernel, and where each stage's configuration actually lives.
Modern Windows boots through a chain of distinct, individually-replaceable stages, similar in spirit to Linux’s firmware-to-kernel handoff but with its own vocabulary: the Windows Boot Manager, winload, and a configuration store called the BCD that replaced the old boot.ini file entirely starting with Vista.
Stage 1: UEFI firmware and Secure Boot
On UEFI systems (the default for any Windows 11 machine and most Windows 10 installs), firmware reads the EFI System Partition (ESP), a small FAT32 partition holding boot loaders, and executes \EFI\Microsoft\Boot\bootmgfw.efi. If Secure Boot is enabled, the firmware verifies this file’s signature against keys stored in firmware before executing it — the same signature-chain concept as Apple Silicon’s boot chain, applied to a PC.
Confirm-SecureBootUEFIStage 2: Windows Boot Manager
bootmgfw.efi is the Windows Boot Manager — its job is to read the BCD (Boot Configuration Data), present a boot menu if more than one OS entry exists, and hand off to the selected OS’s own loader.
bcdedit /enumThe BCD is itself a hive-formatted file (\EFI\Microsoft\Boot\BCD on the ESP), structured just like a registry hive — which is why bcdedit and bootmgr both understand it using registry-like semantics rather than a flat text config file.
bcdedit /set {current} description "Windows 11 Pro"
bcdedit /timeout 5Stage 3: winload and the kernel
The Boot Manager hands off to winload.efi, which loads the kernel (ntoskrnl.exe), the HAL (hardware abstraction layer), boot-critical drivers, and — critically — verifies driver signatures if the system enforces driver signature enforcement:
bcdedit /set {current} nointegritychecks offwinload also reads \Windows\System32\config\SYSTEM early enough to know which drivers are marked as boot-start, since some drivers (storage controllers, in particular) must load before the kernel can even access the volume the rest of Windows lives on.
Stage 4: the kernel takes over
Once ntoskrnl.exe has control, it initializes the executive subsystems (memory manager, object manager, I/O manager), starts the Session Manager (smss.exe), which in turn starts csrss.exe (the Client/Server Runtime, handling console windows and parts of the Win32 subsystem) and wininit.exe.
Stage 5: services and the logon screen
wininit.exe starts the Service Control Manager (services.exe), which begins starting services marked for automatic startup according to their own dependency graph — conceptually similar to rc.d’s REQUIRE/BEFORE ordering on FreeBSD, or systemd’s unit dependencies on Linux, just expressed through the SCM’s own dependency list per service rather than a declarative file.
Get-Service | Where-Object {$_.StartType -eq "Automatic" -and $_.Status -ne "Running"}In parallel, winlogon.exe starts and presents the logon screen once the system reaches a point where user interaction is possible, without necessarily waiting for every automatic service to finish starting.
Booting into recovery
Interrupting a normal boot (three failed boots in a row, or a deliberate interrupt) drops into the Windows Recovery Environment (WinRE), a minimal separate Windows PE-based environment used for System Restore, bootrec, and Startup Repair — conceptually the same role as FreeBSD’s single-user mode or a Linux initramfs rescue shell, just packaged as a full separate mini-OS image rather than a stripped-down mode of the same kernel.
bcdedit /enum {bootmgr}
reagentc /infoELAM: catching malicious drivers before anything else can scan them
Measured Boot (below) records what ran; Early Launch Anti-Malware (ELAM) is the mechanism that can actually stop a malicious boot-start driver from running in the first place. Microsoft Defender’s own ELAM driver (Wdboot.sys) is specifically loaded before any other boot-start driver, letting it classify every other boot-start driver as good, bad, or unknown before the loader lets them run at all — a driver ELAM flags as bad is prevented from loading entirely, closing off exactly the “malicious driver loads before any antimalware software is running to catch it” window that made boot-time rootkits historically difficult to defend against. Third-party antimalware vendors can ship their own ELAM driver too, provided it’s signed with a special Microsoft-issued certificate specifically for this early-boot role, rather than an ordinary code-signing certificate being sufficient.
Fast Startup: why a “shutdown” often isn’t a full boot next time
What looks like a fresh cold boot on modern Windows frequently isn’t one at all. Fast Startup (also called Hiberboot, enabled by default on most Windows 10/11 installs) turns the default shutdown action into a hybrid shutdown: Windows logs off every user and closes every application exactly like a normal shutdown would, but instead of also tearing down the kernel session, it hibernates just that remaining kernel-and-drivers state — writing it to hiberfil.sys — and powers off from there. The next “boot” then skips a substantial part of the stages described above: rather than the kernel and boot-start drivers initializing from scratch, winload resumes the previously-hibernated kernel image directly from hiberfil.sys, which is where most of Fast Startup’s actual speed gain comes from.
powercfg /a
powercfg /h offThis is also the root cause of a specific, recurring category of dual-boot and driver-update confusion: because the kernel session genuinely persists across what looks like a shutdown, a Linux installation sharing the same disk can find the Windows-managed filesystem still marked as “in use” from Windows’s perspective, and a driver or firmware change that needs a truly cold boot to take effect may not fully re-initialize if Windows just resumes its old kernel state instead of actually reinitializing from power-on. Restart (as opposed to Shut down) always performs a full, non-hibernated boot regardless of the Fast Startup setting, which is why “restart, don’t shut down” is the standard troubleshooting advice whenever a change genuinely needs the full boot chain to run again from Stage 1.
Measured boot: extending the trust chain into attestation
Secure Boot (Stage 1) stops unsigned or tampered boot components from executing, but it doesn’t, by itself, produce a record other systems can later check. Measured boot adds that: as each stage of the chain above executes — firmware, Boot Manager, winload, boot-critical drivers — it extends cryptographic hash measurements of what actually ran into the system’s TPM (Trusted Platform Module), building up a tamper-evident log across a set of PCRs (Platform Configuration Registers) that can’t be rewritten, only extended forward.
Get-Tpm
Confirm-SecureBootUEFIWhere Secure Boot answers “was everything that ran properly signed,” measured boot answers a related but distinct question later, potentially from a remote system: “can I prove exactly what actually booted on this machine.” This is what lets BitLocker unlock a drive automatically only when the measured boot state matches what was recorded when the drive was first protected — if measurements change unexpectedly (a boot component was tampered with, or the disk was moved to different firmware), BitLocker’s TPM-bound unlock refuses to release the key automatically, falling back to a recovery key prompt instead. Remote attestation services (Device Health Attestation being Microsoft’s own) can similarly query a machine’s measured boot log to confirm it booted a genuinely untampered chain before granting it access to sensitive resources, extending the trust chain from “this machine booted correctly” all the way out to a network policy decision.
Diagnosing a boot failure by stage
Just like the FreeBSD and Linux boot chains, knowing which stage failed narrows the fix immediately: a black screen before any Windows logo suggests a firmware/Secure Boot/BCD problem (bcdedit /enum from WinRE is the first move); a Windows logo that hangs or blue-screens suggests a boot-critical driver problem (safe mode, or checking Get-WinEvent for the last boot’s kernel-logged errors); a system that reaches a black screen with a cursor but no logon suggests a winlogon/shell-level failure rather than anything upstream. Because each of these stages is logged and independently inspectable — bcdedit, the boot log (bootcfg or msconfig’s boot logging option), and Event Viewer’s System log — a methodical “which stage got furthest” approach works exactly as well here as it does on any other operating system’s boot chain.
Related:
Sources: