Section 6: Windows Bootloader

The Big Picture: Carrying the Kernel into the Building

The boot manager has chosen Windows. Now the Windows OS Loader takes over. It is called winload.efi on UEFI PCs and winload.exe on legacy BIOS PCs. Its job is to prepare everything the kernel needs in order to wake up, and then hand over the keys.

An analogy: the kernel is a surgeon who is about to operate. The loader is the nurse who sets out the instruments and the patient, before the surgeon walks in. If something is missing, the surgeon cannot start.

At this point the loader works with no help from Windows (Windows is not running yet). It has just two tools: the firmware's simple disk reading, and its own code.

6.1 Winload.exe Role

What it is: The OS loader does a fixed list of jobs. In plain order:

1. Read the settings for this Windows from the BCD (Section 5.3), such as Safe Mode or debug options.
2. Check security. With Secure Boot on, it verifies the digital signatures of the kernel and boot drivers. (A part of Windows called Code Integrity does the checking.)
3. Load the kernel (ntoskrnl.exe) and the HAL (Hardware Abstraction Layer, hal.dll) into RAM. (Section 6.5.)
4. Load the SYSTEM registry hive (Section 6.3).
5. Load the boot-start drivers (Section 6.2).
6. Prepare memory: build the first page tables, turn on paging, and make a map of the memory for the kernel.
7. Package the results into one data block, the Loader Parameter Block. It lists everything the loader did and found.
8. Jump to the kernel's entry point and pass it that block. On UEFI, it first calls ExitBootServices (Section 5.5).

  winload                                ntoskrnl.exe
┌────────────────────┐   Loader      ┌─────────────────────┐
│ loads kernel, HAL, │   Parameter   │ starts up, reads    │
│ SYSTEM hive, boot  │ ────────────► │ the block, builds   │
│ drivers            │   Block       │ the rest of Windows │
└────────────────────┘               └─────────────────────┘

The first thing users see: While winload works, you usually see the maker's logo, then the Windows logo with the spinning dots. On many PCs, the logo stays on screen from here until the sign-in page.

BitLocker and TPM. If the disk is encrypted, the key was already released in Section 5.2. The loader also records measurements (fingerprints of the boot files) in the TPM chip. This is measured boot. It lets Windows check later that the boot chain was not tampered with.

6.2 Driver Loading (Critical Drivers)

What it is: A driver is a program that lets Windows talk to one kind of hardware (see Chapter 4). Some drivers are needed right at the start, because without them Windows cannot even read its own disk.

Think: Windows needs to read files from the disk. To read the disk, it needs the disk driver. But the disk driver is itself a file on the disk! So the loader must load that driver into RAM first, using the firmware's simple disk reading. These early drivers are called boot-start drivers.

Each driver has a Start type number in the registry:

So the loader handles only Start = 0: the critical drivers. Examples:

• The file system driver (ntfs.sys) so that NTFS can be read.
• The storage drivers: NVMe, SATA/AHCI, and RAID (for example stornvme.sys, storahci.sys).
• The volume and partition manager drivers.
• A small early-launch anti-malware (ELAM) driver. This is a special security driver. It loads first, so that it can judge all the other boot drivers and block any it thinks are malicious.
• Basic input, display and clock support.

Every boot driver must be digitally signed. If a driver is unsigned or damaged, the boot stops. That is why a faulty storage driver gives the blue screen INACCESSIBLE_BOOT_DEVICE (Section 11).

Windows tip: In Safe Mode, Windows loads only a small set of boot and system drivers. If a PC boots in Safe Mode but not normally, a faulty third-party driver is the prime suspect.

The loader loads drivers in a set order, using the groups listed in the registry. (Storage must come before the file system, for example.)

6.3 Registry Hive Mounting

What it is: The registry is Windows' big settings database. It is stored in several files, each called a hive (the name is a joke about beehives). Each hive is a tree of keys (like folders) and values (like files with data).

The loader needs to know which drivers to load and how. That information lives in the SYSTEM hive. So the loader opens it first. This is called mounting a hive: attaching a file so that it can be read as part of the registry tree.

Inside the SYSTEM hive, the important branch is ControlSet:

HKEY_LOCAL_MACHINE\SYSTEM
 ├─ ControlSet001     ← a full set of driver and service settings
 ├─ ControlSet002     ← often a "last known good" copy
 ├─ Select            ← says which control set is "Current" and which is "Default"
 └─ CurrentControlSet ← a shortcut that Windows creates at start-up

The loader reads the Select key to learn which ControlSet to use, then reads under it the Services key. Each driver has a key there with its Start number (Section 6.2), its file path and a Group.

See it: In the Registry Editor (regedit), look at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\. Pick a service and look at its Start value. Only look. Wrong edits here can stop Windows from starting.

At this stage, the loader has only the SYSTEM hive. The other hives come later (Section 7.6).

6.4 System Initialization

What it is: Before handing over to the kernel, the loader does the preparation of the machine itself. This is the "system initialization" part of the loader's work.

Step by step:

1. Memory map. The loader asks the firmware which pieces of RAM are usable and which are reserved. It builds its own copy of this map for the kernel.
2. Page tables and paging. It sets up the first page tables and turns on paging, so the kernel can use virtual addresses (Chapter 3). In 64-bit Windows, the kernel lives in the upper half of the address space, separate from user programs.
3. Kernel structures. It sets up the first descriptors the CPU needs for exceptions and interrupts, so the kernel can handle them from its very first instruction.
4. Processor features. It checks CPU features (such as hardware virtualization, NX "no-execute" protection and others) and records them. If Virtualization-Based Security or Hyper-V is on, the loader starts the small hypervisor first, and Windows then runs on top of it.
5. Hardware tables. It passes the ACPI tables and other hardware descriptions from the firmware on to the kernel.
6. Boot options. It copies settings such as Safe Mode, debug mode and the number of processors to use.
7. Display. It sets up a simple graphics screen (using the firmware's GOP, Section 3.4) so the Windows logo can be drawn.

All of this ends up in the Loader Parameter Block (Section 6.1), which is placed in RAM.

6.5 Kernel Loading

What it is: The kernel is a large program file: ntoskrnl.exe, in C:\Windows\System32. ("NT OS kernel": the NT in Windows NT.) The loader reads this file and copies it into RAM, together with the HAL.

Two files, one team:

Because the loader runs before Windows works, it cannot use Windows' normal tools. It handles the files itself: it reads them from disk, lays them out in memory as the file format requires, and fixes up the addresses inside them (this is called relocation), so the code works at the place where it landed in RAM.

Before running the kernel, the loader checks, with Code Integrity, that:

• The kernel and HAL files have a valid signature.
• Each boot driver is signed and passes the ELAM check.

Then the last step: the loader jumps to the kernel's entry point and gives it the Loader Parameter Block. The loader's work is over; it never runs again.

winload loads:                      Then it jumps to:
  ntoskrnl.exe   ─┐
  hal.dll         ├──► in RAM ────►  KiSystemStartup  (kernel entry)
  boot drivers    │                   with the Loader Parameter Block
  SYSTEM hive    ─┘

If this step fails, you may see the "Windows failed to start" screen (you will see a real one in Section 11). It names the file the loader could not use (here, winload.exe) and a status code. Section 11 explains how to repair such cases. For now, notice how plain the message is: it tells you the loader, not Windows, has stopped.

Next section: the kernel begins to run. This is where "Windows" really starts.

Summary