FAQ: Zo start Windows via UEFI

Nee. De UEFI-standaard bepaalt dat moederbordfabrikanten een Compatibility Support Module in de firmware kunnen inbouwen, kortweg CSM. Als die actief is, gedraagt de UEFI zich alsof het een Legacy-BIOS is, en verloopt het opstartproces heel anders.

Let op: of er een CSM in de firmware zit, beslist alleen de fabrikant. Dat geldt ook voor de vraag of er bij de firmware-instellingen een optie is om dit in- en uit te schakelen. De fabrikant kan zelfs bepalen dat de CSM automatisch geactiveerd wordt, bijvoorbeeld als noodoplossing wanneer de UEFI-bootmanager niet kan opstarten vanaf de ingebouwde of extern aangesloten schijven en niet via het netwerk.

Je kunt daar niets aan veranderen, dat kan hooguit de fabrikant met een firmware-update.

De Windows-bootmanager kan zich bevinden in bestanden met de naam bootx64.efi, die bij andere CPU-types en hardware-architecturen andere namen hebben. Maar over de architectuur van de UEFI-bootmanager gaat het nergens. Speelt die dan geen rol in het opstartproces tot het moment dat de Windows-bootmanager opgeroepen wordt?

Jawel. Het begint al met de UEFI-firmware van het moederbord. Ook die heeft een architectuur, en wel dezelfde als de processor – anders zou er niets werken. Op een ARM-apparaat heb je dus ARM-firmware, op een 64-bit x86-pc juist een 64-bit x64-UEFI. Er zijn ook 32-bit UEFI-varianten, maar die zijn zeldzaam. Zelfs Itanium hoorde daar vroeger bij, maar daar praten Microsoft en Intel tegenwoordig niet meer zo graag over.

Alle bestanden die de UEFI-bootmanager moet laden, moeten dezelfde architectuur hebben als de firmware. Bij bootx64.efi, bootaa64.efi en dergelijke kun je dat aan de bestandsnaam herkennen, maar ook bootmgfw.efi en dergelijke zijn er in overeenkomstige varianten.

Belangrijk: alles, van de firmware tot het besturingssysteem, moet dezelfde architectuur hebben. Je kunt dat bij een draaiende Windows uitlezen met het systeeminformatieprogramma msinfo32.exe. Het staat op de regel Systeemtype.

Overigens is het anders als de moederbordfirmware een Legacy-BIOS is of als de UEFI-firmware zo’n BIOS emuleert met een CSM. Legacy-BIOS en CSM starten in de 16-bit Real Mode en geven het stokje door aan een MBR-bootloader.

Welke besturingssystemen er kunnen draaien, wordt bepaald door de processor: oudere x86-CPU’s konden alleen 16- en 32-bit besturingssystemen uitvoeren. Moderne x86-CPU’s hebben een 64-bit uitbreiding, waardoor er ook 64-bit besturingssystemen draaien. Deze CPU’s heten x86-64 of, in Microsofts marketingtaal, x64.

Een blik bij de helpteksten van BCDedit laat zien dat het programma de optie /v kent?

Die v staat voor verbose (‘uitvoerig’), maar als je die optie gebruikt, toont BCDedit geen extra objecten en elementen, maar geeft aanvullende informatie over de bestaande. Het programma vervangt bekende GUID’s daarbij niet door hun aliassen.

Het commando BCDedit /enum Firmware toont de instellingen van de UEFI-bootmanager, inclusief de instellingen voor het firmware-opstartmenu. Maar de uitvoer bevat in het object {bootmgr} elementen zoals de volgorde voor het Windows-opstartmenu, die toch alleen interessant kunnen zijn voor de Windows-bootmanager, of niet?

Klopt. Achtergrond: tot de objecten die relevant zijn voor de UEFI-bootmanager behoort ook datgene waarin het gaat om het overdragen van de controle aan de Windows-bootmanager bootmgfw.efi. Dat object bestaat echter dubbel. In de UEFI-variabelen staat wat de UEFI-bootmanager moet weten over de Windows-bootmanager. In BCD-store, dus in het bestand dat bij de Windows-bootmanager hoort, staat hetzelfde (Windows houdt de waarden synchroon), maar aangevuld met andere elementen zoals de volgorde voor het Windows-opstartmenu.

Microsoft heeft besloten dat BCDedit het meer gedetailleerde object uit de BCD-store weergeeft – zelfs als je de uitvoer met de optie /enum Firmware beperkt tot wat relevant is voor de UEFI-bootmanager.

Wat BCDedit laat zien, zijn vertalingen van wat er in de UEFI-variabelen staat. Ik zou heel graag eens direct willen kijken wat daarin staat.

Dat kan, maar het zal je waarschijnlijk niet verder helpen. Als je het per se wilt: ex-Microsoft-medewerker Michael Niehaus heeft de PowerShell-module UEFIv2 in de PowerShell Gallery gepubliceerd. Om je een idee te geven van wat je kunt verwachten: na het installeren van de module kun je bijvoorbeeld met het commando Get-UEFIVariable -VariableName BootCurrent -AsByteArray controleren welke waarde de variabele BootCurrent heeft, die aangeeft welke UEFI-boot-entry heeft geleid tot het opstarten van het momenteel draaiende Windows.

De uitvoer bestaat uit twee regels die elk een waarde bevatten, bijvoorbeeld een 3 en een 0. Dat zijn twee bytes (Little Endian), in dit geval dus de 16-bit waarde 0x0003, wat weer verwijst naar de variabele Boot0003. Die kun je ook opvragen, maar dan krijg je niet slechts één reeks van twee bytes te zien, maar zeer veel.

Met andere woorden: als je niet al over grondige kennis van de UEFI-variabelen beschikt, helpt het uitlezen je niet.

Het element device noemt het station waarop een bootloader staat, en wel in het formaat zoals dat in de Device-map van de Windows-kernel staat. Betekent dit dat UEFI toegang heeft tot die map?

Nee, UEFI weet daar helemaal niets van. De waarde van het element device zit in werkelijkheid in een binair formaat in de UEFI-variabelen (of in een BCD-store). BCDedit vertaalt het alleen voor de uitvoer, zodat het leesbaar is voor mensen. Of de keuze voor dat formaat echt slim was, is een andere kwestie.

Bij elke Windows-bootmanager hoort een bestand dat de BCD-store bevat. Kan ik daarin kijken?

Op zich wel, maar dat is niet de juiste manier om het te lezen, want je kunt de inhoud bekijken met de Register-editor. Dat komt omdat een BCD-bestand technisch gezien een database is die hetzelfde formaat heeft als een registerbestand. Windows laadt de huidige BCD-store bij het opstarten in het register, waar je hem kunt vinden onder HKEY_LOCAL_MACHINE\BCD00000000 (het getal aan het eind kan variëren).

Verwacht echter niet te veel als je naar die sleutel en zijn subsleutels kijkt, het meeste staat daar uitsluitend in binaire vorm.

Als Windows de inhoud van het BCD-bestand in het register laadt, kan ik dat toch bijvoorbeeld ook doen met een rescue-Windows, of niet?

Op zich wel, maar we zeggen het heel duidelijk: doe dit in geen(!) geval(!), want anders start je Windows-installatie misschien niet meer op!

Het gevaar is dat de Register-editor van de rescue-Windows het bestand exclusief opent bij het laden van de BCD-store en dat markeert door een vlag in het bestand te zetten. Die vlag verdwijnt pas weer als je het bestand weer ontlaadt. Als je dat echter vergeet of als de rescue-Windows om wat voor reden dan ook eerder wordt afgesloten, beschouwt de Windows-bootmanager de BCD-store na het opnieuw opstarten van de pc dankzij de vlag als inconsistent. Gevolg: het opstartproces mislukt.

Een poging om de rescue-Windows dan nog een keer te starten om de store weer te ontladen, mislukt eveneens. Om voor elk gebruik een gegarandeerd schone omgeving te kunnen bieden, vergeet het rescuesysteem alle wijzigingen bij het afsluiten. Daarom weet de Register-editor dan niets meer van het laden van de BCD-store tijdens de eerdere sessie en biedt hij bijgevolg ook geen ontladen aan.

Wil je het toch absoluut proberen? Het is jouw beslissing, maar je weet het: geen back-up, geen medelijden.

(Axel Vahldiek en Noud van Kruysbergen)