Opmerking
- Oorspronkelijke publicatiedatum: 19 maart 2026
- KB-id: 5085046
In dit artikel
- Overzicht
- Hoe een Secure Boot-certificaatonderhoud werkt
- Waar moet je beginnen bij het oplossen van problemen?
- Geplande taak voor Secure-Boot-Update
- Waarom een geplande taak wordt gebruikt
- Het registerbitmasker AvailableUpdates
- Integratie met OEM-firmware
- Algemene foutscenario's en oplossingen
- Verwijzing en interne onderdelen
- AvailableUpdates-bits die worden gebruikt voor certificaatonderhoud
- Verwachte voortgang (AvailableUpdates)
- Procedures voor herstel
- Beveiligd opstarten inschakelen in firmware
- Geplande taak beveiligd opstarten uitgeschakeld of verwijderd
Overzicht
Deze pagina begeleidt beheerders en ondersteuningsmedewerkers bij het diagnosticeren en oplossen van problemen met beveiligd opstarten op Windows-apparaten. Onderwerpen zijn onder andere mislukte updates van Secure Boot-certificaten, onjuiste Secure Boot-statussen, onverwachte BitLocker-herstelprompts en opstartfouten na wijzigingen in de Secure Boot-configuratie.
In de richtlijnen wordt uitgelegd hoe u Windows-onderhoud en -configuratie kunt controleren, relevante registerwaarden en gebeurtenislogboeken kunt controleren en kunt bepalen wanneer firmware- of platformbeperkingen een OEM-update vereisen. Deze inhoud is bedoeld voor het diagnosticeren van problemen op bestaande apparaten. Het is niet bedoeld voor het plannen van nieuwe implementaties. Dit document wordt bijgewerkt wanneer nieuwe scenario's en richtlijnen voor probleemoplossing worden geïdentificeerd.
Hoe Secure Boot-certificaatonderhoud werkt
Certificaatonderhoud voor beveiligd opstarten in Windows is een gecoördineerd proces tussen het besturingssysteem en de UEFI-firmware van een apparaat. Het doel is om kritieke trust anchors bij te werken met behoud van de mogelijkheid om in elke fase op te starten.
Het proces wordt aangestuurd door een geplande Windows-taak, een op het register gebaseerde reeks updateacties en ingebouwde logboekregistratie en nieuwe pogingen. Deze onderdelen zorgen er samen voor dat certificaten voor beveiligd opstarten en Windows Boot Manager op een gecontroleerde en geordende manier worden bijgewerkt en alleen nadat de vereiste stappen zijn geslaagd.
Waar moet je beginnen bij het oplossen van problemen?
Wanneer een apparaat niet de verwachte vooruitgang lijkt te boeken bij het toepassen van secure boot-certificaatupdates, begin je met het identificeren van de categorie van het probleem. De meeste problemen vallen onder een van de volgende vier gebieden: de servicestatus van Windows, het updatemechanisme voor beveiligd opstarten, het gedrag van de firmware of een platform- of OEM-beperking.
Begin met de onderstaande controles in de aangegeven volgorde. In veel gevallen zijn deze stappen voldoende om het waargenomen gedrag te verklaren en volgende acties te bepalen zonder diepgaander onderzoek.
Bevestig dat Windows-onderhoud en platformgeschiktheid
- Controleer of het apparaat voldoet aan de basisvereisten om secure boot-certificaatupdates te ontvangen:
- Op het apparaat wordt een ondersteunde versie van Windows uitgevoerd.
- De meest recente vereiste Windows-beveiligingsupdates zijn geïnstalleerd.
- Beveiligd opstarten is ingeschakeld in UEFI-firmware.
- Als niet aan een van deze voorwaarden wordt voldaan, moet u deze oplossen voordat u doorgaat met verdere probleemoplossing.
De taakstatus van Secure-Boot-Update controleren
- Controleer of het Windows-mechanisme dat verantwoordelijk is voor het toepassen van secure boot-certificaatupdates aanwezig is en functioneert:
- De geplande taak Secure-Boot-Update bestaat.
- De taak wordt ingeschakeld en uitgevoerd als lokaal systeem.
- De taak is ten minste eenmaal uitgevoerd sinds de meest recente Windows-beveiligingsupdate is geïnstalleerd.
- Als de taak is uitgeschakeld, verwijderd of niet wordt uitgevoerd, kunnen certificaatupdates voor beveiligd opstarten niet worden toegepast. Bij het oplossen van problemen moet de nadruk liggen op het herstellen van de taak voordat andere oorzaken worden onderzocht.
Registerinstellingen controleren op verwachte voortgang
Controleer de onderhoudsstatus van Secure Boot van het apparaat in het register:- Onderzoek UEFICA2023Status, UEFICA2023Error en UEFICA2023ErrorEvent.
- Bekijk AvailableUpdates en vergelijk deze met de verwachte voortgang (zie Verwijzing en interne factoren).
Samen geven deze waarden aan of de service normaal verloopt, een bewerking opnieuw probeert uit te voeren of vastloopt bij een specifieke stap.
Correleer registerstatus met gebeurtenissen voor beveiligd opstarten
Controleer gebeurtenissen met betrekking tot beveiligd opstarten in het systeemgebeurtenislogboek en correleer deze met de registerstatus. Gebeurtenisgegevens bevestigen doorgaans of het apparaat voorwaarts gaat, opnieuw probeert vanwege een tijdelijke voorwaarde of wordt geblokkeerd door een firmware- of platformprobleem.
Samen geven het register en gebeurtenislogboeken meestal aan of het gedrag verwacht, tijdelijk of corrigerend optreden is.
Geplande taak voor Secure-Boot-Update
Certificaatonderhoud voor beveiligd opstarten wordt geïmplementeerd via een geplande Windows-taak met de naam Secure-Boot-Update. De taak wordt geregistreerd op het volgende pad:
Opmerking
\Microsoft\Windows\PI\Secure-Boot-Update
De taak wordt uitgevoerd als lokaal systeem. Deze wordt standaard uitgevoerd bij het opstarten van het systeem en daarna elke 12 uur. Bij elke uitvoering wordt gecontroleerd of er acties voor updates voor beveiligd opstarten in behandeling zijn en wordt geprobeerd deze achtereenvolgens toe te passen.
Als deze taak is uitgeschakeld of ontbreekt, kunnen certificaatupdates voor beveiligd opstarten niet worden toegepast. De taak Secure-Boot-Update moet ingeschakeld blijven om Secure Boot-onderhoud te laten functioneren.
Waarom een geplande taak wordt gebruikt
Certificaatupdates voor beveiligd opstarten vereisen coördinatie tussen Windows- en UEFI-firmware, waaronder het schrijven van UEFI-variabelen die sleutels en certificaten voor beveiligd opstarten opslaan. Met een geplande taak kan Windows proberen deze updates uit te voeren wanneer het systeem zich in een toestand bevindt waarin firmwarevariabelen kunnen worden gewijzigd.
Het terugkerende schema van 12 uur biedt extra mogelijkheden om updates opnieuw uit te voeren als een eerdere poging is mislukt of als het apparaat ingeschakeld is gebleven zonder opnieuw op te starten. Dit ontwerp zorgt voor vooruitgang zonder handmatige tussenkomst.
Het registerbitmasker AvailableUpdates
De taak Secure-Boot-Update wordt aangestuurd door de registerwaarde AvailableUpdates . Deze waarde is een 32-bits bitmasker op:
Opmerking
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Elk bit in de waarde vertegenwoordigt een specifieke bijwerkactie voor beveiligd opstarten. Het updateproces begint wanneer AvailableUpdates wordt ingesteld op een andere waarde dan nul, automatisch door Windows of expliciet door een beheerder. Een waarde zoals 0x5944 geeft bijvoorbeeld aan dat er meerdere updateacties in behandeling zijn.
Wanneer de taak Secure-Boot-Update wordt uitgevoerd, worden de ingestelde bits geïnterpreteerd als werk in behandeling en worden deze in een gedefinieerde volgorde verwerkt.
Opeenvolgende updates, logboekregistratie en gedrag bij nieuwe rechtszaken
Certificaatupdates voor beveiligd opstarten worden in een vaste volgorde toegepast. Elke updateactie is zo ontworpen dat je het veilig opnieuw kunt proberen en wordt onafhankelijk voltooid. De taak Secure-Boot-Update gaat pas door naar de volgende stap als de huidige actie is voltooid en de bijbehorende bit is gewist uit AvailableUpdates.
Elke bewerking maakt gebruik van standaard UEFI-interfaces om variabelen voor beveiligd opstarten, zoals de DB en KEK, bij te werken of om de bijgewerkte Windows-opstartmanager te installeren. Windows registreert het resultaat van elke stap in het logboek van systeemgebeurtenissen. Succesgebeurtenissen bevestigen de voorwaartse voortgang, terwijl foutgebeurtenissen aangeven waarom een actie niet kon worden voltooid.
Als een updatestap mislukt, wordt de verwerking van de taak gestopt, wordt de fout geregistreerd en blijft de bijbehorende bit ingesteld. De bewerking wordt opnieuw uitgevoerd de volgende keer dat de taak wordt uitgevoerd. Door dit gedrag voor nieuwe proefversies kunnen apparaten automatisch herstellen van tijdelijke omstandigheden, zoals ontbrekende firmware-ondersteuning of vertraagde OEM-updates.
Beheerders kunnen de voortgang bijhouden door de registerstatus te correleren met vermeldingen in het gebeurtenislogboek. Registerwaarden zoals UEFICA2023Status, UEFICA2023Error en UEFICA2023ErrorEvent geven samen met het bitmasker AvailableUpdates aan welke stap actief, voltooid of geblokkeerd is.
Deze combinatie geeft aan of het apparaat normaal verloopt, een bewerking opnieuw probeert uit te voeren of vastloopt.
Integratie met OEM-firmware
Certificaatupdates voor beveiligd opstarten zijn afhankelijk van het juiste gedrag en de juiste ondersteuning in de UEFI-firmware van een apparaat. Terwijl Windows het updateproces orkestreert, is de firmware verantwoordelijk voor het afdwingen van Secure Boot-beleid en het onderhouden van de Secure Boot-databases.
OEM's bieden twee essentiële elementen die Secure Boot-certificaatonderhoud mogelijk maken:
- Door platformsleutels ondertekende Key Exchange Keys (KEK's) die de installatie van nieuwe certificaten voor beveiligd opstarten autoriseren.
- Firmware-implementaties die Secure Boot-databases correct behouden, toevoegen en valideren tijdens updates.
Als de firmware dit gedrag niet volledig ondersteunt, kunnen updates voor beveiligd opstarten vastlopen, voor onbepaalde tijd opnieuw proberen of leiden tot opstartfouten. In deze gevallen kan Windows de update niet voltooien zonder de firmware te wijzigen.
Microsoft werkt samen met OEM's om firmwareproblemen op te sporen en gecorrigeerde updates beschikbaar te maken. Als probleemoplossing aangeeft dat er een firmwarebeperking of -defect is, moeten beheerders mogelijk de meest recente UEFI-firmware-update installeren die door de fabrikant van het apparaat is geleverd voordat de updates van Secure Boot-certificaten kunnen worden voltooid.
Algemene foutscenario's en oplossingen
Updates voor beveiligd opstarten worden toegepast door de geplande taak Secure-Boot-Update op basis van de registerstatus van AvailableUpdates .
Onder normale omstandigheden worden deze stappen automatisch uitgevoerd en worden succesgebeurtenissen vastgelegd terwijl elke fase wordt voltooid. In sommige gevallen kan firmwaregedrag, platformconfiguratie of onderhoudsvereisten de voortgang verhinderen of tot onverwacht opstartgedrag leiden.
In de onderstaande secties worden de meest voorkomende foutscenario's beschreven, hoe u ze kunt herkennen, waarom ze optreden en de juiste vervolgstappen om de normale werking te herstellen. Scenario's worden gerangschikt van de meest voorkomende tot ernstigere gevallen met gevolgen voor opstarten.
Updates voor beveiligd opstarten worden niet toegepast (geen voortgang)
Als bij secure boot-updates geen voortgang te zien is, betekent dit meestal dat het updateproces nooit is gestart. Als gevolg hiervan ontbreken de verwachte registerwaarden en gebeurtenislogboeken voor beveiligd opstarten, omdat het updatemechanisme nooit is geactiveerd.
Wat is er gebeurd?
Het updateproces voor beveiligd opstarten is niet gestart, dus er zijn geen certificaten voor beveiligd opstarten of bijgewerkt opstartbeheer toegepast op het apparaat.
Hoe herken je het?
- Er zijn geen registerwaarden voor Secure Boot-onderhoud aanwezig, zoals UEFICA2023Status.
- Verwachte gebeurtenissen voor beveiligd opstarten (bijvoorbeeld 1043, 1044, 1045, 1799, 1801) ontbreken in het systeemgebeurtenislogboek.
- Het apparaat blijft oudere certificaten voor beveiligd opstarten en opstartonderdelen gebruiken.
De reden hiervoor
Dit scenario treedt meestal op als een of meer van de volgende voorwaarden van toepassing zijn:
- De geplande taak Secure-Boot-Update is uitgeschakeld of ontbreekt.
- Beveiligd opstarten is uitgeschakeld in UEFI-firmware.
- Het apparaat voldoet niet aan de onderhoudsvereisten van Windows, zoals het uitvoeren van een ondersteunde Windows-versie of het installeren van vereiste updates.
Wat u moet doen
- Controleer of het apparaat voldoet aan de vereisten voor Windows-onderhoud en platformgeschiktheid.
- Controleer of Beveiligd opstarten is ingeschakeld in de firmware.
- Zorg ervoor dat de geplande taak SecureBootUpdate bestaat en is ingeschakeld.
Als de geplande taak is uitgeschakeld of ontbreekt, volgt u de richtlijnen in Geplande taak voor beveiligd opstarten uitgeschakeld of verwijderd om deze te herstellen. Nadat de taak is hersteld, start je het apparaat opnieuw op of voer je de taak handmatig uit om Secure Boot-onderhoud te starten.
Apparaat wordt opgestart in BitLocker-herstel na de update voor beveiligd opstarten
In sommige gevallen kunnen aan Secure Boot gerelateerde updates ervoor zorgen dat een apparaat BitLocker-herstel ingaat. Het gedrag kan van voorbijgaande aard of aanhoudend zijn, afhankelijk van de onderliggende oorzaak.
Scenario 1: Eenmalig BitLocker-herstel na secure boot-update
Wat gebeurt er
Het apparaat voert BitLocker-herstel uit bij de eerste keer opstarten na de update voor beveiligd opstarten, maar wordt normaal opgestart bij de volgende herstarts.
De reden hiervoor
Tijdens de eerste keer opstarten na de update meldt de firmware nog niet de bijgewerkte waarden voor beveiligd opstarten wanneer Windows probeert BitLocker opnieuw te sluiten. Hierdoor komen de gemeten opstartwaarden tijdelijk niet overeen en wordt herstel geactiveerd. Bij de volgende keer dat de firmware wordt opgestart, worden de bijgewerkte waarden correct gerapporteerd, wordt BitLocker opnieuw afgesloten en herhaalt het probleem zich niet.
Hoe herken je het?
- BitLocker-herstel vindt eenmaal plaats.
- Na het invoeren van de herstelsleutel vragen volgende opstartbeurten niet om herstel.
- Er is geen actieve opstartvolgorde of PXE-betrokkenheid aanwezig.
Wat u moet doen
- Voer de BitLocker-herstelsleutel in om Windows te hervatten.
- Controleer op firmware-updates.
Scenario 2: Herhaald BitLocker-herstel vanwege de PXE-configuratie voor het eerst opstarten
Wat gebeurt er
BitLocker-herstel wordt telkens opnieuw opgestart door het apparaat.
De reden hiervoor
Het apparaat is geconfigureerd om eerst op te starten via PXE (netwerk). De PXE-opstartpoging mislukt en de firmware valt vervolgens terug naar de opstartmanager van Windows op de schijf.
Dit resulteert in twee verschillende ondertekeningsautoriteiten die tijdens één opstartcyclus worden gemeten:
- Het PXE-opstartpad is ondertekend door de Microsoft UEFI CA 2011.
- Windows-opstartbeheer op schijf is ondertekend door de Windows UEFI CA 2023.
Omdat BitLocker tijdens het opstarten verschillende Secure Boot-vertrouwensketens observeert, kan er geen stabiele set TPM-metingen worden vastgesteld om opnieuw te herstellen. Hierdoor wordt herstel geactiveerd bij elke keer dat BitLocker wordt opgestart.
Hoe herken je het?
- BitLocker-herstel wordt geactiveerd bij elke nieuwe start.
- Door de herstelsleutel in te voeren, kan Windows worden gestart, maar de prompt keert terug bij de volgende keer opstarten.
- PXE of netwerkopstarten is vóór de lokale schijf geconfigureerd in de opstartvolgorde van de firmware.
Wat u moet doen
- Configureer de opstartvolgorde van de firmware, zodat Windows Opstartbeheer op de schijf bovenaan staat.
- Schakel PXE-opstarten uit als dit niet vereist is.
- Als PXE vereist is, zorg er dan voor dat de PXE-infrastructuur gebruikmaakt van een in 2023 ondertekende Windows-opstartlader.
Apparaat kan niet opstarten na het opnieuw instellen van Beveiligd opstarten
Wat is er gebeurd?
Dit weerspiegelt een wijziging op firmwareniveau in plaats van een Windows-probleem. De update voor beveiligd opstarten is voltooid, maar na een latere herstart wordt het apparaat niet meer opgestart in Windows.
Hoe herken je het?
- Het apparaat kan Windows niet starten en er kan een firmware- of BIOS-bericht worden weergegeven dat een schending van beveiligd opstarten aangeeft.
- De fout treedt op nadat de instellingen voor beveiligd opstarten opnieuw zijn ingesteld op de standaardwaarden van de firmware.
- Als je beveiligd opstarten uitschakelt, kan het apparaat mogelijk opnieuw opstarten.
De reden hiervoor
Als je Beveiligd opstarten terugzet naar de standaardinstellingen van de firmware, worden de databases voor beveiligd opstarten gewist die in de firmware zijn opgeslagen. Op apparaten die al zijn overgezet naar de Windows UEFI CA 2023-ondertekende opstartbeheerder, worden met deze reset de certificaten verwijderd die nodig zijn om die opstartmanager te vertrouwen.
Als gevolg hiervan herkent de firmware het geïnstalleerde opstartbeheer van Windows niet meer als vertrouwd en wordt het opstartproces geblokkeerd.
Dit scenario wordt niet veroorzaakt door de secure boot-update zelf, maar door een volgende firmwareactie waarmee de bijgewerkte trust anchors worden verwijderd.
Wat u moet doen
- Gebruik het herstelprogramma voor beveiligd opstarten om het vereiste certificaat te herstellen, zodat het apparaat opnieuw kan worden opgestart.
- Controleer na herstel of de nieuwste firmware van de fabrikant van het apparaat is geïnstalleerd op het apparaat.
- Stel Beveiligd opstarten niet opnieuw in op de standaardwaarden van de firmware, tenzij de OEM-firmware bijgewerkte standaardinstellingen voor beveiligd opstarten bevat die de 2023-certificaten vertrouwen.
Hulpprogramma voor Secure Boot-herstel
Het systeem herstellen:
- Kopieer op een tweede Windows-pc waarop de Windows-update van juli 2024 of nieuwer is geïnstalleerd SecureBootRecovery.efi van C:\Windows\Boot\EFI\.
- Plaats het bestand op een USB-station dat met FAT32 is geformatteerd onder \EFI\BOOT\ en wijzig de naam in bootx64.efi.
- Start het betreffende apparaat op vanaf het USB-station en wacht totdat het herstelprogramma wordt uitgevoerd. Het hulpprogramma voegt de Windows UEFI CA 2023 toe aan de DB.
Nadat het certificaat is hersteld en het systeem opnieuw is opgestart, zou Windows normaal moeten starten.
Belangrijk: Met dit proces wordt slechts één van de nieuwe certificaten opnieuw toegepast. Zodra het apparaat is hersteld, controleert u of de meest recente certificaten opnieuw zijn toegepast en kunt u overwegen het BIOS/de UEFI van het systeem bij te werken naar de nieuwste beschikbare versie. Dit kan helpen voorkomen dat het probleem met het opnieuw instellen van Secure Boot zich opnieuw voordoet, aangezien veel OEM's firmwareoplossingen voor dit specifieke probleem hebben uitgebracht.
Apparaat start niet op na de update voor beveiligd opstarten doordat de firmware de DB overschrijft
Wat is er gebeurd?
Na het toepassen van de certificaatupdate voor beveiligd opstarten en opnieuw opstarten, kan het apparaat niet opstarten en bereikt het Windows niet.
Hoe herken je het?
- Het apparaat werkt direct na het opnieuw opstarten dat is vereist voor de update voor beveiligd opstarten.
- Er kan een firmwarefout of een fout met beveiligd opstarten worden weergegeven of het systeem kan stoppen voordat Windows is geladen.
- Als u beveiligd opstarten uitschakelt, kan het apparaat mogelijk opstarten.
De reden hiervoor
Dit probleem kan worden veroorzaakt door een defect in de UEFI-firmware-implementatie van het apparaat.
Wanneer Windows certificaatupdates voor beveiligd opstarten toepast, wordt van de firmware verwacht dat deze nieuwe certificaten toevoegt aan de bestaande database voor toegestane handtekeningen (DB) voor beveiligd opstarten. Sommige firmware-implementaties overschrijven de DB ten onrechte in plaats van deze eraan toe te voegen.
Wanneer dit gebeurt,
- Eerder vertrouwde certificaten, waaronder het Microsoft 2011 bootloader-certificaat, worden verwijderd.
- Als het systeem op dat moment nog steeds een opstartmanager gebruikt die is ondertekend met het 2011-certificaat, vertrouwt de firmware het niet meer.
- De firmware weigert opstartbeheer en blokkeert het opstartproces.
In sommige gevallen kan de DB ook beschadigd raken in plaats van netjes te worden overschreven, wat tot hetzelfde resultaat leidt. Dit gedrag is waargenomen bij specifieke firmware-implementaties en wordt niet verwacht bij compatibele firmware.
Wat u moet doen
- Open de firmware-instellingmenu's en probeer de instellingen voor beveiligd opstarten opnieuw in te stellen.
- Als het apparaat na het opnieuw instellen wordt opgestart, controleert u de ondersteuningssite van de fabrikant van het apparaat op een firmware-update die de verwerking van Secure Boot DB corrigeert.
- Als er een firmware-update beschikbaar is, installeer je deze voordat Secure Boot opnieuw wordt ingeschakeld en certificaatupdates voor Secure Boot opnieuw worden toegepast.
Als het opnieuw instellen van Beveiligd opstarten niet helpt om de opstartfunctionaliteit te herstellen, zijn voor verder herstel waarschijnlijk OEM-specifieke richtlijnen vereist.
Secure Boot-update geblokkeerd vanwege ontbrekende OEM-ondertekende KEK
Wat is er gebeurd?
De update van het Secure Boot-certificaat is niet voltooid en blijft geblokkeerd tijdens de fase van het bijwerken van de Key Exchange Key (KEK).
Hoe herken je het?
- De registerwaarde AvailableUpdates blijft ingesteld op de KEK-bit (0x0004) en wordt niet gewist.
- UEFICA2023Status gaat niet naar de status voltooid.
- In het systeemgebeurtenislogboek wordt herhaaldelijk gebeurtenis-id 1803 geregistreerd, waarmee wordt aangegeven dat de KEK-update niet kan worden toegepast.
- Het apparaat gaat door met het opnieuw proberen van de update zonder vooruit te gaan.
De reden hiervoor
Voor het bijwerken van de KEK voor beveiligd opstarten is autorisatie vereist van de platformsleutel (PK) van het apparaat, die eigendom is van de OEM.
De update slaagt alleen als de fabrikant van het apparaat Microsoft een PK-ondertekende KEK voor dat specifieke platform verstrekt. Deze door OEM ondertekende KEK is opgenomen in Windows-updates en stelt Windows in staat de KEK-variabele voor de firmware bij te werken.
Als de OEM geen PK-ondertekende KEK voor het apparaat heeft verstrekt, kan Windows de KEK-update niet voltooien. In deze status:
- Updates voor beveiligd opstarten worden standaard geblokkeerd.
- Windows kan de ontbrekende autorisatie niet omzeilen.
- Het apparaat kan permanent niet in staat zijn om Secure Boot-certificaatonderhoud te voltooien.
Dit kan gebeuren op oudere of niet meer ondersteunde apparaten waarbij de OEM geen firmware of belangrijke updates meer biedt. Er is geen ondersteund handmatig herstelpad voor deze voorwaarde.
Gebeurtenissen en foutindicatoren voor secure boot-certificaten
Wanneer certificaatupdates voor beveiligd opstarten niet worden toegepast, registreert Windows diagnostische gebeurtenissen die verklaren waarom de voortgang is geblokkeerd. Deze gebeurtenissen worden geschreven wanneer het bijwerken van de Secure Boot-handtekeningdatabase (DB) of Key Exchange Key (KEK) niet veilig kan worden voltooid vanwege firmware, platformstatus of configuratievoorwaarden. De scenario's in deze sectie verwijzen naar deze gebeurtenissen om algemene foutpatronen te identificeren en de juiste oplossing te bepalen. Deze sectie is bedoeld ter ondersteuning van de diagnose en interpretatie van problemen die eerder zijn beschreven, niet om nieuwe foutscenario's te introduceren.
Zie Secure Boot DB en DBX variabele updategebeurtenissen (KB5016061) voor een volledige lijst met gebeurtenis-id's, beschrijvingen en voorbeeldvermeldingen.
KEK-updatefout (DB-updates slagen, KEK niet)
Een apparaat kan certificaten bijwerken in de Secure Boot DB, maar mislukken tijdens de KEK-update. Als dit gebeurt, kan het updateproces voor beveiligd opstarten niet worden voltooid.
Symptomen
- DB-certificaatgebeurtenissen geven voortgang aan, maar de KEK-fase is nog niet voltooid.
- AvailableUpdates blijft ingesteld op 0x4004 en de 0x0004 bit wordt niet gewist nadat meerdere taken zijn uitgevoerd.
- Gebeurtenis 1795 of 1803 kan aanwezig zijn.
Interpretatie
- 1795 geeft meestal een firmwarefout aan tijdens het bijwerken van een variabele voor beveiligd opstarten.
- 1803 geeft aan dat de KEK-update niet kan worden geautoriseerd omdat er geen vereiste OEM PK-ondertekende KEK-payload beschikbaar is voor het platform.
Volgende stappen
- Controleer voor 1795 op OEM-firmware-updates en valideer firmware-ondersteuning voor variabele secure boot-updates.
- Controleer voor 1803 of de OEM Microsoft de PK-ondertekende KEK heeft verstrekt die vereist is voor het apparaatmodel.
KEK-updatefout op gast-VM's die worden gehost op Hyper-V
Op Hyper-V virtuele machines moeten voor secure boot-certificaatupdates de Windows-updates van maart 2026 worden geïnstalleerd op zowel de Hyper-V-host als het gastbesturingssysteem.
Updatefouten worden gemeld vanuit de gast, maar de gebeurtenis geeft aan waar herstel is vereist:
- Gebeurtenis 1795 (bijvoorbeeld 'De media zijn schrijfbeveiliging') die in de gast is gemeld, geeft aan dat de Hyper-V-host de update van maart 2026 mist en moet worden bijgewerkt.
- Gebeurtenis 1803 gerapporteerd in de gast geeft aan dat de virtuele machine voor gasten zelf de update van maart 2026 mist en moet worden bijgewerkt.
Verwijzing en interne onderdelen
Deze sectie bevat geavanceerde referentie-informatie bedoeld voor probleemoplossing en ondersteuning. Het is niet bedoeld voor implementatieplanning. Het is een uitbreiding op de eerder samengevatte onderhoudsmechanismen voor beveiligd opstarten en biedt gedetailleerd referentiemateriaal voor het interpreteren van registerstatus- en gebeurtenislogboeken.
Opmerking (door IT beheerde implementaties): wanneer geconfigureerd via groepsbeleid of Microsoft Intune, moeten twee vergelijkbare instellingen niet worden verward. De waarde AvailableUpdatesPolicy vertegenwoordigt de geconfigureerde beleidsstatus. Ondertussen weerspiegelt AvailableUpdates de actieve werkstatus voor het wissen van bits. Beide kunnen hetzelfde resultaat opleveren, maar ze gedragen zich anders omdat het beleid na verloop van tijd opnieuw van toepassing is.
AvailableUpdates-bits die worden gebruikt voor certificaatonderhoud
De onderstaande bits worden gebruikt voor de acties voor certificaat- en opstartbeheer die in dit document worden beschreven. De kolom Order geeft de volgorde aan waarin de taak Secure-Boot-Update elke bit verwerkt.
| volgorde | Bitinstelling | Gebruik |
|---|---|---|
| 1 | 0x0040 | Dit bit vertelt de geplande taak om het Windows UEFI CA 2023-certificaat toe te voegen aan de Secure Boot DB. Hierdoor kan Windows opstartbeheerders vertrouwen die met dit certificaat zijn ondertekend. |
| 2 | 0x0800 | Dit bit vertelt de geplande taak om de Microsoft-optie ROM UEFI CA 2023 toe te passen op de DB. Voorwaardelijk gedrag: wanneer de vlag 0x4000 is ingesteld, controleert de geplande taak eerst de database op het Microsoft Corporation UEFI CA 2011-certificaat . Het zal het Microsoft Option ROM UEFI CA 2023-certificaatalleen toepassen als het 2011-certificaat aanwezig is. |
| 3 | 0x1000 | Met dit bit wordt de geplande taak aangegeven om de Microsoft UEFI CA 2023 toe te passen op de database. Voorwaardelijk gedrag: wanneer de vlag 0x4000 is ingesteld, controleert de geplande taak eerst de database op het Microsoft Corporation UEFI CA 2011-certificaat . Het Microsoft UEFI CA 2023-certificaat wordt alleen toegepast als het 2011-certificaat aanwezig is. |
| Wijzigingstoets (gedragsvlag) | 0x4000 | Deze bit wijzigt het gedrag van de 0x0800 en 0x1000 bits, zodat de Microsoft UEFI CA 2023 en Microsoft Option ROM UEFI CA 20223 alleen worden toegepast als de DB al de Microsoft Corporation UEFI CA 2011 bevat. Om ervoor te zorgen dat het beveiligingsprofiel van het apparaat hetzelfde blijft, past deze bit deze nieuwe certificaten alleen toe als het apparaat het Microsoft Corporation UEFI CA 2011-certificaat vertrouwt. Niet alle Windows-apparaten vertrouwen dit certificaat. |
| 4 | 0x0004 | Dit bit vertelt de geplande taak om te zoeken naar een Key Exchange Key die is ondertekend door de Platform Key (PK) van het apparaat. De PK wordt beheerd door de OEM. OEM's ondertekenen de Microsoft KEK met hun PK en leveren deze aan Microsoft, waar deze wordt opgenomen in maandelijkse cumulatieve updates. |
| 5 | 0x0100 | Dit bit vertelt de geplande taak om opstartbeheer toe te passen, ondertekend door de Windows UEFI CA 2023, op de opstartpartitie. Dit vervangt de Microsoft Windows Production PCA 2011 signed boot manager. |
Opmerkingen:
- De 0x4000 bit blijft ingesteld nadat alle andere bits zijn verwerkt.
- Elk bit wordt verwerkt door de geplande taak Secure-Boot-Update in de bovenstaande volgorde.
- Als de 0x0004 bit niet kan worden verwerkt vanwege een ontbrekende PK-ondertekende KEK, wordt op de geplande taak nog steeds de update van Opstartbeheer toegepast die wordt aangegeven door bit 0x0100.
Verwachte voortgang (AvailableUpdates)
Wanneer een bewerking met succes wordt voltooid, wist Windows de bijbehorende bit uit AvailableUpdates. Als een bewerking mislukt, registreert Windows een gebeurtenis en probeert het opnieuw wanneer de taak opnieuw wordt uitgevoerd.
In de onderstaande tabel zie je de verwachte voortgang van de waarden voor AvailableUpdates naarmate elke updateactie voor Secure Boot wordt voltooid.
| Stap | Bit verwerkt | Beschikbare Updates | Beschrijving | Geslaagde gebeurtenis geregistreerd | Mogelijke foutgebeurteniscodes |
|---|---|---|---|---|---|
| Start | 0x5944 | Initiële status voordat het certificaatonderhoud voor beveiligd opstarten wordt gestart. | - | - | |
| 1 | 0x0040 | 0x5944 → 0x5904 | Windows UEFI CA 2023 is toegevoegd aan de Secure Boot DB. | 1036 | 1032, 1795, 1796, 1802 |
| 2 | 0x0800 | 0x5904 → 0x5104 | Voeg Microsoft-optie ROM UEFI CA 2023 toe aan de DB als het apparaat eerder de Microsoft UEFI CA 2011 vertrouwde. | 1044 | 1032, 1795, 1796, 1802 |
| 3 | 0x1000 | 0x5104 → 0x4104 | Microsoft UEFI CA 2023 wordt toegevoegd aan de DB als het apparaat eerder de Microsoft UEFI CA 2011 vertrouwde. | 1045 | 1032, 1795, 1796, 1802 |
| 4 | 0x0004 | 0x4104 → 0x4100 | Nieuwe Microsoft KEK 2K CA 2023, ondertekend door de OEM-platformsleutel, is toegepast. | 1043 | 1032, 1795, 1796, 1802, 1803 |
| 5 | 0x0100 | 0x4100 → 0x4000 | Opstartbeheer ondertekend door Windows UEFI CA 2023 is geïnstalleerd. | 1799 | 1797 |
Opmerkingen
- Zodra de bewerking die aan een bit is gekoppeld, met succes is voltooid, wordt die bit gewist uit AvailableUpdates.
- Als een van deze bewerkingen mislukt, wordt een gebeurtenis geregistreerd en wordt de bewerking opnieuw uitgevoerd wanneer de volgende keer de geplande taak wordt uitgevoerd.
- De 0x4000 bit is een wijzigingstoets en wordt niet gewist. Een uiteindelijke AvailableUpdates-waarde van 0x4000 geeft aan dat alle toepasselijke updateacties zijn voltooid.
- Gebeurtenissen 1032, 1795, 1796 en 1802 geven doorgaans firmware- of platformbeperkingen aan.
- Gebeurtenis 1803 geeft ontbrekende OEM PK-ondertekende KEK aan.
Procedures voor herstel
In deze sectie vindt u stapsgewijze procedures voor het oplossen van specifieke problemen met beveiligd opstarten. Elke procedure is gericht op een goed gedefinieerde voorwaarde en is bedoeld om alleen te worden gevolgd nadat de eerste diagnose heeft bevestigd dat het probleem van toepassing is. Gebruik deze procedures om verwacht beveiligd opstartgedrag te herstellen en certificaatupdates veilig te laten verlopen. Pas deze procedures niet breed of preventief toe.
Beveiligd opstarten inschakelen in firmware
Als beveiligd opstarten is uitgeschakeld in de firmware van een apparaat, raadpleegt u Windows 11 en beveiligd opstarten voor meer informatie over het inschakelen van beveiligd opstarten.
Geplande taak beveiligd opstarten uitgeschakeld of verwijderd
De geplande taak Secure-Boot-Update is vereist om Windows te laten werken om certificaatupdates voor Secure Boot toe te passen. Als de taak is uitgeschakeld of ontbreekt, wordt het certificaatonderhoud voor beveiligd opstarten niet voortgezet.
Taakgegevens
| Taaknaam | Secure-Boot-Update |
|---|---|
| Taakpad | \Microsoft\Windows\PI\ |
| Volledig pad | \Microsoft\Windows\PI\Secure-Boot-Update |
| Wordt uitgevoerd als | SYSTEM (lokaal systeem) |
| Triggers | Bij het opstarten en elke 12 uur |
| Vereiste status | Ingeschakeld |
De taakstatus controleren
Voer uit vanaf een PowerShell-prompt met verhoogde bevoegdheid:
schtasks.exe /Query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V
Zoek het veld Status :
| Status | Betekenis |
|---|---|
| Klaar | Taak bestaat en is ingeschakeld. |
| Delen | Taak bestaat, maar moet worden ingeschakeld. |
| Fout / Niet gevonden | Taak ontbreekt en moet opnieuw worden gemaakt. |
De taak inschakelen of opnieuw maken
Als het statusveld voor Secure-Boot-Update Uitgeschakeld, Fout of Niet gevonden is, gebruik dan het voorbeeldscript om de taak in te schakelen: Voorbeeld Enable-SecureBootUpdateTask.ps1
Opmerking: dit is een voorbeeldscript en wordt niet ondersteund door Microsoft. Beheerders moeten het programma controleren en aanpassen aan hun omgeving.
Voorbeeld:
Opmerking
.\Enable-SecureBootUpdateTask.ps1 - Stil
Instructies voor uitvoeren
- Als u ziet dat toegang is geweigerd, voert u PowerShell opnieuw uit als beheerder.
- Als het script niet wordt uitgevoerd vanwege uitvoeringsbeleid, gebruikt u een bypass voor het procesbereik:
Opmerking
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass