Boot loader to kernel handoff

Startup & shutdown named this as the second stage of boot. This chapter is that specific handoff in detail: how Windows goes from "firmware has picked an OS to start" to "the kernel is genuinely running."

Boot Configuration Data: choosing what to start

Before any kernel-loading work begins, Windows has to know which OS installation, and with what parameters, to actually start — information stored in BCD (Boot Configuration Data), the modern replacement for the older boot.ini-based configuration. BCD is what makes multiple boot entries possible (different OS installations, or the same installation with different debugging or safe-mode parameters) — selecting a different entry changes which kernel image, which boot-critical drivers, and which startup parameters the next stage actually prepares.

Winload: preparing the runway before the kernel lands

Once BCD identifies the target, Winload (the Windows OS loader) takes over: it loads the kernel image itself (Ntoskrnl.exe) and the HAL, along with every driver marked as boot-start — drivers the kernel will need available from the very earliest moments of its own initialization, before the ordinary, dynamic driver-loading machinery (Plug and Play & power) is anywhere close to operational. Winload also sets up the earliest memory structures the kernel will expect to find already in place the moment it begins running.

This is worth picturing precisely as "preparing a runway": Winload doesn't run the kernel's own initialization logic — it does the preparatory work that makes it possible for the kernel to safely begin that initialization the moment control is transferred to it.

Why boot manager and OS loader are genuinely separate stages

It's easy to lump "boot manager" and "OS loader" together as one vague "the thing before Windows starts," but they have meaningfully distinct responsibilities: the boot manager is about choosing — reading BCD, presenting a boot menu if multiple entries exist, deciding which OS to start. Winload is about preparing — once a choice has been made, actually getting that specific kernel image and its boot-critical dependencies ready to run. Confusing the two obscures where a given boot problem actually originates: a corrupted BCD store produces a different class of symptom (missing or wrong boot entries) than a Winload-stage failure (a specific boot-critical driver failing to load).

A worked example: why a boot-critical driver failure appears so early

A boot-start driver — a storage controller driver needed to even read the volume containing the rest of Windows, for instance — that's corrupted, incompatible, or blocked (by Secure Boot, if unsigned) fails at exactly this Winload stage, before the kernel has even begun its own initialization. This produces failures that look and feel categorically different from a driver problem discovered later, after Windows is fully running: often a specific stop-code screen referencing the boot process itself, rather than the ordinary bugcheck screen a runtime driver failure would produce, precisely because so little of the normal diagnostic and recovery infrastructure exists yet at this stage.

A common mistake

Assuming every driver-related boot problem is equivalent, regardless of when in the sequence it manifests, misses a genuinely useful diagnostic distinction: a driver failing to load at the Winload stage (boot-critical, needed before the kernel even starts properly) is a fundamentally different, generally more severe class of problem than a driver failing later, during ordinary Plug and Play enumeration — the former can prevent the machine from starting at all; the latter typically just means one specific device doesn't work correctly, while the rest of Windows runs normally.

Where this connects

• HAL & boot covers the component Winload prepares alongside the kernel image itself.
• Secure Boot & measured boot covers the trust verification that gates exactly which boot loader and boot-critical drivers are even allowed to run at this stage.