Felsökningsguide för säker start
Gäller för
Ursprungligt publiceringsdatum: den 19 mars 2026
KB-ID: 5085046
I denna artikel
Översikt
På den här sidan får administratörer och supportpersonal hjälp med att diagnostisera och lösa problem med säker start på Windows-enheter. Ämnena omfattar fel vid uppdatering av certifikat för säker start, felaktiga statusar för säker start, oväntade BitLocker-återställningsupp uppmaningar och startfel efter ändringar i konfigurationen för säker start.
I anvisningarna förklaras hur du verifierar underhåll och konfiguration av Windows, granskar relevanta registervärden och händelseloggar och identifierar när begränsningar för inbyggd programvara eller plattform kräver en OEM-uppdatering. Det här innehållet är avsett 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 vägledning identifieras.
Så här fungerar säker start-certifikatunderhåll
Säker start-certifikatunderhåll i Windows är en samordnad process mellan operativsystemet och enhetens 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 Aktivitet i Windows, en registerbaserad sekvens av uppdateringsåtgärder och inbyggd loggnings- och försöksfunktion. Tillsammans säkerställer dessa komponenter att Certifikat för säker start och Windows-starthanteraren uppdateras på ett kontrollerat, ordnat sätt och först efter att nödvändiga steg har slutförts.
Var du ska börja vid felsökning
När en enhet inte verkar göra förväntade framsteg med att tillämpa certifikatuppdateringar för säker start börjar du med att identifiera problemets kategori. De flesta problem faller inom något av fyra områden: Underhållstillstånd för Windows, uppdateringsmekanismen för säker start, beteende för inbyggd programvara eller en plattform eller OEM-begränsning.
Börja med kontrollerna nedan, i ordning. I många fall är de här stegen tillräckliga för att förklara det observerade beteendet och bestämma nästa åtgärder utan djupare undersökning.
-
Bekräfta uppgraderingen av Windows-tjänster och -plattformar
-
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 bör du åtgärda dem innan du fortsätter med ytterligare felsökning.
-
-
Kontrollera statusen för uppgiften Säker start-uppdatering
-
Kontrollera att Windows-mekanismen som ansvarar för att tillämpa certifikatuppdateringar för säker start är närvarande och fungerar:
-
Den schemalagda uppgiften Secure-Boot-Update finns.
-
Uppgiften aktiveras och körs som lokalt system.
-
Aktiviteten har körts minst en gång sedan den senaste Windows-säkerhetsuppdateringen installerades.
-
Om uppgiften är inaktiverad, borttagen eller inte körs kan inte uppdateringar av certifikat för säker start tillämpas. 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 underhållstillstånd för säker start i registret:
-
Undersöka UEFICA2023Status, UEFICA2023Fel och UEFICA2023ErrorEvent.
-
Undersök AvailableUpdates och jämför det med förväntat förlopp (se Referens och Internals).
Tillsammans anger dessa värden om underhållet fortskrider normalt, försöker igen eller stannar vid ett visst steg.
-
-
Korrelera registertillstånd med säker start-händelser
Granska Secure Boot-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 en inbyggd programvara eller ett plattformsproblem.
Tillsammans anger register- och händelseloggarna vanligtvis om beteendet är förväntat, tillfälligt eller kräver korrigerande åtgärder.
Schemalagd aktivitet med säker start-uppdatering
Säker start-certifikatunderhåll implementeras via en schemalagd Windows-aktivitet med namnet Secure-Boot-Update. Aktiviteten registreras på följande sökväg:
\Microsoft\Windows\PI\Secure-Boot-Update
Aktiviteten körs som Lokalt system. Som standard körs den vid systemstart och var 12:e timme därefter. Varje gång den körs kontrollerar den om å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 kan inte uppdateringar av certifikat för säker start tillämpas. Uppgiften Secure-Boot-Update måste vara aktiverad för att säker start ska fungera.
Varför en schemalagd aktivitet används
Certifikatuppdateringar för säker start kräver samordning mellan Windows och inbyggd UEFI-programvara, inklusive att skriva UEFI-variabler som lagrar nycklar och certifikat för säker start. En schemalagd aktivitet gör att Windows kan försöka med 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 igen om ett tidigare försök misslyckades eller om enheten var påslagen utan omstart. Den här designen säkerställer framåtskridning utan manuell ingrepp.
Registerbitmasken AvailableUpdates
Uppgiften Secure-Boot-Update drivs av registervärdet AvailableUpdates . Det här värdet är en 32-bitars bitmask som finns vid:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Varje bit i värdet representerar en specifik uppdateringsåtgärd för Säker start. Uppdateringsprocessen startar när AvailableUpdates är inställt på ett värde som inte är 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 uppgiften Secure-Boot-Update körs tolkas de angivna bitarna som väntande arbete och bearbetar dem i en definierad ordning.
Sekventiella uppdateringar, loggning och fö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öras oberoende av varandra. Uppgiften 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. Windows registrerar resultatet av varje steg i systemhändelseloggen. Lyckade händelser bekräftar vidarebefordrans förlopp, 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 bituppsättningen. Åtgärden görs på nytt nästa gång aktiviteten körs. Det här beteendet gör att enheter kan återställas automatiskt från tillfälliga förhållanden, till exempel att stöd för inbyggd programvara saknas eller fördröjda OEM-uppdateringar.
Administratörer kan spåra förloppet genom att korrelera registertillståndet med händelseloggposter. Registervärden som UEFICA2023Status, UEFICA2023Fel och UEFICA2023ErrorEvent samt AvailableUpdates-bitmask anger vilket steg som är aktivt, slutfört eller blockerat.
Den här kombinationen visar om enheten fortskrider normalt, försöker igen eller stannar.
Integrering med inbyggd OEM-programvara
Uppdateringar av certifikat för säker start beror på korrekt beteende och stöd i enhetens inbyggda UEFI-programvara. Windows orkestrerar uppdateringsprocessen, men den inbyggda programvaran ansvarar för att tillämpa principen för säker start och underhålla databaserna för säker start.
OEM-tillverkare tillhandahåller två viktiga element som aktiverar säker start-certifikatunderhåll:
-
Plattformsnyckelsignerade Tangent-Exchange-nycklar (KEK:er) som godkänner installation av nya certifikat för säker start.
-
Implementeringar av inbyggd programvara som bevarar, lägger till och validerar databaser för säker start korrekt under uppdateringar.
Om den inbyggda programvaran inte stöder 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 ändringar i den inbyggda programvaran.
Microsoft samarbetar med OEM-tillverkare för att identifiera problem med inbyggd programvara och göra korrigerade uppdateringar tillgängliga. När felsökning anger en begränsning eller defekt för inbyggd programvara kan administratörer behöva installera den senaste UEFI-uppdateringen som tillhandahålls av enhetstillverkaren innan uppdateringar av certifikat för säker start kan slutföras.
Vanliga felscenarier och lösningar
Uppdateringar för säker start tillämpas av den schemalagda uppgiften 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 funktioner för inbyggd programvara, plattformskonfiguration och underhållsförutsättningar förhindra förlopp eller leda till oväntat startbeteende.
I avsnitten nedan beskrivs 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 åtgärd. Scenarier sorteras från vanligast förekommande till mer allvarliga fall av startpåverkan.
När uppdateringar för Säker start inte visar några framsteg innebär det vanligtvis att uppdateringsprocessen aldrig har startats. Därför saknas de förväntade registervärdena och händelseloggarna för Säker start 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 det
-
Det finns inga registervärden för underhåll av säker start, till exempel UEFICA2023Status.
-
Förväntade händelser för säker start (till exempel 1043, 1044, 1045, 1799 och 1801) saknas i systemhändelseloggen.
-
Enheten fortsätter att använda äldre certifikat för säker start och startkomponenter.
Varför det händer
Det här scenariot inträffar vanligtvis när ett eller flera av följande villkor uppfylls:
-
Den schemalagda uppgiften Säker start-uppdatering är inaktiverad eller saknas.
-
Säker start är inaktiverat i den inbyggda UEFI-programvaran.
-
Enheten uppfyller inte underhållsförutsättningarna för Windows, till exempel om du kör en Windows-version som stöds eller har nödvändiga uppdateringar installerade.
Vad ska jag göra härnäst?
-
Kontrollera att enheten uppfyller kraven för underhåll och plattform för Windows.
-
Kontrollera att Säker start är aktiverat i den inbyggda programvaran.
-
Kontrollera att den schemalagda SecureBootUpdate-aktiviteten finns och är aktiverad.
Om den schemalagda aktiviteten är inaktiverad eller saknas följer du anvisningarna i Säker start schemalagd aktivitet inaktiverad eller borttagen för att återställa den. När uppgiften har återställts startar du om enheten eller kör uppgiften manuellt för att starta säker start-underhåll.
I vissa fall kan säker start-relaterade uppdateringar göra att en enhet anger BitLocker-återställning. Beteendet kan vara tillfälligt eller beständigt, beroende på den underliggande orsaken.
Scenario 1: Onetime BitLocker-återställning efter säker start-uppdatering
Vad som händer
Enheten går in i BitLocker-återställningen vid den första starten efter säker start-uppdateringen, 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 att återförsluta BitLocker. Detta orsakar en tillfällig matchning i uppmätta startvärden och utlöser en återställning. Vid nästa start rapporterar inbyggd programvara de uppdaterade värdena korrekt, BitLocker återförsluts korrekt och problemet återkommer inte.
Så här känner du igen det
-
BitLocker-återställning sker en gång.
-
När du har angett återställningsnyckeln uppmanas inte återställningen att startas.
-
Ingen pågående startordning eller PXE-inblandning finns.
Vad ska jag göra 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 första startkonfigurationen
Vad som händer
Enheten går in i BitLocker-återställning vid varje start.
Varför det händer
Enheten konfigureras 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 leder till att två olika signeringsmyndigheter mäts under en enskild startcykel:
-
PXE-startsökvägen är signerad av Microsoft UEFI CA 2011.
-
Starthanteraren för Windows på disk är signerad av Windows UEFI CA 2023.
Eftersom BitLocker observerar olika säkerhetskedjor för säker start vid start kan det inte upprätta en stabil uppsättning TPM-mått att återförsluta mot. Därför återställs BitLocker vid varje start.
Så här känner du igen det
-
BitLocker-återställning utlöses vid varje omstart.
-
Om du anger återställningsnyckeln kan Windows starta, men uppmaningen returneras vid nästa start.
-
PXE eller nätverksstart konfigureras före den lokala disken i startordning för inbyggd programvara.
Vad ska jag göra härnäst?
-
Konfigurera startordningen för den inbyggda programvaran så att starthanteraren för Windows på disken är först.
-
Inaktivera PXE-start om det inte krävs.
-
Om PXE krävs kontrollerar du att PXE-infrastrukturen använder en 2023-signerad Windows-startinläsningsprogram.
Vad hände
Detta återspeglar en ändring på den inbyggda programvaran i stället för ett Windows-problem. Uppdateringen för säker start slutfördes, men efter en senare omstart startar enheten inte längre i Windows.
Så här känner du igen det
-
Enheten startar inte Windows och kan visa ett meddelande om inbyggd programvara eller BIOS som anger ett fel vid säker start.
-
Felet inträffar när inställningarna för säker start återställs till standardinställningarna för den inbyggda programvaran.
-
Om du inaktiverar Säker start kan enheten startas igen.
Varför det händer
Om du återställer Säker start till den inbyggda programvaran rensas databaserna för säker start som lagras i den inbyggda programvaran. På enheter som redan har gått över till den Windows UEFI CA 2023-signerade starthanteraren tar den här återställningen bort de certifikat som krävs för att kunna lita på starthanteraren.
Därför känner den inbyggda programvaran inte längre igen den installerade Windows-starthanteraren som betrodd och blockerar startprocessen.
Det här scenariot orsakas inte av själva uppdateringen för säker start utan av en efterföljande åtgärd för inbyggd programvara som tar bort de uppdaterade fästpunkterna för förtroende.
Vad ska jag göra 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 startas igen.
-
Efter återställningen kontrollerar du att enheten har den senaste inbyggda programvaran installerad från enhetstillverkaren.
-
Undvik att återställa Säker start till standardvärden för inbyggd programvara om inte OEM-tillverkarens 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 juli 2024 eller senare Windows-uppdatering 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 DB.
När certifikatet har återställts och systemet har startats om ska Windows starta som vanligt.
Viktigt: Den här processen återanvänder bara ett av de nya certifikaten. När enheten har återställts kontrollerar du att den har de senaste certifikaten på nytt och överväger att uppdatera systemets BIOS/UEFI till den senaste versionen som är tillgänglig. Det kan förhindra återkommande problem med återställning av säker start, eftersom många OEM-tillverkare har släppt korrigeringar för den inbyggda programvaran för det här specifika problemet.
Vad hände
När certifikatuppdateringen för Säker start har installerats och startats om går det inte att starta enheten och den når inte Windows.
Så här känner du igen det
-
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 startas.
Varför det händer
Det här problemet kan orsakas av ett fel i enhetens UEFI-implementering av inbyggd 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åtna signaturer för säker start (DB). Vissa implementeringar av inbyggd programvara skriver felaktigt över DB i stället för att lägga till det.
När detta inträffar
-
Tidigare har betrodda certifikat, inklusive Microsoft 2011 bootloader-certifikat, tagits bort.
-
Om systemet fortfarande använder en starthanterare som är signerad med 2011-certifikatet då, litar den inbyggda programvaran inte längre på den.
-
Den inbyggda programvaran avvisar starthanteraren och blockerar startprocessen.
I vissa fall kan DB också skadas i stället för att skrivas över helt, 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.
Vad ska jag göra härnäst?
-
Ange installationsmenyerna för den inbyggda programvaran och försök återställa inställningarna för säker start.
-
Om enheten startar efter återställningen kan du söka efter en uppdatering av den inbyggda programvaran på tillverkarens supportwebbplats som korrigerar säker start DB-hantering.
-
Om det finns en tillgänglig uppdatering av den inbyggda programvaran installerar du den innan du aktiverar Säker start på nytt och återapplicerar certifikatuppdateringar för säker start.
Om återställning av Säker start inte återställer startfunktionen krävs troligen OEM-specifik vägledning för ytterligare återställning.
Vad hände
Certifikatuppdateringen för säker start är inte slutförd och är fortfarande blockerad i uppdateringssteget för Nyckel exchange-nyckel (KEK).
Så här känner du igen det
-
Registervärdet AvailableUpdates förblir inställt med KEK-biten (0x0004) och rensas inte.
-
UEFICA2023Status fortsätter inte till ett slutfört tillstånd.
-
Systemhändelseloggen registrerar händelse-ID 1803 upprepade gånger, vilket indikerar att KEK-uppdateringen inte kunde tillämpas.
-
Enheten fortsätter att försöka med uppdateringen utan att göra några framsteg framåt.
Varför det händer
Uppdatering av KEK för säker start kräver 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 det möjligt för Windows att uppdatera kek-variabeln för inbyggd programvara.
Om OEM-tillverkaren inte har tillhandahållit ett PK-signerat KEK för enheten kan Windows inte slutföra KEK-uppdateringen. I det här läget:
-
Uppdateringar för säker start blockeras av design.
-
Windows kan inte kringgå den saknade auktoriseringen.
-
Enheten kan inte slutföra säker start-certifikatunderhåll permanent.
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ällningssökväg som stöds för det här villkoret.
När uppdateringar av certifikat 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 start-signatur (DB) eller KEK (Key Exchange Key) kan inte slutföras på ett säkert sätt på grund av inbyggd programvara, plattformstillstånd eller konfigurationsvillkor. Scenarierna i det här avsnittet refererar till dessa händelser för att identifiera vanliga felmönster och fastställa lämplig åtgärd. Det här avsnittet är avsett att stödja diagnos och tolkning av problem som beskrivits tidigare, inte för att införa nya felscenarier.
En fullständig lista över händelse-ID:er, beskrivningar och exempelposter finns i Avsnittet om säker start av DB- och DBX-uppdateringshändelser (KB5016061).
KEK-uppdateringsfel (DB-uppdateringar lyckas, KEK gör det inte)
En enhet kan uppdatera certifikat i SÄKER start DB men misslyckas under KEK-uppdateringen. När detta inträffar går det inte att slutföra uppdateringsprocessen för säker start.
Symtom
-
DB-certifikathändelser indikerar förlopp, men KEK-steget är inte slutfört.
-
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 anger vanligtvis ett fel i den inbyggda programvaran när du försöker uppdatera en variabel för säker start.
-
1803 anger att KEK-uppdateringen inte kan godkännas eftersom en obligatorisk 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 OEM-programvara och validerar stöd för inbyggd programvara för uppdateringar av variabeln Säker start.
-
För 1803 kontrollerar du om OEM-tillverkaren har försett Microsoft med det PK-signerade KEK som krävs för enhetsmodellen.
KEK-uppdateringsfel på virtuella gästdatorer med Hyper-V som värd
På virtuella Hyper-V-datorer måste Windows-uppdateringarna för säker start 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 åtgärd 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 den virtuella gästdatorn saknar uppdateringen för mars 2026 och måste uppdateras.
Referens och internt
Det här avsnittet innehåller avancerad referensinformation avsedd för felsökning och support. Den är inte avsedd för distributionsplanering. Den expanderar underhållsmekaniken för säker start som sammanfattats tidigare och innehåller detaljerat referensmaterial för tolkning av registertillstånd och händelseloggar.
Obs! (IT-hanterade distributioner): När du konfigurerar via grupprincip eller Microsoft Intune ska två liknande inställningar inte förväxlas. Värdet AvailableUpdatesPolicy representerar det konfigurerade principtillståndet. Samtidigt återspeglar AvailableUpdates det pågående arbetet med bitrensning. Båda kan driva samma resultat, men de beter sig annorlunda eftersom politiken tillämpas igen med tiden.
AvailableUpdates bits used for certificate servicing
Bitarna nedan används för de åtgärder för certifikat och starthanteraren som beskrivs i det här dokumentet. Kolumnen Order återspeglar sekvensen i vilken uppgiften Secure-Boot-Update bearbetar varje bit.
|
Order |
Bitinställning |
Användning |
|---|---|---|
|
1 |
0x0040 |
Den här biten berättar för den schemalagda aktiviteten att lägga till Windows UEFI CA 2023-certifikatet i Secure Boot DB. Det gör att Windows kan lita på starthanterare som är signerade av certifikatet. |
|
2 |
0x0800 |
Den här biten talar om för den schemalagda aktiviteten att tillämpa Microsoft Option ROM UEFI CA 2023 på DB. Villkorsstyrd funktion: När 0x4000-flaggan anges kontrollerar den schemalagda aktiviteten först databasen efter certifikatet Microsoft Corporation UEFI CA 2011 . Microsoft Option ROM UEFI CA 2023-certifikat tillämpas endast om 2011-certifikatet finns. |
|
3 |
0x1000 |
Den här biten anger att den schemalagda aktiviteten ska tillämpa Microsoft UEFI CA 2023 på DB. Villkorsstyrd funktion: När 0x4000-flaggan har angetts kontrollerar den schemalagda aktiviteten först databasen efter certifikatet Microsoft Corporation UEFI CA 2011 . Microsoft UEFI CA 2023-certifikatet tillämpas endast om 2011-certifikatet finns. |
|
Modifierare (beteendeflagga) |
0x4000 |
Den här biten ändrar beteendet för 0x0800 och 0x1000 bitar så att Microsoft UEFI CA 2023 och Microsoft Option ROM UEFI CA 2023 endast tillämpas om DB redan innehåller Microsoft Corporation UEFI CA 2011. För att säkerställa att enhetens säkerhetsprofil förblir densamma gäller den här biten endast dessa nya certifikat om enheten litar på Microsoft Corporation UEFI CA 2011-certifikatet. Det är inte alla Windows-enheter som litar på certifikatet. |
|
4 |
0x0004 |
Den här biten anger att den schemalagda aktiviteten ska leta efter en Key Exchange-nyckel som signerats av enhetens plattformsnyckel (PK). PK hanteras av OEM-tillverkaren. OEM-tillverkare signerar Microsoft KEK med sitt PK och levererar det till Microsoft där det ingår i månatliga kumulativa uppdateringar. |
|
5 |
0x0100 |
Den här biten talar om för 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 uppgiften Secure-Boot-Update i den ordning som visas ovan.
-
Om den 0x0004 biten inte kan bearbetas på grund av att ett PK-signerat KEK saknas, kommer den schemalagda aktiviteten fortfarande att tillämpa uppdateringen av starthanteraren som anges av bit 0x0100.
Förväntad progression (AvailableUpdates)
När en åtgärd har slutförts 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 förväntad status för AvailableUpdates-värden när varje uppdateringsåtgärd för Säker start slutförs.
|
Steg |
Bit bearbetad |
Tillgänglig Uppdateringar |
Beskrivning |
Lyckad händelse loggad |
Möjliga felhändelsekoder |
|---|---|---|---|---|---|
|
Start |
0x5944 |
Ursprungligt tillstånd innan säker start av certifikatunderhåll påbörjas. |
- |
- |
|
|
1 |
0x0040 |
0x5944 → 0x5904 |
Windows UEFI CA 2023 läggs till i Säker start DB. |
1036 |
1032, 1795, 1796, 1802 |
|
2 |
0x0800 |
0x5904 → 0x5104 |
Lägg till Microsoft Option ROM UEFI CA 2023 i DB 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 DB om enheten tidigare litade på Microsoft UEFI CA 2011. |
1045 |
1032, 1795, 1796, 1802 |
|
4 |
0x0004 |
0x4104 → 0x4100 |
Nya Microsoft KEK 2K CA 2023 som signerats av OEM-plattformsnyckeln tillämpas. |
1043 |
1032, 1795, 1796, 1802, 1803 |
|
5 |
0x0100 |
0x4100 → 0x4000 |
Starthanteraren som är signerad av Windows UEFI CA 2023 är installerad. |
1799 |
1797 |
Anmärkningar
-
När åtgärden som är kopplad till en bit har slutförts rensas den biten från AvailableUpdates.
-
Om någon av dessa åtgärder misslyckas loggas en händelse och åtgärden görs på nytt nästa gång den schemalagda aktiviteten körs.
-
Den 0x4000 biten är en modifierare och rensas inte. Ett slutligt AvailableUpdates-värde för 0x4000 anger att alla tillämpliga uppdateringsåtgärder har slutförts.
-
Händelser 1032, 1795, 1796, 1802 anger vanligtvis begränsningar för inbyggd programvara eller plattform.
-
Händelse 1803 indikerar att OEM PK-signerad KEK saknas.
Åtgärder
Det här avsnittet innehåller stegvisa procedurer 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 bekräftar 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 att certifikatuppdateringarna fortsätter på ett säkert sätt. Använd inte de här procedurerna i stort eller i förebyggande syfte.
Aktivera Säker start i inbyggd programvara
Om Säker start är inaktiverat i en enhets inbyggda programvara finns mer information om hur du aktiverar Säker start i Windows 11 och Säker start.
Säker start-schemalagd aktivitet inaktiverad eller borttagen
Den schemalagda uppgiften Secure-Boot-Update krävs för att Windows ska kunna tillämpa certifikatuppdateringar för säker start. Om uppgiften är inaktiverad eller saknas fortsätter inte underhåll av certifikat för säker start.
Uppgiftsinformation
|
Aktivitetsnamn |
Secure-Boot-Update |
|
Aktivitetssö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 |
Aktiverad |
Så här kontrollerar du aktivitetsstatus
Kör från en Upphöjd PowerShell-uppmaning: schtasks.exe /Query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V
Leta efter fältet Status:
|
Status |
Betydelse |
|---|---|
|
Redo |
Aktiviteten finns och är aktiverad. |
|
Inaktiverad |
Aktiviteten finns men måste vara aktiverad. |
|
Fel / Hittades inte |
Uppgiften saknas och måste återskapas. |
Så här aktiverar eller återskapar du uppgiften
Om statusfältet för Säker start-uppdatering är inaktiverat, Fel eller Hittades inte använder du exempelskriptet för att aktivera uppgiften: 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:
.\Enable-SecureBootUpdateTask.ps1 -Quiet
Kör vägledning
-
Om Access nekas 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 processomfattning:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Behöver du mer hjälp?
Vill du ha fler alternativ?
Utforska prenumerationsförmåner, bläddra bland utbildningskurser, lär dig hur du skyddar din enhet med mera.
Communities hjälper dig att ställa och svara på frågor, ge feedback och få råd från experter med rika kunskaper.
