Fejlfinding
Gælder for
Oprindelig publiceringsdato: 19. marts 2026
KB-id: 5085046
I denne artikel
Oversigt
Denne side vejleder administratorer og supportmedarbejdere i diagnosticering og løsning af problemer med sikker bootstart på Windows-enheder. Emnerne omfatter fejl i forbindelse med sikker bootstartcertifikatopdatering, forkerte secure boot-tilstande, uventede BitLocker-genoprettelsesprompter og startfejl efter konfigurationsændringer for sikker bootstart.
Vejledningen forklarer, hvordan du kontrollerer vedligeholdelse og konfiguration af Windows, gennemser relevante registreringsdatabaseværdier og hændelseslogge og identificerer, hvornår firmware- eller platformbegrænsninger kræver en OEM-opdatering. Dette indhold er beregnet til at diagnosticere problemer på eksisterende enheder. Det er ikke beregnet til planlægning af nye installationer. Dette dokument opdateres, efterhånden som der identificeres nye fejlfindingsscenarier og vejledning.
Sådan fungerer vedligeholdelse af certifikat til sikker bootstart
Sikker bootstartcertifikatvedligeholdelse på Windows er en koordineret proces mellem operativsystemet og en enheds UEFI-firmware. Målet er at opdatere kritiske tillidsankre, samtidig med at muligheden for at starte i hvert trin bevares.
Processen styres af en planlagt Windows-opgave, en registreringsdatabasebaseret sekvens af opdateringshandlinger og indbygget logføring og funktionsmåde for forsøg. Disse komponenter sikrer sammen, at certifikater til sikker bootstart og Windows Boot Manager opdateres på en kontrolleret, sorteret måde, og kun når de nødvendige trin lykkes.
Her skal du starte, når du foretager fejlfinding
Når en enhed ikke ser ud til at gøre forventede fremskridt i forbindelse med anvendelse af sikker bootstartcertifikatopdateringer, skal du starte med at identificere kategorien for problemet. De fleste problemer falder ind under et af fire områder: Windows-servicetilstand, sikker bootstart-opdateringsmekanisme, firmwarefunktionsmåde eller en platform eller OEM-begrænsning.
Begynd med nedenstående kontroller i rækkefølge. I mange tilfælde er disse trin tilstrækkelige til at forklare den observerede adfærd og bestemme næste handlinger uden dybere undersøgelse.
-
Bekræft berettigelse til Windows-vedligeholdelse og platform
-
Kontrollér, at enheden opfylder de grundlæggende krav for at modtage opdateringer af certifikat til sikker bootstart:
-
Enheden kører en understøttet version af Windows.
-
De seneste påkrævede Windows-sikkerhedsopdateringer er installeret.
-
Sikker bootstart er aktiveret i UEFI-firmware.
-
Hvis nogen af disse betingelser ikke er opfyldt, skal du løse dem, før du fortsætter med yderligere fejlfinding.
-
-
Bekræft opgavestatus for Sikker bootstart-opdatering
-
Bekræft, at den Windows-mekanisme, der er ansvarlig for at anvende opdateringer af certifikat til sikker bootstart, findes og fungerer:
-
Den planlagte opgave Sikker bootstart-opdatering findes.
-
Opgaven er aktiveret og kører som Lokalt system.
-
Opgaven er kørt mindst én gang, siden den seneste Windows-sikkerhedsopdatering blev installeret.
-
Hvis opgaven er deaktiveret, slettet eller ikke kører, kan certifikatopdateringer til sikker bootstart ikke anvendes. Fejlfinding bør fokusere på at gendanne opgaven, før du undersøger andre årsager.
-
-
Kontrollér indstillinger i registreringsdatabasen for forventet forløb
Gennemse enhedens tjenestetilstand for sikker bootstart i registreringsdatabasen:
-
Undersøg UEFICA2023Status, UEFICA2023Error og UEFICA2023ErrorEvent.
-
Undersøg AvailableUpdates , og sammenlign det med det forventede forløb (se Reference og Interne).
Disse værdier angiver sammen, om vedligeholdelsen skrider normalt frem, om en handling skal forsøges igen, eller om den er gået i stå på et bestemt trin.
-
-
Korreler registreringstilstand med hændelser for sikker bootstart
Gennemse Secure Boot-relaterede hændelser i systemhændelsesloggen, og korreler dem med registreringsdatabasens tilstand. Hændelsesdata bekræfter typisk, om enheden gør fremskridt, forsøger igen på grund af en forbigående tilstand eller er blokeret af et firmware- eller platformproblem.
Registreringsdatabasen og hændelseslogfilerne angiver normalt, om funktionsmåden er forventet, midlertidig eller kræver korrigerende handling.
Sikker bootstart-opdatering planlagt opgave
Certifikatvedligeholdelse af sikker bootstart implementeres via en Planlagt Windows-opgave med navnet Sikker bootstart-opdatering. Opgaven er registreret på følgende sti:
\Microsoft\Windows\PI\Secure-Boot-Update
Opgaven kører som lokalt system. Som standard kører den ved systemstart og hver 12 timer derefter. Hver gang den kører, kontrollerer den, om opdateringshandlinger for sikker bootstart venter, og forsøger at anvende dem i rækkefølge.
Hvis denne opgave er deaktiveret eller mangler, kan certifikatopdateringer til sikker bootstart ikke anvendes. Opgaven Secure Boot-Update skal forblive aktiveret, for at servicering af sikker bootstart kan fungere.
Derfor bruges en planlagt opgave
Opdateringer af certifikat til sikker bootstart kræver koordinering mellem Windows- og UEFI-firmware, herunder skrivning af UEFI-variabler, der gemmer nøgler og certifikater til sikker bootstart. En planlagt opgave gør det muligt for Windows at forsøge disse opdateringer, når systemet er i en tilstand, hvor firmwarevariabler kan ændres.
Den tilbagevendende 12-timers tidsplan giver yderligere muligheder for at prøve opdateringer igen, hvis et tidligere forsøg mislykkedes, eller hvis enheden forblev tændt uden at genstarte. Dette design er med til at sikre fremadrettede fremskridt uden at kræve manuel indgriben.
Bitmasken AvailableUpdates i registreringsdatabasen
Opgaven Sikker bootstart-opdatering styres af registreringsdatabaseværdien AvailableUpdates . Denne værdi er en 32-bit bitmaske, der er placeret i:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Hver bit i værdien repræsenterer en bestemt sikker bootstartopdateringshandling. Opdateringsprocessen starter, når AvailableUpdates er indstillet til en værdi, der ikke er nul, enten automatisk af Windows eller eksplicit af en administrator. En værdi som f.eks. 0x5944 angiver f.eks., at flere opdateringshandlinger venter.
Når opgaven Sikker bootstart-opdatering kører, fortolker den sættet som ventende arbejde og behandler dem i en defineret rækkefølge.
Sekventielle opdateringer, logføring og funktionsmåde for prøv igen
Opdateringer af certifikat til sikker bootstart anvendes i en fast rækkefølge. Hver opdateringshandling er designet til at være sikker til at prøve igen og fuldføres enkeltvis. Opgaven Sikker bootstart-opdatering går ikke videre til næste trin, før den aktuelle handling lykkes, og dens tilsvarende bit fjernes fra AvailableUpdates.
Hver handling bruger UEFI-standardgrænseflader til at opdatere variabler for sikker bootstart, f.eks. DB og KEK, eller til at installere den opdaterede Windows Boot Manager. Windows registrerer resultatet af hvert trin i systemhændelsesloggen. Vellykkede hændelser bekræfter fremadrettet fremgang, mens fejlhændelser angiver, hvorfor en handling ikke kunne fuldføres.
Hvis et opdateringstrin mislykkes, stopper opgaven med at behandle, logger fejlen og lader det tilknyttede bitsæt være. Handlingen udføres igen, næste gang opgaven kører. Denne funktionsmåde for nye forsøg gør det muligt for enheder at genoprette automatisk efter midlertidige forhold, f.eks. manglende firmwareunderstøttelse eller forsinkede OEM-opdateringer.
Administratorer kan spore status ved at korrelere registreringsdatabasetilstanden med hændelseslogposter. Registreringsdatabaseværdier som F.eks. UEFICA2023Status, UEFICA2023Error og UEFICA2023ErrorEvent angiver sammen med AvailableUpdates-bitmasken , hvilket trin der er aktivt, fuldført eller blokeret.
Denne kombination viser, om enheden skrider frem normalt, forsøger at udføre en handling igen eller går i stå.
Integration med OEM-firmware
Opdateringer af certifikat til sikker bootstart afhænger af den korrekte funktionsmåde og understøttelse i en enheds UEFI-firmware. Mens Windows organiserer opdateringsprocessen, er firmwaren ansvarlig for at gennemtvinge politikken for sikker bootstart og vedligeholde Secure Boot-databaserne.
OEM'er leverer to vigtige elementer, der aktiverer vedligeholdelse af certifikat til sikker bootstart:
-
Platform Key–signed Key Exchange Keys (KEKs), der godkender installation af nye certifikater til sikker bootstart.
-
Firmwareimplementeringer, der korrekt bevarer, tilføjer og validerer Secure Boot-databaser under opdateringer.
Hvis firmwaren ikke understøtter disse funktionsmåder fuldt ud, kan opdateringer til sikker bootstart gå i stå, prøve igen på ubestemt tid eller resultere i startfejl. I disse tilfælde kan Windows ikke fuldføre opdateringen uden ændringer af firmwaren.
Microsoft samarbejder med OEM'er om at identificere firmwareproblemer og gøre de rette opdateringer tilgængelige. Når fejlfinding angiver en firmwarebegrænsning eller -fejl, skal administratorer muligvis installere den nyeste UEFI-firmwareopdatering, der leveres af enhedsproducenten, før sikker bootstartcertifikatopdateringer kan fuldføres.
Almindelige fejlscenarier og løsninger
Opdateringer til sikker bootstart anvendes af den planlagte opgave Secure-Boot-Update baseret på registreringstilstanden AvailableUpdates i registreringsdatabasen.
Under normale forhold udføres disse trin automatisk og registrerer succeshændelser, efterhånden som hver fase fuldføres. I nogle tilfælde kan firmwarefunktionsmåder, platformkonfiguration eller vedligeholdelsesforudsætninger forhindre status eller medføre uventet startfunktionsmåde.
I afsnittene herunder beskrives de mest almindelige fejlscenarier, hvordan du genkender dem, hvorfor de opstår, og de relevante næste trin til at gendanne normal drift. Scenarier sorteres fra de mest almindeligt forekommende til mere alvorlige bootkonsekvenser.
Når opdateringer til sikker bootstart ikke viser nogen status, betyder det typisk, at opdateringsprocessen aldrig er startet. Derfor mangler de forventede værdier i registreringsdatabasen for sikker bootstart og hændelseslogge, fordi opdateringsmekanismen aldrig blev udløst.
Hvad skete der
Processen til opdatering af sikker bootstart startede ikke, så der blev ikke anvendt nogen certifikater til sikker bootstart eller opdateret bootstyring på enheden.
Sådan genkender du den
-
Der findes ingen værdier for vedligeholdelse af sikker bootstart i registreringsdatabasen, f.eks . UEFICA2023Status.
-
Forventede Secure Boot-hændelser (f.eks. 1043, 1044, 1045, 1799, 1801) mangler i systemhændelsesloggen.
-
Enheden fortsætter med at bruge ældre certifikater til sikker bootstart og startkomponenter.
Derfor sker det
Dette scenarie opstår typisk, når en eller flere af følgende betingelser gælder:
-
Den planlagte opgave Sikker bootstart-opdatering er deaktiveret eller mangler.
-
Sikker bootstart er deaktiveret i UEFI-firmware.
-
Enheden opfylder ikke Windows-vedligeholdelsesforudsætninger, f.eks. kørsel af en understøttet Windows-version eller installation af påkrævede opdateringer.
Hvad kan du gøre bagefter?
-
Kontrollér, at enheden opfylder Windows-krav til servicering og platformberettigelse.
-
Bekræft, at Sikker bootstart er aktiveret i firmware.
-
Sørg for, at den planlagte SecureBootUpdate-opgave findes og er aktiveret.
Hvis den planlagte opgave er deaktiveret eller mangler, skal du følge vejledningen i planlagt sikker bootstart-opgave deaktiveret eller slettet for at gendanne den. Når opgaven er gendannet, skal du genstarte enheden eller køre opgaven manuelt for at starte vedligeholdelse af sikker bootstart.
I nogle tilfælde kan sikker bootstartrelaterede opdateringer medføre, at en enhed starter BitLocker-genoprettelse. Funktionsmåden kan være forbigående eller vedvarende, afhængigt af den underliggende årsag.
Scenarie 1: Engangs-BitLocker-genoprettelse efter sikker bootstartopdatering
Hvad sker der?
Enheden starter BitLocker-genoprettelsen på den første start efter sikker bootstart, men starter normalt ved efterfølgende genstart.
Derfor sker det
Under den første start efter opdateringen rapporterer firmwaren endnu ikke de opdaterede værdier for sikker bootstart, når Windows forsøger at reseal BitLocker. Dette medfører en midlertidig uoverensstemmelse i målte startværdier og udløser genoprettelse. Ved næste start rapporterer firmwaren de opdaterede værdier korrekt, BitLocker genseals korrekt, og problemet opstår ikke igen.
Sådan genkender du den
-
BitLocker-genoprettelse sker én gang.
-
Når du har indtastet genoprettelsesnøglen, spørger efterfølgende bootstart ikke genoprettelse.
-
Der er ingen igangværende startrækkefølge eller PXE-involvering.
Hvad kan du gøre bagefter?
-
Angiv BitLocker-genoprettelsesnøglen for at fortsætte Windows.
-
Søg efter firmwareopdateringer.
Scenarie 2: Gentaget BitLocker-genoprettelse på grund af første startkonfiguration af PXE
Hvad sker der?
Enheden skifter til BitLocker-genoprettelse på hver start.
Derfor sker det
Enheden er konfigureret til først at forsøge at starte PXE (netværk). PXE-startforsøget mislykkes, og firmwaren går derefter tilbage til Windows Boot Manager på disken.
Dette resulterer i , at to forskellige signeringsmyndigheder måles i løbet af en enkelt startcyklus:
-
PXE-startstien er signeret af Microsoft UEFI CA 2011.
-
Windows Boot Manager på disken er signeret af Windows UEFI CA 2023.
Da BitLocker registrerer forskellige tillidskæder til sikker bootstart under start, kan den ikke etablere et stabilt sæt TPM-målinger, der skal gensees mod. Derfor går BitLocker ind i genoprettelsen på hver start.
Sådan genkender du den
-
BitLocker-genoprettelse udløses ved hver genstart.
-
Hvis du angiver genoprettelsesnøglen, kan Windows starte, men prompten returneres ved næste start.
-
PXE eller netværksstart er konfigureret foran den lokale disk i firmwarestartrækkefølgen.
Hvad kan du gøre bagefter?
-
Konfigurer firmwarestartrækkefølgen, så Windows Boot Manager på disken er først.
-
Deaktiver PXE-start, hvis det ikke er påkrævet.
-
Hvis PXE er påkrævet, skal du sikre dig, at PXE-infrastrukturen bruger en 2023-signeret Windows-startindlæser.
Hvad skete der
Dette afspejler en ændring på firmwareniveau i stedet for et problem med Windows. Opdateringen til sikker bootstart blev gennemført, men efter en senere genstart startes enheden ikke længere i Windows.
Sådan genkender du den
-
Enheden kan ikke starte Windows og kan vise en firmware- eller BIOS-meddelelse, der angiver en overtrædelse af sikker bootstart.
-
Fejlen opstår, når indstillingerne for sikker bootstart er nulstillet til standardindstillingerne for firmware.
-
Hvis du deaktiverer sikker bootstart, kan enheden muligvis starte igen.
Derfor sker det
Hvis du nulstiller Sikker bootstart til firmwarestandard, ryddes de Secure Boot-databaser, der er gemt i firmwaren. På enheder, der allerede er overgået til Windows UEFI CA 2023-signeret boot manager, fjerner denne nulstilling de certifikater, der kræves for at have tillid til startstyringen.
Derfor genkender firmwaren ikke længere den installerede Windows Boot Manager som pålidelig og blokerer startprocessen.
Dette scenarie skyldes ikke selve opdateringen til sikker bootstart, men en efterfølgende firmwarehandling, der fjerner de opdaterede tillidsankre.
Hvad kan du gøre bagefter?
-
Brug genoprettelsesværktøjet til sikker bootstart til at gendanne det nødvendige certifikat, så enheden kan starte igen.
-
Efter genoprettelse skal du sikre dig, at enheden har den nyeste tilgængelige firmware installeret fra enhedsproducenten.
-
Undgå at nulstille sikker bootstart til firmwarestandard, medmindre OEM-firmwaren indeholder opdaterede standarder for sikker bootstart, der har tillid til 2023-certifikaterne.
Genoprettelsesværktøj til sikker bootstart
Sådan genopretter du systemet:
-
På en anden Windows-pc, hvor juli 2024 eller nyere Windows-opdatering er installeret, skal du kopiere SecureBootRecovery.efi fra C:\Windows\Boot\EFI\.
-
Placer filen på et FAT32-formateret USB-drev under \EFI\BOOT\, og omdøb den til bootx64.efi.
-
Start den berørte enhed fra USB-drevet, og tillad, at genoprettelsesværktøjet kører. Værktøjet føjer Windows UEFI CA 2023 til DB.
Når certifikatet er gendannet, og systemet genstarter, bør Windows starte normalt.
Vigtigt: Denne proces vil kun genanvende et af de nye certifikater. Når enheden er gendannet, skal du sikre dig, at den har de nyeste certifikater anvendt igen, og overveje at opdatere systemets BIOS/UEFI til den nyeste version, der er tilgængelig. Dette kan være med til at forhindre en gentagelse af problemet med nulstilling af sikker bootstart, da mange OEM'er har udgivet firmwarerettelser til dette specifikke problem.
Hvad skete der
Når du har anvendt opdateringen til certifikatet til sikker bootstart og genstartet, kan enheden ikke starte og kan ikke oprette forbindelse til Windows.
Sådan genkender du den
-
Enheden mislykkes umiddelbart efter genstarten, der kræves af opdateringen til sikker bootstart.
-
Der vises muligvis en firmware- eller sikker bootstartfejl, eller systemet kan stoppe, før Windows indlæses.
-
Hvis du deaktiverer Sikker bootstart, kan enheden muligvis starte.
Derfor sker det
Dette problem kan skyldes en fejl i enhedens implementering af UEFI-firmware.
Når Windows anvender opdateringer af certifikater til sikker bootstart, forventes det, at der føjes nye certifikater til den eksisterende tilladte database til sikker bootstart (DB). Nogle firmwareimplementeringer overskriver DB'en forkert i stedet for at blive føjet til den.
Når dette sker,
-
Tidligere pålidelige certifikater, herunder Microsoft 2011-bootloadercertifikatet, fjernes.
-
Hvis systemet stadig bruger en boot manager, der er signeret med 2011-certifikatet på det pågældende tidspunkt, har firmwaren ikke længere tillid til det.
-
Firmwaren afviser startstyringen og blokerer startprocessen.
I nogle tilfælde kan DB'en også blive beskadiget i stedet for rent overskrevet, hvilket fører til det samme resultat. Denne funktionsmåde er blevet observeret på bestemte firmwareimplementeringer og forventes ikke på kompatibel firmware.
Hvad kan du gøre bagefter?
-
Angiv menuen til konfiguration af firmware, og forsøg at nulstille indstillingerne for sikker bootstart.
-
Hvis enheden startes efter nulstillingen, skal du gå til enhedsproducentens supportwebsted for at se, om der er en firmwareopdatering, der retter Sikker bootstart DB-håndtering.
-
Hvis der findes en firmwareopdatering, skal du installere den, før sikker bootstart aktiveres igen, og certifikatopdateringer til sikker bootstart genanvendes.
Hvis nulstilling af sikker bootstart ikke gendanner startfunktionaliteten, kræver yderligere genoprettelse sandsynligvis OEM-specifik vejledning.
Hvad skete der
Opdateringen af certifikat til sikker bootstart er ikke fuldført og forbliver blokeret på opdateringsfasen for Nøgleudvekslingsnøgle (KEK).
Sådan genkender du den
-
Registreringsdatabaseværdien AvailableUpdates forbliver angivet med KEK-bitten (0x0004) og ryddes ikke.
-
UEFICA2023Status går ikke videre til en fuldført tilstand.
-
Systemhændelsesloggen registrerer gentagne gange hændelses-id 1803, hvilket angiver, at KEK-opdateringen ikke kunne anvendes.
-
Enheden fortsætter med at forsøge opdateringen igen uden at gøre fremskridt.
Derfor sker det
Opdatering af Secure Boot KEK kræver godkendelse fra enhedens Platform Key (PK), som ejes af OEM'en.
For at opdateringen kan lykkes, skal enhedsproducenten give Microsoft en PK-signeret KEK til den pågældende platform. Denne OEM-signerede KEK er inkluderet i Windows-opdateringer og giver Windows mulighed for at opdatere KEK-firmwarevariablen.
Hvis OEM'en ikke har leveret en PK-signeret KEK til enheden, kan Windows ikke fuldføre KEK-opdateringen. I denne tilstand:
-
Opdateringer til sikker bootstart blokeres af designet.
-
Windows kan ikke omgå den manglende godkendelse.
-
Enheden kan ikke fuldføre certifikatvedligeholdelse af sikker bootstart permanent.
Dette kan ske på ældre enheder eller enheder, der ikke længere understøttes, hvor OEM'en ikke længere leverer firmware- eller nøgleopdateringer. Der er ingen understøttet manuel genoprettelsessti til denne betingelse.
Når opdateringer af certifikat til sikker bootstart ikke kan anvendes, registrerer Windows diagnosticeringshændelser, der forklarer, hvorfor status blev blokeret. Disse hændelser skrives, når du opdaterer databasen til signatur for sikker bootstart (DB) eller Nøgle exchange-nøgle (KEK) kan ikke udføres sikkert på grund af firmware, platformstilstand eller konfigurationsbetingelser. Scenarierne i dette afsnit henviser til disse hændelser for at identificere almindelige fejlmønstre og bestemme den relevante afhjælpning. Dette afsnit er beregnet til at understøtte diagnosticering og fortolkning af problemer, der er beskrevet tidligere, ikke at indføre nye fejlscenarier.
Du kan finde en komplet liste over hændelses-id'er, beskrivelser og eksempelposter under Sikker bootstart DB- og DBX-variable opdateringshændelser (KB5016061).
KEK-opdateringsfejl (DB-opdateringer lykkes, det gør KEK ikke)
En enhed kan opdatere certifikater i Secure Boot DB, men mislykkes under KEK-opdateringen. Når dette sker, kan opdateringen til sikker bootstart ikke fuldføres.
Symptomer
-
DB-certifikathændelser angiver status, men KEK-fasen er ikke fuldført.
-
AvailableUpdates forbliver indstillet til 0x4004, og 0x0004-bit'en ryddes ikke, når der køres flere opgaver.
-
Hændelse 1795 eller 1803 kan være til stede.
Fortolkning
-
1795 angiver typisk firmwarefejl under forsøg på at opdatere en sikker bootstartvariabel.
-
1803 angiver, at KEK-opdateringen ikke kan godkendes, fordi en påkrævet OEM PK-signeret KEK-nyttelast ikke er tilgængelig for platformen.
Næste trin
-
I 1795 skal du søge efter opdateringer til OEM-firmware og validere firmwareunderstøtten for variable opdateringer til sikker bootstart.
-
I 1803 skal du bekræfte, om OEM'en har givet Microsoft den PK-signerede KEK, der kræves til enhedsmodel.
KEK-opdateringsfejl på gæste-VM'er, der er hostet på Hyper-V
På virtuelle Hyper-V-maskiner kræver opdateringer af certifikat til sikker bootstart, at Windows-opdateringerne fra marts 2026 installeres på både Hyper-V-værten og gæsteoperativsystemet.
Opdateringsfejl rapporteres inde fra gæsten, men hændelsen angiver, hvor afhjælpning er påkrævet:
-
Hændelse 1795 (f.eks. "Mediet er skrivebeskyttet") rapporteret i gæsten angiver, at Hyper-V-værten mangler opdateringen for marts 2026 og skal opdateres.
-
Hændelse 1803 , der er rapporteret i gæsten , angiver, at selve gæste virtuel maskine mangler marts 2026-opdateringen og skal opdateres.
Reference og interne
Dette afsnit indeholder avancerede referenceoplysninger, der er beregnet til fejlfinding og support. Det er ikke beregnet til planlægning af installation. Den udvides på den mekanik for servicering af sikker bootstart, der er opsummeret tidligere, og indeholder detaljeret referencemateriale til fortolkning af registreringsdatabasens tilstand og hændelseslogge.
Bemærk (IT-administrerede installationer): Når de konfigureres via Gruppepolitik eller Microsoft Intune, må to lignende indstillinger ikke forveksles. Værdien AvailableUpdatesPolicy repræsenterer den konfigurerede politiktilstand. I mellemtiden afspejler AvailableUpdates den igangværende bit-clearing-arbejdstilstand. Begge kan føre til det samme resultat, men de opfører sig anderledes, fordi politikken igen gælder over tid.
AvailableUpdates-bits, der bruges til certifikatvedligeholdelse
Nedenstående bit bruges til de certifikat- og boot manager-handlinger, der er beskrevet i dette dokument. Kolonnen Rækkefølge afspejler den rækkefølge, som opgaven Secure Boot-Update behandler hver bit i.
|
Ordre |
Bitindstilling |
Brug |
|---|---|---|
|
1 |
0x0040 |
Denne bit fortæller den planlagte opgave at føje Windows UEFI CA 2023-certifikatet til Secure Boot DB. Dette giver Windows mulighed for at have tillid til bootadministratorer, der er signeret af dette certifikat. |
|
2 |
0x0800 |
Denne bit fortæller den planlagte opgave at anvende Microsoft Option ROM UEFI CA 2023 til DB. Betinget funktionsmåde: Når 0x4000 flag er angivet, kontrollerer den planlagte opgave først databasen for Microsoft Corporation UEFI CA 2011-certifikatet . Den anvender kun Microsoft Option ROM UEFI CA 2023-certifikatet, hvis 2011-certifikatet er til stede. |
|
3 |
0x1000 |
Denne bit fortæller den planlagte opgave at anvende Microsoft UEFI CA 2023 på DB. Betinget funktionsmåde: Når 0x4000 flag er angivet, kontrollerer den planlagte opgave først databasen for Microsoft Corporation UEFI CA 2011-certifikatet . Den anvender kun Microsoft UEFI CA 2023-certifikatet, hvis 2011-certifikatet er til stede. |
|
Ændringsfunktion (funktionsflag) |
0x4000 |
Denne bit ændrer funktionsmåden for 0x0800 og 0x1000 bit, så Microsoft UEFI CA 2023 og Microsoft Option ROM UEFI CA 2023 kun anvendes, hvis DB allerede indeholder Microsoft Corporation UEFI CA 2011. For at sikre, at enhedens sikkerhedsprofil forbliver den samme, anvender denne bit kun disse nye certifikater, hvis enheden har tillid til Microsoft Corporation UEFI CA 2011-certifikatet. Ikke alle Windows-enheder har tillid til dette certifikat. |
|
4 |
0x0004 |
Denne bit fortæller den planlagte opgave at søge efter en Nøgle exchange-nøgle, der er signeret af enhedens platformsnøgle (PK). Pc'en administreres af OEM'en. OEM'er signerer Microsoft KEK med deres pc og leverer den til Microsoft, hvor den er inkluderet i månedlige kumulative opdateringer. |
|
5 |
0x0100 |
Denne bit fortæller den planlagte opgave at anvende startstyringen, der er signeret af Windows UEFI CA 2023, på startpartitionen. Dette erstatter den Microsoft Windows Production PCA 2011-signerede boot manager. |
Bemærk:
-
Den 0x4000 bit forbliver indstillet, når alle andre bit behandles.
-
Hver bit behandles af den planlagte sikker bootstart-opgave i den rækkefølge, der er vist ovenfor.
-
Hvis 0x0004-bitten ikke kan behandles på grund af en manglende PK-signeret KEK, vil den planlagte opgave stadig anvende opdateringen til Boot Manager angivet med bit 0x0100.
Forventet forløb (AvailableUpdates)
Når en handling er fuldført, rydder Windows den tilknyttede bit fra AvailableUpdates. Hvis en handling mislykkes, logger Windows en hændelse og prøver igen, når opgaven kører igen.
Tabellen nedenfor viser det forventede forløb af AvailableUpdates-værdier , efterhånden som hver sikker bootstartopdateringshandling fuldføres.
|
Trin |
Bit behandlet |
Tilgængelig Opdateringer |
Beskrivelse |
Succeshændelse logført |
Mulige fejlhændelseskoder |
|---|---|---|---|---|---|
|
Start |
0x5944 |
Starttilstand, før vedligeholdelse af certifikat til sikker bootstart starter. |
- |
- |
|
|
1 |
0x0040 |
0x5944 → 0x5904 |
Windows UEFI CA 2023 føjes til Secure Boot DB. |
1036 |
1032, 1795, 1796, 1802 |
|
2 |
0x0800 |
0x5904 → 0x5104 |
Føj Microsoft Option ROM UEFI CA 2023 til DB, hvis enheden tidligere har tillid til Microsoft UEFI CA 2011. |
1044 |
1032, 1795, 1796, 1802 |
|
3 |
0x1000 |
0x5104 → 0x4104 |
Microsoft UEFI CA 2023 føjes til DB, hvis enheden tidligere havde tillid til Microsoft UEFI CA 2011. |
1045 |
1032, 1795, 1796, 1802 |
|
4 |
0x0004 |
0x4104 → 0x4100 |
Ny Microsoft KEK 2K CA 2023 signeret af OEM-platformnøglen anvendes. |
1043 |
1032, 1795, 1796, 1802, 1803 |
|
5 |
0x0100 |
0x4100 → 0x4000 |
Boot Manager, der er signeret af Windows UEFI CA 2023, er installeret. |
1799 |
1797 |
Noter
-
Når handlingen, der er knyttet til en bit, er fuldført, ryddes bitten fra AvailableUpdates.
-
Hvis en af disse handlinger mislykkes, logføres en hændelse, og handlingen udføres igen, næste gang den planlagte opgave kører.
-
Den 0x4000 bit er en ændringsfunktion og ryddes ikke. En endelig AvailableUpdates-værdi for 0x4000 angiver, at alle relevante opdateringshandlinger er fuldført.
-
Hændelser 1032, 1795, 1796, 1802 angiver typisk firmware- eller platformsbegrænsninger.
-
Hændelse 1803 angiver manglende OEM PK-signeret KEK.
Afhjælpningsprocedurer
Dette afsnit indeholder trinvise procedurer til afhjælpning af specifikke problemer med sikker bootstart. Hver procedure er begrænset til en veldefineret tilstand og er beregnet til kun at blive fulgt, når den indledende diagnose bekræfter, at problemet gælder. Brug disse procedurer til at gendanne den forventede funktionsmåde for sikker bootstart og tillade, at certifikatopdateringer fortsætter sikkert. Anvend ikke disse procedurer bredt eller præemptivt.
Aktivering af sikker bootstart i firmware
Hvis Sikker bootstart er deaktiveret i en enheds firmware, skal du se Windows 11 og Sikker bootstart for at få mere at vide om aktivering af sikker bootstart.
Planlagt sikker bootstart-opgave deaktiveret eller slettet
Den planlagte opgave Sikker bootstart-opdatering er påkrævet, for at Windows kan anvende certifikatopdateringer til sikker bootstart. Hvis opgaven er deaktiveret eller mangler, udføres vedligeholdelsen af certifikatet til sikker bootstart ikke.
Opgaveoplysninger
|
Opgavenavn |
Sikker bootstartopdatering |
|
Opgavesti |
\Microsoft\Windows\PI\ |
|
Fuld sti |
\Microsoft\Windows\PI\Secure-Boot-Update |
|
Kører som |
SYSTEM (lokalt system) |
|
Udløsere, |
Ved opstart og hver 12. time |
|
Påkrævet tilstand |
Aktiveret |
Sådan kontrolleres opgavestatus
Kør fra en powershell-prompt med administratorrettigheder: schtasks.exe /Query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V
Se efter feltet Status:
|
Status |
Betydning |
|---|---|
|
Klar |
Opgaven findes og er aktiveret. |
|
Deaktiveret |
Opgaven findes, men skal aktiveres. |
|
Fejl/ blev ikke fundet |
Opgaven mangler og skal oprettes igen. |
Sådan aktiveres eller genoprettes opgaven
Hvis statusfeltet for Sikker bootstart-opdatering er deaktiveret, fejl eller ikke fundet, skal du bruge eksempelscriptet til at aktivere opgaven: Eksempel Enable-SecureBootUpdateTask.ps1
Bemærk! Dette er et eksempelscript og understøttes ikke af Microsoft. Administratorer bør gennemgå og tilpasse det til deres miljø.
Eksempel:
.\Enable-SecureBootUpdateTask.ps1 – Stille
Kør vejledning
-
Hvis du ser Adgang nægtet, skal du køre PowerShell som administrator igen.
-
Hvis scriptet ikke kører på grund af eksekveringspolitik, skal du bruge en tilsidesættelse af procesområde:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Har du brug for mere hjælp?
Vil du have flere indstillinger?
Udforsk abonnementsfordele, gennemse kurser, få mere at vide om, hvordan du sikrer din enhed og meget mere.
Communities hjælper dig med at stille og besvare spørgsmål, give feedback og høre fra eksperter med omfattende viden.
