Bemærk
- Oprindelig udgivelsesdato: Marts 19, 2026
- KB-id: 5085046
I denne artikel
- Oversigt
- Sådan fungerer vedligeholdelse af et Secure Boot-certifikat
- Hvor skal du starte, når du foretager fejlfinding
- Schedule-Boot-Update opgave
- Derfor bruges en planlagt opgave
- Bitmasken AvailableUpdates i registreringsdatabasen
- Integration med OEM-firmware
- Almindelige fejlscenarier og løsninger
- Reference og interne dele
- AvailableUpdates-bits, der bruges til vedligeholdelse af certifikat
- Forventet forløb (AvailableUpdates)
- Afhjælpningsprocedurer
- Aktivering af sikker bootstart i firmware
- Planlagt opgave i Secure Boot deaktiveret eller slettet
Oversigt
Denne side vejleder administratorer og supportmedarbejdere i diagnosticering og løsning af problemer relateret til sikker bootstart på Windows-enheder. Emnerne omfatter fejl under opdatering af Secure Boot-certifikat, forkerte tilstande for sikker bootstart, uventede BitLocker-genoprettelsesprompter og startfejl efter ændringer i konfigurationen af Secure Boot.
Vejledningen forklarer, hvordan du bekræfter vedligeholdelse og konfiguration af Windows, gennemser relevante registreringsdatabaseværdier og hændelseslogfiler og identificerer, hvornår firmware- eller platformsbegræ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 nye fejlfindingsscenarier og vejledning identificeres.
Sådan fungerer vedligeholdelse af Secure Boot-certifikat
Vedligeholdelse af Secure Boot-certifikat på Windows er en koordineret proces mellem operativsystemet og en enheds UEFI-firmware. Målet er at opdatere vigtige tillidsankre, samtidig med at muligheden for at starte op på hvert trin bevares.
Processen drives af en planlagt Windows-opgave, en registreringsdatabasebaseret sekvens af opdateringshandlinger og indbygget logføring og nye forsøg. Sammen sikrer disse komponenter, at Secure Boot-certifikater og Windows Boot Manager opdateres på en kontrolleret og struktureret måde, og kun når forudsætningerne lykkes.
Hvor skal du starte, når du foretager fejlfinding
Når en enhed ikke ser ud til at gøre de forventede fremskridt ved anvendelse af certifikatopdateringer til sikker bootstart, skal du starte med at identificere problemets kategori. De fleste problemer falder inden for et af fire områder: Windows-servicing state, opdateringsmekanismen til sikker bootstart, firmwarefunktionsmåde eller en platforms- eller OEM-begrænsning.
Start 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 de næste handlinger uden nærmere undersøgelse.
Bekræft berettigelse til vedligeholdelse og platform for Windows
- Bekræft, at enheden opfylder de grundlæggende krav til at modtage certifikatopdateringer til sikker bootstart:
- Enheden kører en understøttet version af Windows.
- De seneste påkrævede sikkerhedsopdateringer til Windows er installeret.
- Sikker start er aktiveret i UEFI-firmwaren.
- Hvis nogen af disse betingelser ikke er opfyldt, skal du løse dem, før du fortsætter med yderligere fejlfinding.
Kontrollér opgavestatus for Secure-Boot-Update
- Bekræft, at den Windows-mekanisme, der er ansvarlig for at anvende certifikatopdateringer til sikker bootstart, findes og fungerer:
- Den planlagte opgave Secure-Boot-Update findes.
- Opgaven aktiveres og kører som et lokalt system.
- Opgaven har 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 andre årsager undersøges.
Kontrollér registreringsdatabaseindstillinger for forventet forløb
Gennemse enhedens servicetilstand 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 internt materiale).
Samlet angiver disse værdier, om vedligeholdelsen skrider frem normalt, prøver en handling igen eller er gået i stå på et bestemt trin.
Korreler tilstand i registreringsdatabasen med Secure Boot-hændelser
Gennemse hændelser, der er relateret til sikker start i systemets hændelseslog, og korreler dem med registreringsdatabasens tilstand. Hændelsesdata bekræfter typisk, om enheden gør fremadrettet status, forsøger igen på grund af en midlertidig tilstand eller blokeres af et firmware- eller platformsproblem.
Sammen angiver registreringsdatabasen og hændelseslogfiler normalt, om funktionsmåden er forventet, midlertidig eller kræver korrigerende handlinger.
Schedule-Boot-Update opgave
Vedligeholdelse af Secure Boot-certifikat implementeres via en planlagt Windows-opgave kaldet Secure-Boot-Update. Opgaven er registreret på følgende sti:
Bemærk
\Microsoft\Windows\PI\Secure-Boot-Update
Opgaven kører som et lokalt system. Som standard kører det ved systemstart og derefter hver 12. time. Hver gang den kører, kontrollerer den, om opdateringshandlinger til 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 Secure Boot-vedligeholdelsen kan fungere.
Derfor bruges en planlagt opgave
Certifikatopdateringer til sikker bootstart kræver koordinering mellem Windows og UEFI-firmwaren, 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 flere muligheder for at prøve opdateringer igen, hvis et tidligere forsøg mislykkedes, eller hvis enheden forblev tændt uden at genstarte. Dette design hjælper med at sikre fremadrettet fremskridt uden at kræve manuel indgriben.
Bitmasken AvailableUpdates i registreringsdatabasen
Opgaven Secure-Boot-Update drives af værdien AvailableUpdates i registreringsdatabasen. Denne værdi er en 32-bit bitmaske, der findes på:
Bemærk
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Hver bit i værdien repræsenterer en bestemt Secure Boot-opdateringshandling. 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 0x5944 angiver f.eks., at der er ventende flere opdateringshandlinger.
Når opgaven Secure-Boot-Update kører, fortolkes de indstillede bit som ventende arbejde og behandler dem i en defineret rækkefølge.
Sekventielle opdateringer, logføring og funktionsmåde for gentagne forsøg
Certifikatopdateringer til sikker bootstart anvendes i en fast rækkefølge. Hver opdateringshandling er designet til at være sikker at forsøge igen og udføres uafhængigt. Opgaven Secure-Boot-Update går ikke videre til næste trin, før den aktuelle handling lykkes, og den tilsvarende bit ryddes fra AvailableUpdates.
Hver handling bruger UEFI-standardgrænseflader til at opdatere Secure Boot-variabler, f.eks. DB og KEK, eller til at installere den opdaterede Windows Boot Manager. Windows registrerer resultatet af hvert trin i systemets hændelseslog. Vellykkede hændelser bekræfter fremadrettet status, mens fejlhændelser angiver, hvorfor en handling ikke kunne fuldføres.
Hvis et opdateringstrin mislykkes, standser opgaven behandlingen, logfører fejlen og lader den tilknyttede bit være indstillet. Handlingen forsøges igen, næste gang opgaven køres. Denne funktionsmåde for fornyet prøvetagning gør det muligt for enheder automatisk at genoprette efter midlertidige forhold, f.eks. manglende firmwareunderstøttelse eller forsinkede OEM-opdateringer.
Administratorer kan spore status ved at korrelere registreringsdatabasens tilstand med hændelseslogposter. Registreringsdatabaseværdier som UEFICA2023Status, UEFICA2023Error og UEFICA2023ErrorEvent angiver sammen med AvailableUpdates-bitmasken , hvilket trin der er aktivt, fuldført eller blokeret.
Denne kombination viser, om enheden forløber normalt, prøver en handling igen eller er gået i stå.
Integration med OEM-firmware
Opdateringer til Secure Boot-certifikat afhænger af korrekt funktionsmåde og understøttelse i en enheds UEFI-firmware. Mens Windows orkestrerer opdateringsprocessen, er firmwaren ansvarlig for at håndhæve politikken for sikker bootstart og vedligeholde Secure Boot-databaserne.
OEM-producenter har to vigtige elementer, der muliggør sikker bootstart-certifikatservice:
- KEK'er (Platform Key-signerede nøgleudvekslingsnøgler), der godkender installation af nye sikker bootstart-certifikater.
- Firmwareimplementeringer, der på korrekt vis bevarer, tilføjer og validerer Secure Boot-databaser under opdateringer.
Hvis firmwaren ikke understøtter disse funktionsmåder fuldt ud, kan Secure Boot-opdateringer 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 arbejder med OEM'er om at identificere firmwareproblemer og stille rettede opdateringer til rådighed. Hvis fejlfinding indikerer en firmwarebegrænsning eller -defekt, skal administratorer muligvis installere den nyeste UEFI-firmwareopdatering fra enhedsproducenten, før certifikatopdateringer til sikker bootstart kan fuldføres.
Almindelige fejlscenarier og løsninger
Secure Boot-opdateringer anvendes af den planlagte opgave Secure-Boot-Update, der er baseret på AvailableUpdates i registreringsdatabasen.
Under normale forhold forekommer disse trin automatisk og registrerer vellykkede hændelser, efterhånden som hver fase fuldføres. I nogle tilfælde kan firmwarefunktionsmåde, platformkonfiguration eller vedligeholdelseskrav forhindre status eller føre til uventet startfunktionalitet.
I afsnittene herunder beskrives de mest almindelige fejlscenarier, hvordan du genkender dem, hvorfor de opstår, og de relevante næste trin for at gendanne normal drift. Scenarier er sorteret fra de mest almindeligt forekommende til mere alvorlige startpåvirkningstilfælde.
Secure Boot-opdateringer anvendes ikke (ingen status)
Når Secure Boot-opdateringer ikke viser nogen status, betyder det typisk, at opdateringsprocessen aldrig startede. Derfor mangler de forventede værdier for registreringsdatabasen for sikker bootstart og hændelseslogfiler, fordi opdateringsmekanismen aldrig blev udløst.
Hvad skete der
Opdateringsprocessen til sikker bootstart startede ikke, så der blev ikke anvendt nogen Secure Boot-certifikater eller opdateret boot manager på enheden.
Sådan genkender du den
- Der findes ingen værdier i registreringsdatabasen til vedligeholdelse af Secure Boot, f.eks. UEFICA2023Status.
- Forventede Secure Boot-hændelser (f.eks. 1043, 1044, 1045, 1799, 1801) mangler i systemets hændelseslog.
- Enheden fortsætter med at bruge ældre Secure Boot-certifikater og bootkomponenter.
Derfor sker det
Dette scenarie opstår typisk, når en eller flere af følgende betingelser gør sig gældende:
- Den planlagte opgave Secure-Boot-Update er deaktiveret eller mangler.
- Sikker start er deaktiveret i UEFI-firmware.
- Enheden opfylder ikke kravene til vedligeholdelse af Windows, f.eks. at køre en understøttet Windows-version eller have krævede opdateringer installeret.
Hvad kan du nu gøre?
- Kontrollér, at enheden opfylder kravene til vedligeholdelse og berettigelse til platformen i Windows.
- Bekræft, at Sikker start er aktiveret i firmwaren.
- 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 Secure Boot planlagt 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 Secure Boot-serviceringen.
Enheden starter i BitLocker-genoprettelse efter Secure Boot-opdatering
I nogle tilfælde kan opdateringer relateret til sikker bootstart medføre, at en enhed går i BitLocker-genoprettelse. Funktionsmåden kan være forbigående eller vedvarende afhængigt af den underliggende årsag.
Scenarie 1: Engangsgenoprettelse af BitLocker efter Secure Boot-opdatering
Hvad sker der?
Enheden går i BitLocker-genoprettelse ved den første start efter Secure Boot-opdateringen, men starter normalt ved efterfølgende genstarter.
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 forsegle BitLocker igen. 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 gendannes korrekt, og problemet opstår ikke igen.
Sådan genkender du den
- BitLocker-genoprettelse sker én gang.
- Når du har angivet genoprettelsesnøglen, medfører efterfølgende starter ikke genoprettelse.
- Der er ingen igangværende startordre eller PXE-involvering.
Hvad kan du nu gøre?
- Angiv BitLocker-genoprettelsesnøglen for at fortsætte Windows.
- Søg efter firmwareopdateringer.
Scenarie 2: Gentagen BitLocker-genoprettelse på grund af PXE konfiguration af første start
Hvad sker der?
Enheden går i BitLocker-genoprettelse ved hver start.
Derfor sker det
Enheden er konfigureret til at forsøge PXE-start (netværk) først. PXE-startforsøget mislykkes, og firmwaren falder derefter tilbage til Windows Boot Manager på disken.
Dette resulterer i, at to forskellige signeringsautoriteter måles i løbet af en enkelt startcyklus:
- PXE-startstien er signeret af Microsoft UEFI CA 2011.
- Windows-startstyring på disken er signeret af Windows UEFI CA 2023.
Da BitLocker overholder forskellige Secure Boot-tillidskæder under start, kan den ikke oprette et stabilt sæt TPM-målinger, der skal forsegles igen. Derfor går BitLocker i genoprettelse ved hver opstart.
Sådan genkender du den
- BitLocker-genoprettelse udløses ved hver genstart.
- Hvis du angiver genoprettelsesnøglen, kan Windows starte, men prompten vender tilbage ved næste start.
- PXE eller netværksstart er konfigureret foran den lokale disk i startrækkefølgen for firmwaren.
Hvad kan du nu gøre?
- Konfigurer startrækkefølgen for firmwaren, så Windows Boot Manager på disken er først.
- Deaktiver PXE-start, hvis det ikke er nødvendigt.
- Hvis PXE er påkrævet, skal du sikre dig, at PXE-infrastrukturen bruger en 2023-signeret Windows-bootindlæser.
Enheden kan ikke starte, efter at sikker bootstart er nulstillet
Hvad skete der
Dette afspejler en ændring på firmwareniveau snarere end et Windows-problem. Opdateringen til sikker bootstart blev fuldført, men efter en senere genstart starter 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 Secure Boot.
- Fejlen opstår , når indstillingerne for sikker bootstart er nulstillet til standardindstillingerne for firmwaren.
- Hvis du deaktiverer sikker bootstart, kan enheden genstarte.
Derfor sker det
Hvis du nulstiller Secure Boot til standardindstillingerne for firmwaren, ryddes de Secure Boot-databaser, der er gemt i firmwaren. På enheder, der allerede er overgået til den Windows UEFI CA 2023-signerede boot manager, fjerner denne nulstilling de certifikater, der kræves for at have tillid til denne boot manager.
Som et resultat genkender firmwaren ikke længere den installerede Windows Boot Manager som pålidelig og blokerer opstartsprocessen.
Dette scenarie skyldes ikke selve Secure Boot-opdateringen, men en efterfølgende firmwarehandling, der fjerner de opdaterede tillidsankre.
Hvad kan du nu gøre?
- Brug genoprettelsesværktøjet til sikker bootstart til at gendanne det påkrævede certifikat, så enheden kan starte igen.
- Efter genoprettelsen skal du sikre dig, at enheden har den nyeste tilgængelige firmware installeret fra enhedsproducenten.
- Undgå at nulstille sikker bootstart til firmwarestandarder, medmindre OEM-firmwaren indeholder opdaterede standarder for sikker bootstart, der har tillid til 2023-certifikaterne.
Genoprettelsesværktøj til sikker bootstart
Sådan gendannes systemet:
- På en anden Windows-pc med Windows-opdateringen fra juli 2024 eller nyere 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 lad genoprettelsesværktøjet køre. Hjælpeprogrammet føjer Windows UEFI CA 2023 til databasen.
Når certifikatet er gendannet, og systemet genstartes, bør Windows starte normalt.
Vigtigt! Denne proces genanvender kun ét af de nye certifikater. Når enheden er genoprettet, skal du sikre dig, at de nyeste certifikater er 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 Secure Boot, da mange OEM-producenter har frigivet firmwarerettelser til dette specifikke problem.
Enheden kan ikke starte efter Secure Boot-opdatering pga. at firmware overskriver databasen
Hvad skete der
Efter at have anvendt opdateringen af Secure Boot-certifikatet og genstartet, kan enheden ikke starte og når ikke Windows.
Sådan genkender du den
- Enheden giver fejl umiddelbart efter den genstart, der kræves af Secure Boot-opdateringen.
- Der vises muligvis en firmware- eller sikker bootstartfejl, eller systemet kan stoppe, før Windows indlæses.
- Hvis du deaktiverer sikker bootstart, kan enheden starte.
Derfor sker det
Problemet kan skyldes en fejl i enhedens implementering af UEFI-firmware.
Når Windows anvender certifikatopdateringer til sikker bootstart, forventes firmwaren at føje nye certifikater til den eksisterende databasen med tilladte signaturer til sikker bootstart. Nogle firmwareimplementeringer overskriver forkert databasen i stedet for at føje til den.
Når dette sker,
- Certifikater, der tidligere var tillid til, herunder Microsoft 2011 bootloader-certifikatet, fjernes.
- Hvis systemet stadig bruger en Boot Manager, der er signeret med 2011-certifikatet på det tidspunkt, har firmwaren ikke længere tillid til den.
- Firmwaren afviser boot manager og blokerer startprocessen.
I nogle tilfælde kan databasen også blive beskadiget i stedet for at blive overskrevet, hvilket fører til det samme resultat. Denne funktionsmåde er observeret på specifikke firmwareimplementeringer og forventes ikke på kompatibel firmware.
Hvad kan du nu gøre?
- Gå ind i firmwarens opsætningsmenuer, og forsøg at nulstille indstillingerne for sikker bootstart.
- Hvis enheden starter efter nulstillingen, skal du gå til enhedsproducentens supportwebsted for at se, om der er en firmwareopdatering, der retter håndteringen af Secure Boot DB.
- Hvis der findes en firmwareopdatering, skal du installere den, før du genaktiverer Secure Boot og genanvender Secure Boot-certifikatopdateringer.
Hvis nulstilling af Sikker start ikke gendanner startfunktionaliteten, kræver yderligere gendannelse sandsynligvis OEM-specifik vejledning.
Opdatering til sikker bootstart blokeret pga. manglende OEM-signeret KEK
Hvad skete der
Opdateringen af certifikatet til sikker bootstart er ikke fuldført og forbliver blokeret i opdateringsfasen for Key Exchange Key (KEK).
Sådan genkender du den
- Værdien AvailableUpdates i registreringsdatabasen forbliver angivet med KEK-bitten (0x0004) og ryddes ikke.
- UEFICA2023Status går ikke videre til en fuldført tilstand.
- Systemhændelseslog registrerer gentagne gange hændelses-id 1803, hvilket angiver, at KEK-opdateringen ikke kunne anvendes.
- Enheden fortsætter med at prøve 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.
Hvis opdateringen skal lykkes, skal enhedsproducenten give Microsoft en PK-signeret KEK for den pågældende platform. Denne OEM-signerede KEK er inkluderet i Windows-opdateringer og gør det muligt for Windows at opdatere firmware-KEK-variablen.
Hvis OEM-producenten ikke har leveret en PK-signeret KEK til enheden, kan Windows ikke fuldføre KEK-opdateringen. I denne tilstand:
- Secure Boot-opdateringer er tilsigtet blokeret.
- Windows kan ikke løse den manglende godkendelse.
- Enheden kan forblive permanent ude af stand til at fuldføre vedligeholdelsen af Secure Boot-certifikatet.
Dette kan ske på ældre enheder, eller enheder, der ikke længere understøttes, hvor OEM-producenten ikke længere leverer firmware- eller vigtige opdateringer. Der er ikke nogen understøttet manuel genoprettelsessti for denne betingelse.
Opdateringshændelser og fejlindikatorer for Secure Boot-certifikat
Når certifikatopdateringer til sikker bootstart ikke anvendes, registrerer Windows diagnosticeringshændelser, der forklarer, hvorfor status blev blokeret. Disse hændelser skrev, når opdatering af Secure Boot Signature Database (DB) eller Key Exchange Key (KEK) ikke kan udføres sikkert på grund af firmware, platformtilstand eller konfigurationsforhold. Scenarierne i dette afsnit henviser til disse hændelser for at identificere almindelige fejlmønstre og fastlægge den relevante afhjælpning. Dette afsnit er beregnet til at understøtte diagnosticering og fortolkning af problemer, der er beskrevet tidligere, ikke til at introducere nye fejlscenarier.
Du kan finde en komplet liste over hændelses-id'er, beskrivelser og eksempelposter under Sikker start DB- og DBX-variabelopdateringshæ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 opdateringsprocessen 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 den 0x0004 bit ryddes ikke efter flere opgavekørsler.
- Hændelse 1795 eller 1803 kan være til stede.
Fortolkning
- 1795 angiver typisk firmwarefejl under forsøg på at opdatere en Secure Boot-variabel.
- 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
- For 1795 skal du søge efter OEM-firmwareopdateringer og validere firmwareunderstøttelse for variable opdateringer til sikker bootstart.
- For 1803 skal du kontrollere, om OEM-producenten har leveret Microsoft den PK-signerede KEK, der kræves til enhedsmodellen.
KEK-opdateringsfejl på virtuelle gæstemaskiner, der hostes på Hyper-V
På virtuelle Hyper-V-maskiner kræver certifikatopdateringer til sikker start, 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"), der rapporteres 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 den virtuelle gæstemaskine mangler opdateringen for marts 2026 og skal opdateres.
Reference og interne dele
Dette afsnit indeholder avancerede referenceoplysninger, der er beregnet til fejlfinding og support. Den er ikke beregnet til planlægning af installationer. Den udvider mekanikken til Secure Boot-vedligeholdelse, der er opsummeret tidligere, og indeholder detaljeret referencemateriale til fortolkning af registreringsdatabasens tilstand og hændelseslogfiler.
Bemærk (it-administrerede installationer): Når de er konfigureret via Gruppepolitik eller Microsoft Intune, bør to lignende indstillinger ikke forveksles. Værdien AvailableUpdatesPolicy repræsenterer den konfigurerede politiktilstand. I mellemtiden afspejler AvailableUpdates den igangværende arbejdstilstand for bitrydning. Begge kan føre til det samme resultat, men de fungerer forskelligt, fordi politikken træder i kraft igen over tid.
AvailableUpdates-bits, der bruges til vedligeholdelse af certifikat
Bittene nedenfor bruges til de certifikat- og Boot Manager-handlinger, der er beskrevet i dette dokument. Kolonnen Rækkefølge afspejler den sekvens, som Secure-Boot-Update-opgaven behandler hver bit i.
| Rækkefølge | 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 Boot Managere, 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 det 0x4000 flag er angivet, kontrollerer den planlagte opgave først databasen for Microsoft Corporation UEFI CA 2011-certifikatet . Det 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å databasen. Betinget funktionsmåde: Når det 0x4000 flag er angivet, kontrollerer den planlagte opgave først databasen for Microsoft Corporation UEFI CA 2011-certifikatet . Det anvender kun Microsoft UEFI CA 2023-certifikatet, hvis 2011-certifikatet er til stede. |
| Modifikator (funktionsflag) | 0x4000 | Denne bit ændrer funktionsmåden af 0x0800 og 0x1000 bits, så Microsoft UEFI CA 2023 og Microsoft Option ROM UEFI CA 2023 kun anvendes, hvis databasen 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 der skal søges efter en nøgleudvekslingsnøgle, der er signeret med enhedens platformnøgle (PK). PK'en administreres af OEM'en. OEM-producenter signerer Microsoft KEK med deres PK og leverer den til Microsoft, hvor den er inkluderet i månedlige akkumulerede opdateringer. |
| 5 | 0x0100 | Denne bit fortæller den planlagte opgave at anvende boot manager, signeret af Windows UEFI CA 2023, på boot-partitionen. Dette erstatter den Microsoft Windows Production PCA 2011-signerede boot manager. |
Bemærk!
- Den 0x4000 bit forbliver indstillet, efter alle andre bit er behandlet.
- Hver bit behandles af den planlagte opgave Secure-Boot-Update i den rækkefølge, der er vist ovenfor.
- Hvis den 0x0004 bit ikke kan behandles pga. en manglende PK-signeret KEK, vil den planlagte opgave stadig anvende boot manager-opdateringen, der indikeres af bit 0x0100.
Forventet forløb (AvailableUpdates)
Når en handling er fuldført, rydder Windows den tilknyttede bit fra AvailableUpdates. Hvis en handling mislykkes, logfører 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 Secure Boot-opdateringshandling fuldføres.
| Trin | Bit behandlet | Tilgængelige Opdateringer | Beskrivelse | Succeshændelse logført | Mulige fejlhændelseskoder |
|---|---|---|---|---|---|
| Start | 0x5944 | Starttilstand, før servicering af Secure Boot-certifikatet begynder. | - | - | |
| 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 databasen, hvis enheden tidligere havde tillid til Microsoft UEFI CA 2011. | 1044 | 1032, 1795, 1796, 1802 |
| 3 | 0x1000 | 0x5104 → 0x4104 | Microsoft UEFI CA 2023 føjes til databasen, 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, der er signeret af OEM-platformsnø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 |
Bemærkninger
- Når den handling, der er knyttet til en bit, fuldføres, fjernes den pågældende bit fra AvailableUpdates.
- Hvis en af disse handlinger mislykkes, logføres en hændelse, og handlingen forsøges igen, næste gang den planlagte opgave køres.
- Den 0x4000 bit er en modifikator og ryddes ikke. En afsluttende AvailableUpdates-værdi på 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 at afhjælpe bestemte problemer med sikker bootstart. Hver procedure er begrænset til en veldefineret tilstand og er kun beregnet til at blive fulgt, når den første diagnose bekræfter, at problemet er relevant. 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æventivt.
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å oplysninger om, hvordan du aktiverer sikker bootstart.
Planlagt opgave i Secure Boot deaktiveret eller slettet
Den planlagte opgave Secure-Boot-Update er påkrævet, for at Windows kan anvende certifikatopdateringer til sikker bootstart. Hvis opgaven er deaktiveret eller mangler, går vedligeholdelsen af Secure Boot-certifikatet ikke videre.
Opgavedetaljer
| Opgavenavn | Secure-Boot-Update |
|---|---|
| Opgavesti | \Microsoft\Windows\PI\ |
| Fuld sti | \Microsoft\Windows\PI\Secure-Boot-Update |
| Kører som | SYSTEM (lokalt system) |
| Udløsere | Ved start og hver 12. time |
| Påkrævet tilstand | Aktiveret |
Sådan kontrollerer du opgavestatus
Kør fra en PowerShell-prompt med administratorrettigheder:
schtasks.exe /query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V
Kig efter feltet Status :
| Status | Betydning |
|---|---|
| Klar | Opgaven findes og er aktiveret. |
| Deaktiveret | Opgaven findes, men skal aktiveres. |
| Fejl/Ikke fundet | Opgaven mangler og skal oprettes igen. |
Sådan aktiverer eller genopretter du opgaven
Hvis statusfeltet for Secure-Boot-Update er deaktiveret, Fejl eller Ikke fundet, skal du bruge eksempelscriptet til at aktivere opgaven: Eksempel på Enable-SecureBootUpdateTask.ps1
Bemærk! Dette er et eksempelscript og understøttes ikke af Microsoft. Administratorer bør gennemse og tilpasse den til deres miljø.
Eksempel:
Bemærk
.\Enable-SecureBootUpdateTask.ps1 -Quiet
Vejledning til kørsel
- Hvis du får vist Adgang nægtet, skal du køre PowerShell igen som administrator.
- Hvis scriptet ikke kører på grund af eksekveringspolitik, kan du bruge en procesomfangstilsidesættelse:
Bemærk
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass