Overzicht van partitionering van harde schijven onder Windows: FAQ

Daarnaast geldt: als bijvoorbeeld het volume met de bootloader beschadigd raakt, kun je het opnieuw instellen zonder dat je aan het volume met de Windows-installatie hoeft te sleutelen. Als er in plaats daarvan iets aan C: is, start RE in ieder geval nog op – mits het in een apart volume staat.

Een andere reden is de eigen schijfversleuteling van Windows, BitLocker – waarover zo meer. Alleen over de lege MSR-partitie (Microsoft Reserved), die de Windows-installatie normaal gesproken extra aanmaakt, zou je kunnen discussiëren, maar die is met amper 16 tot 128 MB de moeite van het verwijderen niet waard.

Als ik BitLocker activeer, wordt de hele schijf toch versleuteld – of niet?

Nee, dat zou niet gaan werken. Versleutelde gegevens zijn immers niet alleen beschermd tegen vreemden, maar ook tegen jou. Je moet ze dus eerst ontgrendelen voordat je ermee kunt werken.

En dat ontgrendelen moet door software gedaan worden. Die moet daarvoor echter onversleuteld zijn. Dat geldt ook voor Windows: het kan pas opstarten vanaf een met BitLocker beveiligde schijf C: als die ontgrendeld is. Het ontgrendelen wordt gedaan door de Windows-bootmanager, die daarvoor verplicht op een apart, niet-versleuteld volume moet staan.

Bij pc’s die via UEFI opstarten is dat de ESP, bij MBR-schijven is dat het kleine volume met de naam System Reserved. Ook de herstelpartitie is normaal gesproken niet versleuteld, zodat Windows RE nog steeds kan opstarten als er juist bij het ontgrendelen van C: iets misgaat.

Om de bootloader en RE altijd beschikbaar te houden, versleutelt BitLocker alleen met NTFS geformatteerde volumes die zich in partities van het type Basic Data bevinden (ID bij MBR: 0x07, bij GPT: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7).

Volgens ct-partinfo bevindt C: zich in een partitie van het type Basic Data, maar BitLocker weigert te versleutelen.

Dat kan gebeuren als Windows RE zich ook op C: bevindt – of dat nu komt door een verkeerde configuratie van RE, omdat de RE-partitie ontbreekt of …

Dan helpt het alleen om RE uit te schakelen of te repareren. De details kun je lezen in de twee hierboven genoemde artikelen. Het tweede artikel introduceert bovendien een apart script voor RE-analyse.

Herstelpartities hoeven niet door BitLocker versleuteld te worden. Die van mij is dat echter wel, en het script ct-partinfo laat zien dat het echt een partitie van het type Recovery is.

Hier zijn mogelijk twee dingen samengekomen. Ten eerste is de Apparaatversleuteling actief, die in alle Windows-edities aanwezig is (Home, Pro, Enterprise …). Die versleutelt automatisch, mits aan alle noodzakelijke voorwaarden is voldaan (meer daarover in [3]).

Ten tweede is de RE-partitie waarschijnlijk tussendoor opnieuw aangemaakt. Dat kan met Diskpart. Daarmee maak je in één keer een primaire partitie aan met de juiste herstel-ID. Als je dat in plaats daarvan in twee stappen doet (die fout hebben wij ook al gemaakt), ontstaat eerst de Basic-Data-partitie, die pas daarna via een wijziging van de type-ID wordt omgezet in een RE-partitie.

Het resultaat is niet te onderscheiden van het aanmaken in één stap, maar de korte tijd tussen de twee stappen is vaak al genoeg voor de Apparaatversleuteling om op de achtergrond en zonder te vragen te beginnen met het versleutelen van het nieuwe volume.

Er zitten vier schijven in mijn pc, maar het script geeft er maar drie weer.

We kennen maar weinig gevallen waarin dat gebeurt. Een hardware-RAID voegt bijvoorbeeld meerdere schijven samen tot een cluster, zodat Windows en daarmee het script het cluster alleen als één schijf herkennen.

Bij software-RAID hangt het ervan af. Het script herkent de eigen RAID’s van Windows en hun moderne opvolgers, de Storage Spaces. Bij andere oplossingen kunnen we echter niet voorspellen wat het script precies laat zien.

Als je geen RAID hebt, kan het ook zijn dat er een hardwareprobleem is (schijf of aansluiting defect, kabel zit niet goed vast …).

Bij mij zijn het niet te weinig, maar te veel schijven die het script weergeeft.

ct-partinfo toont niet alleen de fysieke schijven, maar ook virtuele schijven – voor zover het die herkent. Daaronder vallen bijvoorbeeld VHD(x)-bestanden die in Verkenner geïntegreerd zijn, maar ook schijfgroepen die als Storage Space zijn ingesteld.

Bij mij zijn bij station E: maar liefst twee schijven te zien. Hoe kan dat?

Dat is een RAID die met de standaardmiddelen gemaakt is. Je herkent dat doordat bij schijven 4 en 5 in de beschrijving aan het einde telkens Dynamisch (LDM) staat. Welk type RAID het is, kun je controleren in Schijfbeheer.

In dit geval is het een mirror, waarbij alle gegevens op E: tegelijkertijd op beide schijven opgeslagen worden. E: bestaat dus daadwerkelijk op beide schijven.

Dat dient ter bescherming tegen het uitvallen van een schijf: als dat gebeurt, heb je de gegevens nog op de andere. Maar let op: zo’n RAID beschermt echt alleen tegen het uitvallen van één schijf, en dan ook maar één. Als beide uitvallen, zijn de gegevens toch weg.

Maar je kent ongetwijfeld ons motto: geen back-up, geen medelijden.

Op een schijf zie ik een volume met een stationsletter en de grootte 0 KB (0 KB vrij).

Dat is vermoedelijk een met BitLocker beveiligd volume dat nog niet ontgrendeld is. Zodra je dat gedaan hebt (bijvoorbeeld door een pincode of wachtwoord in te voeren), verschijnt ook de juiste grootte.

Bij Windows is opstarten via UEFI alleen mogelijk vanaf een GPT-schijf, heb ik ervaren bij het installeren van Windows. Ik weet echter zeker dat ik ooit een computer heb gezien waarop Windows op een MBR-schijf stond en de pc toch via UEFI opstartte.

Dat hebben we ook al eens gezien, maar we zijn er nooit in geslaagd om een reproduceerbaar scenario na te bootsen.

Er is echter één uitzondering: wanneer er meerdere schijven in het apparaat zitten. De GPT-verplichting geldt namelijk uitsluitend voor de EFI System Partition (ESP), dus de partitie met de bootloader. Windows zelf (dus C:) mag daarentegen ook op een MBR-schijf staan.

Er is nog een andere uitzondering: externe opslagmedia. De UEFI-GPT-verplichting geldt namelijk alleen voor interne schijven. Externe schijven, zoals USB-sticks, mogen daarentegen ook in de Windows-wereld met MBR gepartitioneerd zijn. Opstarten via UEFI lukt dan toch. Er is zelfs geen ESP nodig: op externe schijven doorzoekt het UEFI-BIOS gewoon alle aanwezige FAT-volumes op zoek naar een geschikte bootloader.

Op een screenshot van het script staat een USB-stick met daarop een FAT-volume met de naam UEFI_NTFS. Dat vond ik wel vreemd, maar ik heb er verder niet bij stilgestaan. Maar nu heb ik ontdekt dat er op een van mijn USB-sticks ook zo’n volume staat.

Die stick is vermoedelijk ingesteld met de freeware Rufus (te downloaden op rufus.ie). Daarmee kun je bijvoorbeeld een ISO-image met de Windows-installatiebestanden doorgeven. Rufus zet de inhoud daarvan zodanig op de USB-stick dat de pc ervan opstart en je Windows kunt installeren.

Rufus kan een stick dan zodanig instellen dat hij uitsluitend via UEFI opstart, maar stuit daarbij op een probleem. Ter herinnering: via UEFI start de pc op vanaf een volume op de stick dat met FAT geformatteerd is. Bij Windows is dat meestal FAT32. Maar ook FAT12 en FAT16 zijn toegestaan.

Zelfs bij FAT32 kunnen echter alleen bestanden met een maximale grootte van 4 GB worden opgeslagen. Op veel Windows-ISO’s staat inmiddels echter een bestand dat groter is (Install.wim bevat het eigenlijke besturingssysteem).

Rufus gebruikt een opmerkelijke truc om het probleem op te lossen: het maakt een groot volume op de stick aan en formatteert dat met NTFS, want dan maakt de bestandsgrootte niet uit.

Daarnaast maakt het echter een klein FAT-volume aan met de naam UEFI_NTFS. Bij verwisselbare media zoals USB-sticks doorzoekt het UEFI-BIOS volgens de specificatie elk FAT-volume naar het bestand \EFI\BOOT\Bootx64.EFI (of de betreffende architectuurvariant). Dat bestand is, anders dan bij andere sticks, niet afkomstig van Microsoft, maar van Rufus. Het gaat echter zoals gewoonlijk om een UEFI-toepassing.

Het UEFI-BIOS start die, maar blijft op de achtergrond actief. De eigen UEFI-toepassing van Rufus laadt tijdens de uitvoering een NTFS-stuurprogramma, dat zich eveneens op het UEFI_NTFS-volume bevindt, zodat het UEFI-BIOS dan op de NTFS-partitie de eigenlijke Windows-bootloader \EFI\BOOT\Bootx64.EFI kan lezen en starten.

Klopt het dat Legacy-BIOS niets van GPT weet en alleen met MBR overweg kan?

Strikt genomen kent een Legacy-BIOS helemaal geen partitieschema, dus noch GPT noch MBR. Het kent alleen de eerste sector van de schijf, namelijk het Master Boot Record, waarin het naar de opstartcode zoekt.

Zo’n MBR vindt het ook op een GPT-schijf, maar dat is slechts een Protective MBR. Die bevat één enkele partitie-entry (type 0xEE) die de hele schijf bestrijkt. Op die manier herkent het BIOS dat de schijf bezet is, maar vindt het geen opstartcode waaraan het de controle kan overdragen. Die vindt het alleen op met MBR gepartitioneerde schijven.

Een andere reden voor de Protective MBR is trouwens dat hij moet voorkomen dat oude tools, die nog niets van GPT weten, de schijf als leeg beschouwen en hem zonder meer opnieuw inrichten. Daarbij zouden bestaande gegevens verloren kunnen gaan.

Axel Vahldiek en Noud van Kruysbergen

[1] Axel Vahldiek en Marco den Teuling, Windows RE en de herstelpartitie, c’t 11/2021, p.123
[2] Axel Vahldiek en Daniel Dupré, Windows-herstelomgeving RE repareren, c’t 11/2024, p. 112
[3] Axel Vahldiek en Jan Mulder, Windows Apparaatversleuteling, c’t 4/2025, p.140/2024, p.112

Verzameling links en bronnen bij dit artikel.