Obs
- Ursprungligt publiceringsdatum: Senast uppdaterad: 19 mars 2026
- KB-ID: 5085046
Den här artikeln innehåller följande avsnitt
- Översikt
- Så här fungerar ett certifikat för säker start
- Börja vid felsökning
- Schemalagd aktivitet för säker start och uppdatering
- Varför en schemalagd aktivitet används
- Registerbitmasken AvailableUpdates
- Integrering med OEM-inbyggd programvara
- Vanliga felscenarier och lösningar
- Referens och interna delar
- AvailableUpdates-bitar som används för certifikatunderhåll
- Förväntat förlopp (AvailableUpdates)
- Åtgärder för att åtgärda detta
- Aktivera Säker start i den inbyggda programvaran
- Schemalagd aktivitet för säker start inaktiverad eller borttagen
Översikt
Den här sidan hjälper administratörer och supportpersonal att diagnostisera och lösa problem med Säker start på Windows-enheter. Ämnena omfattar uppdateringsfel för certifikat för säker start, felaktiga tillstånd för säker start, oväntade BitLocker-återställningsfrågor och startfel efter konfigurationsändringar för säker start.
Vägledningen förklarar hur du verifierar underhåll och konfiguration av Windows, granskar relevanta registervärden och händelseloggar och identifierar när begränsningar i inbyggd programvara eller plattform kräver en OEM-uppdatering. Det här innehållet är avsett för att diagnostisera problem på befintliga enheter. Den är inte avsedd för planering av nya distributioner. Det här dokumentet uppdateras när nya felsökningsscenarier och riktlinjer identifieras.
Så här fungerar certifikatunderhåll för säker start
Säker start-certifikatunderhåll i Windows är en samordnad process mellan operativsystemet och en enhets inbyggda UEFI-programvara. Målet är att uppdatera kritiska förtroendeankare samtidigt som möjligheten att starta i varje steg bevaras.
Processen drivs av en schemalagd Windows-aktivitet, en registerbaserad sekvens med uppdateringsåtgärder och inbyggd loggning och återförsök. Tillsammans säkerställer dessa komponenter att Secure Boot-certifikat och Windows Boot Manager uppdateras på ett kontrollerat, ordnat sätt och endast efter att nödvändiga steg har slutförts.
Börja vid felsökning
När en enhet inte verkar göra förväntade framsteg med att installera certifikatuppdateringar för säker start börjar du med att identifiera problemkategorin. De flesta problem faller inom ett av fyra områden: Windows-underhållstillstånd, uppdateringsmekanismen för säker start, beteende för inbyggd programvara eller en plattforms- eller OEM-begränsning.
Börja med kontrollerna nedan, i ordning. I många fall är dessa steg tillräckliga för att förklara det observerade beteendet och fastställa nästa åtgärder utan djupare undersökning.
Bekräfta Windows-underhåll och plattformsberättigande
- Kontrollera att enheten uppfyller de grundläggande kraven för att få uppdateringar av certifikat för säker start:
- Enheten kör en version av Windows som stöds.
- De senaste nödvändiga Windows-säkerhetsuppdateringarna installeras.
- Säker start är aktiverat i den inbyggda UEFI-programvaran.
- Om något av dessa villkor inte uppfylls åtgärdar du dem innan du fortsätter med ytterligare felsökning.
Verifiera status för Secure-Boot-Update-aktiviteten
- Kontrollera att Windows-mekanismen som ansvarar för att tillämpa certifikatuppdateringar för säker start finns och fungerar:
- Den schemalagda aktiviteten Secure-Boot-Update finns.
- Aktiviteten aktiveras och körs som ett lokalt system.
- Aktiviteten har körts minst en gång sedan den senaste Windows-säkerhetsuppdateringen installerades.
- Om aktiviteten är inaktiverad, borttagen eller inte körs går det inte att tillämpa certifikatuppdateringar för säker start. Felsökningen bör fokusera på att återställa aktiviteten innan andra orsaker undersöks.
Kontrollera registerinställningarna för förväntad status
Granska enhetens status för säker start i registret:- Undersök UEFICA2023Status, UEFICA2023Error och UEFICA2023ErrorEvent.
- Undersök AvailableUpdates och jämför det med förväntad status (se Referens och internt).
Tillsammans anger dessa värden om underhållet fortskrider normalt, försöker utföra en åtgärd igen eller har stoppats i ett visst steg.
Korrelera registertillstånd med säkra starthändelser
Granska Säker start-relaterade händelser i systemhändelseloggen och korrelera dem med registertillståndet. Händelsedata bekräftar vanligtvis om enheten går framåt, försöker igen på grund av ett tillfälligt tillstånd eller blockeras av ett problem med inbyggd programvara eller plattform.
Tillsammans anger register- och händelseloggarna vanligtvis om beteendet är förväntat, tillfälligt eller kräver korrigerande åtgärder.
Schemalagd aktivitet för säker start och uppdatering
Certifikatunderhåll för säker start implementeras via en schemalagd Windows-aktivitet med namnet Secure-Boot-Update. Uppgiften registreras på följande sökväg:
Obs
\Microsoft\Windows\PI\Secure-Boot-Update
Aktiviteten körs som ett lokalt system. Som standard körs den när systemet startas och därefter var 12:e timme. Varje gång den körs kontrollerar den om uppdateringsåtgärder för säker start väntar och försöker tillämpa dem i följd.
Om den här uppgiften är inaktiverad eller saknas går det inte att tillämpa certifikatuppdateringar för säker start. Aktiviteten Secure-Boot-Update måste vara aktiverad för att säker start ska fungera.
Varför en schemalagd aktivitet används
För uppdateringar av certifikat för säker start krävs samordning mellan Windows och inbyggd UEFI-programvara, inklusive skrivning av UEFI-variabler som lagrar nycklar och certifikat för säker start. En schemalagd aktivitet gör att Windows kan försöka uppdatera dessa uppdateringar när systemet är i ett tillstånd där variabler för inbyggd programvara kan ändras.
Det återkommande 12-timmarsschemat ger ytterligare möjligheter att försöka uppdatera igen om ett tidigare försök misslyckades eller om enheten förblev påslagen utan att starta om. Den här designen hjälper till att säkerställa framsteg framåt utan att kräva manuella åtgärder.
Registerbitmasken AvailableUpdates
Aktiviteten Secure-Boot-Update drivs av registervärdet AvailableUpdates . Det här värdet är en 32-bitars bitmask som finns på:
Obs
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Varje bit i värdet representerar en specifik uppdateringsåtgärd för säker start. Uppdateringsprocessen börjar när AvailableUpdates anges till ett annat värde än noll, antingen automatiskt av Windows eller uttryckligen av en administratör. Ett värde som 0x5944 anger till exempel att flera uppdateringsåtgärder väntar.
När aktiviteten Secure-Boot-Update körs tolkar den de angivna bitarna som väntande arbete och bearbetar dem i en definierad ordning.
Sekventiella uppdateringar, loggning och återförsöksbeteende
Uppdateringar av certifikat för säker start tillämpas i en fast ordning. Varje uppdateringsåtgärd är utformad för att vara säker att försöka igen och slutför oberoende av varandra. Aktiviteten Secure-Boot-Update går inte vidare till nästa steg förrän den aktuella åtgärden lyckas och motsvarande bit rensas från AvailableUpdates.
Varje åtgärd använder UEFI-standardgränssnitt för att uppdatera variabler för säker start, till exempel DB och KEK, eller för att installera den uppdaterade Windows-starthanteraren. Resultatet av varje steg sparas i systemhändelseloggen. Lyckade händelser bekräftar framåtskridandet, medan felhändelser anger varför en åtgärd inte kunde slutföras.
Om ett uppdateringssteg misslyckas slutar aktiviteten att bearbetas, loggar felet och lämnar den associerade biten inställd. Åtgärden utförs på nytt nästa gång aktiviteten körs. Med det här återförsöksbeteendet kan enheter återställas automatiskt från tillfälliga förhållanden, till exempel bristande stöd för inbyggd programvara eller försenade OEM-uppdateringar.
Administratörer kan spåra förloppet genom att korrelera registerstatus med händelseloggposter. Registervärden som UEFICA2023Status, UEFICA2023Error och UEFICA2023ErrorEvent, tillsammans med bitmasken AvailableUpdates , anger vilket steg som är aktivt, slutfört eller blockerat.
Den här kombinationen visar om enheten fungerar normalt, försöker utföra en åtgärd igen eller har stannat.
Integrering med OEM-inbyggd programvara
Uppdateringar av certifikat för säker start är beroende av korrekt beteende och stöd i en enhets inbyggda UEFI-programvara. Medan Windows orkestrerar uppdateringsprocessen ansvarar den inbyggda programvaran för att upprätthålla principen för säker start och underhålla databaserna för säker start.
OEM-tillverkare tillhandahåller två viktiga element som möjliggör certifikatservice för säker start:
- Platform Key-signed Key Exchange Keys (KEKs) som auktoriserar installation av nya certifikat för säker start.
- Implementeringar av inbyggd programvara som korrekt bevarar, lägger till och verifierar databaser för säker start under uppdateringar.
Om den inbyggda programvaran inte har fullt stöd för dessa beteenden kan uppdateringar av säker start stanna upp, försöka igen på obestämd tid eller resultera i startfel. I sådana fall kan Windows inte slutföra uppdateringen utan att ändra den inbyggda programvaran.
Microsoft arbetar med OEM-tillverkare för att identifiera problem med inbyggd programvara och göra korrigerade uppdateringar tillgängliga. När felsökningen indikerar en begränsning av den inbyggda programvaran eller en defekt kan administratörer behöva installera den senaste uppdateringen av den inbyggda UEFI-programvaran från enhetstillverkaren innan certifikatuppdateringarna för säker start kan slutföras.
Vanliga felscenarier och lösningar
Uppdateringar för säker start tillämpas av den schemalagda aktiviteten Secure-Boot-Update baserat på registertillståndet AvailableUpdates .
Under normala förhållanden sker dessa steg automatiskt och registrerar lyckade händelser när varje steg slutförs. I vissa fall kan den inbyggda programvarans beteende, plattformskonfiguration eller underhållskrav förhindra förloppet eller leda till oväntat startbeteende.
Avsnitten nedan beskriver de vanligaste felscenarierna, hur du känner igen dem, varför de inträffar och lämpliga nästa steg för att återställa normal drift. Scenarierna sorteras från de vanligaste fallen till allvarligare fall som påverkar starten.
Uppdateringar av säker start tillämpas inte (inga förlopp)
När uppdateringar för säker start inte visar några förlopp innebär det vanligtvis att uppdateringsprocessen aldrig startats. Det gör att de förväntade värdena för Secure Boot-registervärdena och händelseloggarna saknas eftersom uppdateringsmekanismen aldrig utlöstes.
Vad hände
Uppdateringsprocessen för säker start startade inte, så inga certifikat för säker start eller uppdaterad starthanterare tillämpades på enheten.
Så här känner du igen den
- Det finns inga registervärden för säker start-underhåll, till exempel UEFICA2023Status.
- Förväntade händelser för säker start (till exempel 1043, 1044, 1045, 1799, 1801) saknas i systemets händelselogg.
- Enheten fortsätter att använda äldre certifikat och startkomponenter för säker start.
Varför det händer
Det här scenariot inträffar vanligtvis när ett eller flera av följande villkor är sanna:
- Den schemalagda aktiviteten Secure-Boot-Update är inaktiverad eller saknas.
- Säker start är inaktiverat i den inbyggda UEFI-programvaran.
- Enheten uppfyller inte kraven för Windows-underhåll, till exempel att köra en Windows-version som stöds eller att nödvändiga uppdateringar har installerats.
Lämplig åtgärd härnäst
- Kontrollera att enheten uppfyller kvalificeringskraven för Windows-service och plattform.
- Kontrollera att Säker start är aktiverat i den inbyggda programvaran.
- Kontrollera att den schemalagda aktiviteten SecureBootUpdate finns och är aktiverad.
Om den schemalagda aktiviteten är inaktiverad eller saknas följer du anvisningarna i Schemalagd aktivitet för säker start inaktiverad eller borttagen för att återställa den. När aktiviteten har återställts startar du om enheten eller kör aktiviteten manuellt för att initiera säker start-service.
Enheten startas i BitLocker-återställning efter uppdatering av Säker start
I vissa fall kan uppdateringar relaterade till säker start göra att en enhet hamnar i BitLocker-återställning. Beteendet kan vara tillfälligt eller beständigt beroende på den bakomliggande orsaken.
Scenario 1: BitLocker-återställning en gång efter uppdatering av säker start
Vad som händer
Enheten går in i BitLocker-återställning vid den första starten efter uppdateringen av säker start, men startar normalt vid efterföljande omstarter.
Varför det händer
Under den första starten efter uppdateringen rapporterar den inbyggda programvaran ännu inte de uppdaterade värdena för säker start när Windows försöker återförsluta BitLocker. Detta orsakar ett tillfälligt matchningsfel i uppmätta startvärden och utlöser återställning. Vid nästa start rapporterar den inbyggda programvaran de uppdaterade värdena korrekt, BitLocker-återförslutningarna lyckas och problemet återkommer inte.
Så här känner du igen den
- BitLocker-återställning sker en gång.
- När återställningsnyckeln har angetts frågar efterföljande starter inte om återställning.
- Det finns ingen pågående startordning eller PXE-inblandning.
Lämplig åtgärd härnäst
- Ange BitLocker-återställningsnyckeln för att återuppta Windows.
- Sök efter uppdateringar av den inbyggda programvaran.
Scenario 2: Upprepad BitLocker-återställning på grund av PXE:s första startkonfiguration
Vad som händer
Enheten går in i BitLocker-återställning vid varje start.
Varför det händer
Enheten är konfigurerad för att försöka starta PXE (nätverk) först. PXE-startförsöket misslyckas och den inbyggda programvaran återgår sedan till Windows-starthanteraren på disken.
Det resulterar i att två olika signeringsutfärdare mäts under en enda startcykel:
- PXE-startsökvägen är signerad av Microsoft UEFI CA 2011.
- Windows-starthanteraren på disken är signerad av Windows UEFI CA 2023.
Eftersom BitLocker observerar olika förtroendekedjor för säker start under starten kan den inte upprätta en stabil uppsättning TPM-mått att återförsluta mot. Det innebär att BitLocker går in i återställning vid varje start.
Så här känner du igen den
- BitLocker-återställning utlöses vid varje omstart.
- Om du anger återställningsnyckeln kan Windows starta, men uppmaningen återkommer vid nästa start.
- PXE eller nätverksstart konfigureras före den lokala disken i startordning för den inbyggda programvaran.
Lämplig åtgärd härnäst
- Konfigurera startordningen för den inbyggda programvaran så att Windows-starthanteraren på disken är först.
- Inaktivera PXE-start om det inte krävs.
- Om PXE krävs kontrollerar du att PXE-infrastrukturen använder ett 2023-signerat Windows-startprogram.
Enheten startar inte efter återställning av Säker start
Vad hände
Detta återspeglar en ändring på den inbyggda programvarans nivå snarare än ett Windows-problem. Uppdateringen av säker start slutfördes, men efter en senare omstart startar enheten inte längre i Windows.
Så här känner du igen den
- Enheten kan inte starta Windows och kan visa ett meddelande om inbyggd programvara eller BIOS som anger ett brott mot säker start.
- Felet uppstår efter att inställningarna för säker start återställts till standardvärdena för den inbyggda programvaran.
- Om du inaktiverar Säker start kan enheten starta igen.
Varför det händer
Om du återställer säker start till standardinställningarna för den inbyggda programvaran rensas de säkra startdatabaser som lagras i den inbyggda programvaran. På enheter som redan har övergått till den Windows UEFI CA 2023–signerade starthanteraren tar den här återställningen bort de certifikat som krävs för att lita på den starthanteraren.
Som ett resultat känner den inbyggda programvaran inte längre igen den installerade Windows Boot Manager som betrodd och blockerar startprocessen.
Det här scenariot orsakas inte av själva uppdateringen av säker start, utan av en efterföljande åtgärd för inbyggd programvara som tar bort de uppdaterade förtroendeankarna.
Lämplig åtgärd härnäst
- Använd återställningsverktyget för säker start för att återställa det certifikat som krävs, så att enheten kan starta igen.
- Efter återställningen kontrollerar du att enheten har den senaste tillgängliga inbyggda programvaran installerad från enhetstillverkaren.
- Undvik att återställa säker start till standardinställningarna för den inbyggda programvaran om inte OEM-enhetens inbyggda programvara innehåller uppdaterade standardinställningar för säker start som litar på 2023-certifikaten.
Återställningsverktyg för säker start
Så här återställer du systemet:
- På en andra Windows-dator med Windows-uppdateringen från juli 2024 eller senare installerad kopierar du SecureBootRecovery.efi från C:\Windows\Boot\EFI\.
- Placera filen på en FAT32-formaterad USB-enhet under \EFI\BOOT\ och byt namn på den till bootx64.efi.
- Starta den berörda enheten från USB-enheten och låt återställningsverktyget köras. Verktyget lägger till Windows UEFI CA 2023 i databasen.
När certifikatet har återställts och systemet startats om bör Windows starta normalt.
Viktigt: Den här processen tillämpar bara ett av de nya certifikaten igen. När enheten har återställts kontrollerar du att de senaste certifikaten har tillämpats igen och överväg att uppdatera systemets BIOS/UEFI till den senaste tillgängliga versionen. Detta kan förhindra att problemet med återställning av säker start upprepas eftersom många OEM-tillverkare har släppt korrigeringar av inbyggd programvara för det här specifika problemet.
Enheten kan inte starta efter uppdatering av säker start på grund av att den inbyggda programvaran skriver över databasen
Vad hände
När du har installerat certifikatuppdateringen för säker start och startat om kan enheten inte starta och den når inte Windows.
Så här känner du igen den
- Enheten misslyckas omedelbart efter omstarten som krävs av uppdateringen för säker start.
- Ett fel med inbyggd programvara eller säker start kan visas, eller så kan systemet stoppas innan Windows läses in.
- Om du inaktiverar Säker start kan enheten starta.
Varför det händer
Det här problemet kan orsakas av ett fel i enhetens implementering av inbyggd UEFI-programvara.
När Windows tillämpar certifikatuppdateringar för säker start förväntas den inbyggda programvaran lägga till nya certifikat i den befintliga databasen med tillåten signatur för säker start (DB). Vissa implementeringar av inbyggd programvara skriver felaktigt över databasen i stället för att lägga till i den.
När detta inträffar
- Tidigare betrodda certifikat, inklusive Microsoft 2011-startprogramcertifikatet, tas bort.
- Om systemet fortfarande använder en starthanterare som är signerad med 2011-certifikatet vid den tidpunkten, litar den fasta programvaran inte längre på den.
- Den fasta programvaran avvisar starthanteraren och blockerar startprocessen.
I vissa fall kan databasen också bli skadad i stället för att skrivas över rent, vilket leder till samma resultat. Det här beteendet har observerats på specifika implementeringar av inbyggd programvara och förväntas inte på kompatibel inbyggd programvara.
Lämplig åtgärd härnäst
- Öppna konfigurationsmenyerna för den inbyggda programvaran och försök att återställa inställningarna för säker start.
- Om enheten startar efter återställningen kontrollerar du enhetstillverkarens supportwebbplats för en uppdatering av inbyggd programvara som korrigerar hanteringen av databasen med säker start.
- Om det finns en uppdatering av den inbyggda programvaran installerar du den innan du återaktiverar säker start och tillämpar certifikatuppdateringar för säker start igen.
Om återställning av Säker start inte återställer startfunktionen kräver ytterligare återställning troligen OEM-specifik vägledning.
Säker startuppdatering blockeras på grund av att OEM-signerad KEK saknas
Vad hände
Certifikatuppdateringen för säker start slutförds inte och förblir blockerad i KEK-uppdateringssteget (Key Exchange Key).
Så här känner du igen den
- Registervärdet AvailableUpdates förblir inställt med KEK-biten (0x0004) och rensas inte.
- UEFICA2023Status går inte vidare till ett slutfört tillstånd.
- Systemhändelseloggen registrerar händelse-ID 1803 upprepade gånger, vilket anger att KEK-uppdateringen inte kunde tillämpas.
- Enheten fortsätter att försöka uppdatera igen utan att gå framåt.
Varför det händer
För att uppdatera KEK för säker start krävs auktorisering från enhetens plattformsnyckel (PK), som ägs av OEM-tillverkaren.
För att uppdateringen ska lyckas måste enhetstillverkaren förse Microsoft med en PK-signerad KEK för den specifika plattformen. Denna OEM-signerade KEK ingår i Windows-uppdateringar och gör att Windows kan uppdatera KEK-variabeln för den inbyggda programvaran.
Om OEM-tillverkaren inte har tillhandahållit en PK-signerad KEK för enheten kan Windows inte slutföra KEK-uppdateringen. I det här tillståndet:
- Uppdateringar av säker start blockeras avsiktligt.
- Det går inte att kringgå problemet med den saknade auktoriseringen.
- Enheten kan vara permanent oförmögen att slutföra certifikatunderhåll för säker start.
Detta kan inträffa på äldre enheter eller enheter utan support där OEM-tillverkaren inte längre tillhandahåller inbyggd programvara eller viktiga uppdateringar. Det finns ingen manuell återställningsväg som stöds för det här tillståndet.
Uppdateringshändelser och felindikatorer för certifikat för säker start
När certifikatuppdateringar för säker start inte kan tillämpas registrerar Windows diagnostiska händelser som förklarar varför förloppet blockerades. Dessa händelser skrivs när du uppdaterar databasen för säker startsignatur (DB) eller att Key Exchange Key (KEK) inte kan slutföras på ett säkert sätt på grund av inbyggd programvara, plattformstillstånd eller konfigurationsförhållanden. Scenarierna i det här avsnittet refererar till dessa händelser för att identifiera vanliga felmönster och fastställa lämplig reparation. Det här avsnittet är avsett att stödja diagnos och tolkning av problem som beskrivits tidigare, inte att introducera nya felscenarier.
En fullständig lista över händelse-ID:t, beskrivningar och exempelposter finns i Databas- och DBX-variabeluppdateringshändelser (KB5016061) för säker start.
KEK-uppdateringsfel (DB-uppdateringar lyckas, KEK gör det inte)
En enhet kan uppdatera certifikat i databasen för säker start men misslyckas under KEK-uppdateringen. Om detta inträffar går det inte att slutföra uppdateringsprocessen för säker start.
Symtom
- DB-certifikathändelser anger förloppet, men KEK-fasen har inte slutförts.
- AvailableUpdates är fortfarande inställt på 0x4004 och den 0x0004 biten rensas inte efter att flera aktiviteter har körts.
- Händelse 1795 eller 1803 kan förekomma.
Tolkning
- 1795 indikerar vanligtvis ett fel på den inbyggda programvaran vid försök att uppdatera en variabel för säker start.
- 1803 anger att KEK-uppdateringen inte kan auktoriseras eftersom en nödvändig OEM PK-signerad KEK-nyttolast inte är tillgänglig för plattformen.
Nästa steg
- För 1795 söker du efter uppdateringar av inbyggd programvara från OEM-tillverkare och verifierar stödet för inbyggd programvara för variabeluppdateringar för säker start.
- För 1803 bekräftar du om OEM-tillverkaren har försett Microsoft med den PK-signerade KEK som krävs för enhetsmodellen.
KEK-uppdateringsfel på virtuella gästdatorer som finns på Hyper-V
På virtuella Hyper-V-datorer kräver certifikatuppdateringar för säker start att Windows-uppdateringarna för mars 2026 installeras på både Hyper-V-värden och gästoperativsystemet.
Uppdateringsfel rapporteras inifrån gästen, men händelsen anger var reparation krävs:
- Händelse 1795 (till exempel "mediet är skrivskyddat") som rapporterats i gästen anger att Hyper-V-värden saknar uppdateringen för mars 2026 och måste uppdateras.
- Händelse 1803 som rapporterats i gästen anger att själva den virtuella gästdatorn saknar uppdateringen för mars 2026 och måste uppdateras.
Referens och interna delar
Det här avsnittet innehåller avancerad referensinformation avsedd för felsökning och support. Den är inte avsedd för distributionsplanering. Den utökar underhållsmekaniken för säker start som sammanfattades tidigare och innehåller detaljerat referensmaterial för tolkning av registertillstånd och händelseloggar.
Obs (IT-hanterade distributioner): Vid konfiguration via Grupprincip eller Microsoft Intune bör två liknande inställningar inte förväxlas. Värdet AvailableUpdatesPolicy representerar det konfigurerade principtillståndet. Under tiden återspeglar AvailableUpdates det pågående bitrensningsarbetets tillstånd. Båda kan ge samma resultat, men de beter sig olika eftersom principen tillämpas om med tiden.
AvailableUpdates-bitar som används för certifikatunderhåll
Bitarna nedan används för certifikat- och starthanteraråtgärderna som beskrivs i det här dokumentet. Kolumnen Ordning visar den sekvens i vilken Secure-Boot-Update-aktiviteten bearbetar varje bit.
| Ordning | Bitinställning | Användning |
|---|---|---|
| 1 | 0x0040 | Den här biten instruerar den schemalagda aktiviteten att lägga till Windows UEFI CA 2023-certifikatet i databasen för säker start. Detta gör att Windows kan lita på starthanterare som signerats av det här certifikatet. |
| 2 | 0x0800 | Den här biten instruerar den schemalagda aktiviteten att tillämpa Microsoft Option ROM UEFI CA 2023 på DB. Villkorsstyrt beteende: När 0x4000-flaggan har angetts söker den schemalagda aktiviteten först i databasen efter Microsoft Corporation UEFI CA 2011-certifikatet . Det tillämpar endast Microsoft Option ROM UEFI CA 2023-certifikatetom 2011-certifikatet finns. |
| 3 | 0x1000 | Den här biten instruerar den schemalagda aktiviteten att tillämpa Microsoft UEFI CA 2023 på databasen. Villkorsstyrt beteende: När 0x4000-flaggan har angetts söker den schemalagda aktiviteten först i databasen efter Microsoft Corporation UEFI CA 2011-certifikatet . Det tillämpar endast Microsoft UEFI CA 2023-certifikatetom 2011-certifikatet finns. |
| Modifierare (beteendeflagga) | 0x4000 | Den här biten ändrar beteendet för 0x0800- och 0x1000-bitarna så att Microsoft UEFI CA 2023 och Microsoft Option ROM UEFI CA 2023 endast tillämpas om databasen redan innehåller Microsoft Corporation UEFI CA 2011. För att säkerställa att enhetens säkerhetsprofil förblir densamma tillämpar den här biten endast dessa nya certifikat om enheten litar på Microsoft Corporation UEFI CA 2011-certifikatet. Alla Windows-enheter litar inte på certifikatet. |
| 4 | 0x0004 | Den här biten instruerar den schemalagda aktiviteten att leta efter en nyckelutbytesnyckel som signerats av enhetens plattformsnyckel (PK). PK hanteras av OEM-tillverkaren. OEM-tillverkare signerar Microsoft KEK med sin PK och levererar den till Microsoft där den ingår i månatliga kumulativa uppdateringar. |
| 5 | 0x0100 | Den här biten instruerar den schemalagda aktiviteten att tillämpa starthanteraren, signerad av Windows UEFI CA 2023, på startpartitionen. Detta ersätter den signerade starthanteraren för Microsoft Windows Production PCA 2011 . |
Obs!
- Den 0x4000 biten förblir inställd när alla andra bitar har bearbetats.
- Varje bit bearbetas av den schemalagda aktiviteten Secure-Boot-Update i den ordning som visas ovan.
- Om den 0x0004 biten inte kan bearbetas på grund av att en PK-signerad KEK saknas tillämpar den schemalagda aktiviteten fortfarande starthanteraruppdateringen som anges av bit 0x0100.
Förväntat förlopp (AvailableUpdates)
När en åtgärd slutförs rensar Windows den associerade biten från AvailableUpdates. Om en åtgärd misslyckas loggar Windows en händelse och försöker igen när aktiviteten körs igen.
I tabellen nedan visas den förväntade förloppet för AvailableUpdates-värden när varje uppdateringsåtgärd för säker start slutförs.
| Steg | Bitbearbetade bitar | Tillgängliga uppdateringar | Beskrivning | Lyckad händelse loggad | Möjliga felhändelsekoder |
|---|---|---|---|---|---|
| Start | 0x5944 | Inledande tillstånd innan certifikatunderhåll för säker start påbörjas. | - | - | |
| 1 | 0x0040 | 0x5944 → 0x5904 | Windows UEFI CA 2023 läggs till i databasen för säker start. | 1036 | 1032, 1795, 1796, 1802 |
| 2 | 0x0800 | 0x5904 → 0x5104 | Lägg till Microsoft Option ROM UEFI CA 2023 i databasen om enheten tidigare litade på Microsoft UEFI CA 2011. | 1044 | 1032, 1795, 1796, 1802 |
| 3 | 0x1000 | 0x5104 → 0x4104 | Microsoft UEFI CA 2023 läggs till i databasen om enheten tidigare litade på Microsoft UEFI CA 2011. | 1045 | 1032, 1795, 1796, 1802 |
| 4 | 0x0004 | 0x4104 → 0x4100 | Nya Microsoft KEK 2K CA 2023 signerade av OEM-plattformsnyckeln tillämpas. | 1043 | 1032, 1795, 1796, 1802, 1803 |
| 5 | 0x0100 | 0x4100 → 0x4000 | Boot Manager signerad av Windows UEFI CA 2023 är installerad. | 1799 | 1797 |
Obs!
- När åtgärden som är kopplad till en bit slutförs rensas biten från AvailableUpdates.
- Om någon av dessa åtgärder misslyckas loggas en händelse och åtgärden görs om nästa gång den schemalagda aktiviteten körs.
- Den 0x4000 biten är en modifierare och rensas inte. Det slutliga AvailableUpdates-värdet 0x4000 anger att alla tillämpliga uppdateringsåtgärder har slutförts.
- Händelserna 1032, 1795, 1796 och 1802 anger vanligtvis begränsningar i den inbyggda programvaran eller plattformen.
- Händelse 1803 anger saknad OEM PK-signerad KEK.
Åtgärder för att åtgärda detta
Det här avsnittet innehåller stegvisa anvisningar för att åtgärda specifika problem med säker start. Varje procedur är begränsad till ett väldefinierat tillstånd och är avsedd att följas först efter att den första diagnosen har bekräftat att problemet gäller. Använd de här procedurerna för att återställa förväntat beteende för säker start och tillåta certifikatuppdateringar att fortsätta på ett säkert sätt. Tillämpa inte dessa procedurer brett eller i förebyggande syfte.
Aktivera Säker start i den inbyggda programvaran
Om Säker start är inaktiverat i en enhets inbyggda programvara läser du Windows 11 och Säker start för mer information om hur du aktiverar Säker start.
Schemalagd aktivitet för säker start inaktiverad eller borttagen
Den schemalagda aktiviteten Secure-Boot-Update krävs för att Windows ska tillämpa certifikatuppdateringar för säker start. Om aktiviteten är inaktiverad eller saknas fortskrider inte certifikatunderhållet för säker start.
Information om uppgiften
| Uppgiftsnamn | Säker startuppdatering |
|---|---|
| Aktivitetens sökväg | \Microsoft\Windows\PI\ |
| Fullständig sökväg | \Microsoft\Windows\PI\Secure-Boot-Update |
| Körs som | SYSTEM (lokalt system) |
| Utlösare | Vid start och var 12:e timme |
| Obligatoriskt tillstånd | Aktiverat |
Kontrollera uppgiftsstatus
Kör från en upphöjd PowerShell-kommandotolk:
schtasks.exe /Query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V
Titta efter statusfältet:
| Status | Betydelse |
|---|---|
| Klar | Aktiviteten finns och är aktiverad. |
| Inaktiverad | Aktiviteten finns men måste vara aktiverad. |
| Fel/Hittades inte | Aktiviteten saknas och måste återskapas. |
Aktivera eller återskapa uppgiften
Om statusfältet för Secure-Boot-Update är Inaktiverad, Fel eller Hittades inte använder du exempelskriptet för att aktivera aktiviteten: Exempel Enable-SecureBootUpdateTask.ps1
Obs! Det här är ett exempelskript och stöds inte av Microsoft. Administratörer bör granska och anpassa den till sin miljö.
Exempel:
Obs
.\Enable-SecureBootUpdateTask.ps1 -Tyst
Köra vägledning
- Om åtkomst nekad kör du PowerShell igen som administratör.
- Om skriptet inte körs på grund av körningsprincipen använder du en förbikoppling av processomfånget:
Obs
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass