Zo start Windows via UEFI: de techniek achter het opstarten

Een van de eerste taken van een UEFI is om de processor in een gedefinieerde starttoestand te brengen. Optioneel wordt de integriteit van de firmware gecontroleerd om er zeker van te zijn dat die niet gewijzigd is, bijvoorbeeld door malware.

Als Root of Trust (basis van vertrouwen) dient een onveranderlijke hardwarecomponent, zoals een TPM of een mechanisme in de processor, zoals Intels Boot Guard. Als de verificatie succesvol was, dient de firmware als betrouwbare basis voor het verdere opstartproces, dus voor Secure Boot.

Vervolgens wordt het werkgeheugen geïnitialiseerd. Daarnaast laadt de UEFI enkele stuurprogramma’s voor grafische kaart, netwerk, USB-controller enzovoort, waarvan de functionaliteit echter tot het hoogstnodige beperkt is.

Dan komt de UEFI-bootmanager in actie, die een integraal onderdeel van de UEFI is. Zijn taak bestaat in wezen uit het laden van een besturingssysteem-bootmanager en het overdragen van de controle daaraan.

De UEFI-bootmanager vindt de benodigde informatie in de UEFI-bootvariabelen in een niet-vluchtig geheugen op het moederbord (NVRAM of flash). De informatie die daarin is opgeslagen, bepaalt onder andere de opstartvolgorde van de schijven. Als er via PXE/TFTP vanaf het netwerk moet worden opgestart, staat dat daar ook vermeld. De opstartvolgorde is dezelfde als die je ook in de UEFI-set-up kunt zien. Als het opstarten vanaf een schijf mislukt, probeert de UEFI-bootmanager het met de volgende in de lijst.

Andere UEFI-bootvariabelen bevatten de informatie waar precies op een schijf de bootmanager moet worden gezocht. Informatie over Secure Boot (status, certificaten) staat daar ook. Het besturingssysteem kan uit de variabelen een aantal dingen aflezen, zoals de systeemtaal en of de UEFI over bepaalde mogelijkheden beschikt.

Zo komt Windows daar te weten of het een herstart naar de UEFI-set-up mag aanbieden of firmware-updates mag installeren, en of de UEFI direct een herstelomgeving kan starten.

Je kunt de UEFI-variabelen uitlezen met de eigen Windows-commandlinetool BCDedit.exe. De eerste drie letters van die naam staan voor Boot Configuration Data.

De BCD is het geheel van informatie dat nodig is om het besturingssysteem op te starten. Die informatie zit niet alleen in de UEFI-variabelen, maar ook in speciale bestanden. Zo’n bestand (een BCD-Store) staat de Windows-bootmanager bij.

Voordat je meteen aan de slag gaat met BCDedit.exe, is een waarschuwing op zijn plaats. Het programma dient niet alleen voor analyse, maar kan ook de opstartconfiguratie van een pc wijzigen. Onzorgvuldige wijzigingen kunnen er in het ergste geval toe leiden dat Windows niet meer opstart.

Je kunt eventuele wijzigingen wel met een rescue-Windows ongedaan maken, maar er is geen Undo-functie. Je moet dus zelf tot in detail uitzoeken wat precies naar welke instelling teruggezet moet worden. Kortom: wees extra oplettend bij het gebruik van BCDedit!

Wat relevant is voor de UEFI-opstartmanager, kun je met één enkel commando uitlezen. Dat is onschadelijk omdat het alleen leest, maar niets wijzigt. Druk eerst op Windows+X en kies, afhankelijk van wat er beschikbaar is, Terminal, PowerShell of Opdrachtprompt. Let er echter op dat je telkens de optie selecteert met de toevoeging Als administrator uitvoeren.

Voer het volgende commando uit:

BCDedit /enum Firmware

De uitvoer ziet er ingewikkelder uit dan hij is. Grofweg is hij onderverdeeld in verschillende blokken, die Microsoft BCD-objecten noemt. Het bovenste object heeft de kop Firmware Boot Manager en bepaalt de volgorde waarin de volgende objecten weergegeven worden.

Alle objecten onder het bovenste bevatten elk de informatie over waar de UEFI-bootmanager welke Windows-bootmanager moet laden.

De UEFI identificeert de blokken niet aan de hand van de titels, want die kent hij helemaal niet, maar aan de hand van unieke identificatiecodes, de identifier.

Er zijn twee soorten van die ID’s: de ene geldt alleen op deze pc, die lijken vaak zo op elkaar dat ze maar op één positie verschillen.

De Firmware Boot Manager toont in displayorder de opstartvolgorde, vergelijkbaar met de instelling bij de UEFI-instellingen. Daaronder volgen de afzonderlijke firmwaretoepassingen zoals netwerk- en SCSI-boot.

De andere ID’s zijn GUID’s (Globally Unique Identifier), die op alle computers hetzelfde zijn. Daarvoor heeft Microsoft in veel gevallen een alias gedefinieerd, dat BCDedit vervolgens in plaats van de GUID weergeeft, bijvoorbeeld {fwbootmgr}, {bootmgr} en {current}.

Het bovenste object met de alias {fwbootmgr} bepaalt de opstartvolgorde. Het bevat meerdere BCD-elementen, die je kunt zien als variabelen die een of meerdere waarden bevatten. In dit geval heten de elementen displayorder en timeout.

Het element displayorder bevat een lijst met andere ID’s en aliassen. De UEFI-bootmanager doorloopt die lijst van boven naar beneden. Hij pakt de eerste ID (of de bijbehorende alias), gaat naar het object met diezelfde ID en probeert daar de Windows-bootmanager te laden zoals aangegeven.

Als dat niet lukt, probeert de UEFI-bootmanager het met de volgende ID op de displayorder-lijst.

Het andere element timeout staat voor een wachttijd. Er is UEFI-firmware die een ingebouwd opstartmenu heeft. Terwijl displayorder dan de volgorde in het menu aangeeft, staat de waarde achter timeout voor het aantal seconden dat de UEFI wacht op een gebruikersinvoer voordat hij automatisch verdergaat met het eerste item onder displayorder.

In de meeste gevallen moet op een Windows-pc natuurlijk Windows opgestart worden, om precies te zijn: een Windows-versie die op een interne schijf geïnstalleerd is. De benodigde informatie over de bijbehorende Windows-bootmanager vindt de UEFI-bootmanager in het BCD-object met de alias {bootmgr}.

Ook dat object bevat weer elementen. Een daarvan heet device. Dat is het logische station waarop de Windows-bootmanager staat. De specificatie gebeurt daar echter niet in het formaat dat de eigen Windows-partitieprogramma’s Schijfbeheer en zijn commandline-tegenhanger Diskpart gebruiken – inleidingen daarover in [1, 2].

Het formaat is in plaats daarvan dat van een NT Device Path, zoals de Windows-kernel dat intern gebruikt. Als device kan daar bijvoorbeeld iets staan als partition=\Device\HarddiskVolume1. Het voorvoegsel partition= geeft aan dat de bootloader in een partitie te vinden is. \Device\ is de map van de Windows-kernel voor alles wat hij via een stuurprogramma aanspreekt. HarddiskVolume1 is een vermelding in die map en staat voor een logisch station (Volume) – in dit geval dus dat met de Windows-bootmanager.

In de praktijk verwijst het element device in het object {bootmgr} naar de EFI System Partition, afgekort ESP. Dat is een speciale partitie die meestal kleiner is dan 1 GB. Daarin is een met FAT32 geformatteerd logisch station (volume) aangemaakt. Daarop staat de Windows-bootmanager in de vorm van een bestand. Omdat Windows standaard geen stationsletter toewijst aan de ESP, is die niet te zien in Verkenner.

Voor meer informatie over de details van ESP en dergelijke zie [3]. Dat artikel introduceert ook het script ct-partinfo, dat de partitie-indeling van schijven gedetailleerder weergeeft dan Schijfbeheer of Diskpart dat kunnen.

Een ander element in het object {bootmgr} heet path. Het bevat het pad en de naam van de Windows-bootmanager. Voorbeeld: \EFI\Microsoft\Boot\bootmgfw.efi.

Dat pad begint niet zoals gebruikelijk met een station, want dat wordt al door het element device aangegeven. De namen van de mappen zijn op alle computers hetzelfde. \EFI is voorgeschreven door de UEFI-specificatie.

Daarna volgt een map met een fabrikantspecifieke naam. Bij Windows heet die \Microsoft. Microsoft heeft besloten om de extra submap \Boot te gebruiken. De bestandsnaam is bootmgfw.efi. Dat is een afkorting van bootmanager en firmware. In dat bestand zit dus die Windows-eigen bootmanager die bedoeld is om door de UEFI-firmware van het moederbord te worden opgeroepen (in tegenstelling tot bootmgr, de Legacy-BIOS-variant).

De extensie .efi geeft aan dat het om een EFI-toepassing gaat die de UEFI kan laden en uitvoeren, terwijl hij zelf op de achtergrond actief blijft.

Tot de overige elementen van het object {bootmgr} behoren bijvoorbeeld de door Microsoft afkomstige beschrijving (description) en de taalinstelling (locale).

Andere objecten dan {bootmgr} komen aan bod wanneer ze in de displayorder boven {fwbootmgr} staan of wanneer het opstarten van de Windows-bootmanager mislukt. Je kunt meestal aan de description zien waarvandaan de UEFI-bootmanager vervolgens de volgende opstartpoging doet, bijvoorbeeld EFI Network of UEFI: Network Device (dus via het netwerk) of EFI Device of UEFI: Removable Device (USB-opslag, optische media …). De benamingen kunnen variëren.

Als je in die andere objecten behalve de ID en de beschrijving geen elementen zoals device en Path ziet, komt dat doordat daar sowieso altijd hetzelfde gebeurt: de UEFI-bootmanager probeert altijd het bestand \EFI\BOOT\ BOOTX64.efi te starten. Dat is ook een besturingssysteem-bootmanager. Op computers zonder extra geïnstalleerd Linux zijn Bootmgfw.efi en Bootx64.efi meestal zelfs identiek.

De naam van het bestand hangt af van het CPU-type. Bij ARM64-pc’s heet dat bestand bijvoorbeeld niet Bootx64.efi, maar Bootaa64.efi.

Als de UEFI-bootmanager de lijst in displayorder heeft afgewerkt en niets daarvan werkte, geeft de UEFI meestal een melding als No bootable device found weer.

Als de UEFI-bootmanager de controle succesvol kan overdragen aan de Windows-bootmanager Bootmgfw.efi, komen verdere BCD-instellingen in het spel. Dat laat een ander commando zien:

BCDedit /enum

Ook dat laat weer objecten zien, en het basisconcept ken je inmiddels: het bovenste object draagt hier de titel Windows Boot Manager en de alias {bootmgr}. Dat is geen toeval, maar komt simpelweg doordat het hetzelfde object is dat je ook bij bcdedit /enum firmware te zien kreeg.

Het object {bootmgr} bevat ook een element displayorder en dat bepaalt weer een volgorde (en timeout bepaalt ook hier de wachttijd). Maar in dit geval gaat het erom welke van de aanwezige Windows-installaties de Windows-bootmanager moet starten.

Als er maar één bestaat, bevat displayorder slechts één vermelding met de naam {current}.

Of {current} ook echt wordt gebruikt, wordt bepaald door een ander element: resumeobject. Daarin staat weer een ID, en de naam van het element doet het al vermoeden: het gaat hier om het ontwaken uit de slaapstand.

Ter herinnering: wanneer Windows in de slaapstand gaat, slaat het de inhoud van het werkgeheugen op in het bestand C:\hiberfil.sys en schakelt de pc vervolgens uit. Je kunt de pc daarna van de stroom halen.

Wanneer je de pc weer inschakelt, gaat de Windows-bootmanager op zoek naar het bestand hiberfil.sys. Als hij het vindt en het intact acht, laat hij Windows weer ontwaken. Daarvoor wordt WinResume.efi geladen in plaats van Winload.efi. Andere Windows-installaties worden in dat geval genegeerd.

Let op: de slaapstand en ‘Energie besparen’ zijn onder Windows niet hetzelfde. Bij dat laatste schakelt Windows vrijwel alle hardware uit die tijdelijk niet nodig is en slaat het de systeemstatus op in het werkgeheugen. Dat kost weliswaar wat energie, maar als je de pc weer uit de slaapstand haalt, activeert het systeem de hardware slechts kort en is het weer klaar voor gebruik.

De eerste vermelding onder displayorder gebruikt de Windows-bootmanager alleen als Windows eerder volledig afgesloten is, als je Windows opnieuw opstart (bijvoorbeeld door op de gelijknamige knop in het Startmenu te klikken) of als hiberfil.sys ontbreekt of defect is.

Voor de volledigheid even kort iets over de elementen die nog niet zijn toegelicht. inherit zijn de overgenomen instellingen van de Windows-bootmanager, dat zijn meestal de algemene instellingen. Daar gaat het echter om dingen die normaal gesproken niet interessant zijn (EMS- en debugger-instellingen, wat te doen bij RAM-defecten …).

Mocht je toch eens willen kijken, dan kan dat met BCDedit /Enum Inherit.

toolsdisplayorder bevat meestal alleen een oproep voor de geheugendiagnose, daar kunnen pc-fabrikanten ook eigen tools verankeren, bijvoorbeeld voor systeemherstel.

Als de Windows-bootmanager Windows moet starten, moet hij de controle overdragen aan de Windows-loader. In de uitvoer van BCDedit /enum zijn de details daarvan te zien bij het object {current}. Wat de elementen device en path betekenen, weet je al.

Hier vertaalt BCDedit de informatie handig direct naar stationsletters zoals C:. De Windows-loader zit in het bestand \WINDOWS\system32\winload.efi. Om ervoor te zorgen dat Winload.efi weet waar Windows zich bevindt, bevat het element osdevice het station (ook C:) en systemroot de naam van de Windows-map.

Als het oproepen van Winload.efi mislukt, gaat het verder in het object {current} met het element recoverysequence: het object waarvan de ID daar wordt genoemd, zie je op dat moment niet, maar daarin zit de oproep naar de eigen herstelomgeving van Windows (Recovery Environment, RE) verborgen.

Als bij recoveryenabled een Yes staat, probeert RE het probleem automatisch te repareren.

RE kan in plaats van via de bootmanager ook via de Windows-loader Winload.efi gestart worden. Dat gebeurt echter alleen in uitzonderlijke gevallen, bijvoorbeeld als het verdere opstartproces herhaaldelijk mislukt. of wanneer je RE zelf oproept door tijdens het draaien van Windows in het startmenu op Opnieuw opstarten te klikken en daarbij de Shift-toets ingedrukt te houden.

Het element isolatedcontext bepaalt of de Windows-loader in een geïsoleerd geheugengebied moet worden geladen. Dat dient ter bescherming tegen manipulatie en is bijvoorbeeld relevant voor Secure Boot.

Het element allowedinmemorysettings bepaalt welke BCD-instellingen tijdens het draaien in het werkgeheugen mogen worden gewijzigd. De hexadecimale waarde 0x15000075 die BCDedit meestal weergeeft, is echter niet gedocumenteerd.

Het element nx bepaalt of en zo ja hoe Data Execution Prevention (DEP) actief is. De waarden AlwaysOn en AlwaysOff spreken voor zich. OptIn activeert DEP alleen voor programma’s die erom vragen, OptOut voor alle programma’s behalve expliciete uitzonderingen.

bootmenupolicy bepaalt ten slotte hoe een eventueel weergegeven opstartmenu eruitziet (Standard: tegelweergave, Legacy: zoals bij Legacy BIOS).

Afhankelijk van de Windows-configuratie kunnen er nog andere elementen zijn, zoals hypervisorlaunchtype. auto laadt de hypervisor tijdens het opstarten.

Winload.efi doet uiteindelijk de rest. Daar hoort het laden bij van de system-tak van het register, de Windows-kernel (ntoskrnl.exe), de Hardware Abstraction Layer (hal.dll), de Code Integrity Module (ci.dll), diverse stuurprogramma’s en nog wat meer. Daarna neemt de kernel het over en zie je eindelijk het logo van de fabrikant. Vervolgens start Windows op.

Je kunt met BCDedit nog meer informatie loskrijgen. Zo toont BCDedit /enum all in één keer alle vermeldingen van UEFI- en Windows-bootmanagers, wat echter al snel meerdere schermpagina’s vult. Wat BCDedit nog meer kan, krijg je te zien met BCDedit /?, maar laat het ter afsluiting nog eens gezegd zijn: gebruik het programma voorzichtig, want fouten kunnen ertoe leiden dat Windows niet meer opstart. En dat repareren is niet meteen eenvoudig. Je hebt nu immers een idee van hoe complex de configuratie van bootmanagers en Windows-loaders is.

Axel Vahldiek en Noud van Kruysbergen

­[1] Axel Vahldiek en Noud van Kruysbergen, Partitioneren met programma’s van Windows – deel 1: Schijfbeheer, c’t 5/2018, p.104

[2] Axel Vahldiek en Noud van Kruysbergen, Partitioneren met programma’s van Windows – deel 2: DiskPart, c’t 5/2018, p.108

[3] Axel Vahldiek en Noud van Kruysbergen, Partitionering in kaart gebracht, c’t 7/2026, p.84