Obs!
- Opprinnelig publiseringsdato: Mars 19, 2026
- KB-ID: 5085046
I denne artikkelen
- Oversikt
- Slik fungerer vedlikehold av et Secure Boot-sertifikat
- Hvor du skal starte når du feilsøker
- Planlagt oppgave Secure-Boot-Update
- Hvorfor en planlagt oppgave brukes
- Registerbitmasken AvailableUpdates
- Integrasjon med OEM-fastvare
- Vanlige feilscenarier og løsninger
- Referanser og interne elementer
- AvailableUpdates-biter som brukes til sertifikatservice
- Forventet fremdrift (TilgjengeligeOppdateringer)
- Utbedringsprosedyrer
- Aktiverer sikker oppstart i fastvare
- Planlagt oppgave for sikker oppstart er deaktivert eller slettet
Oversikt
Denne siden veileder administratorer og kundestøttepersonell i diagnostisering og løsning av problemer knyttet til sikker oppstart på Windows-enheter. Emnene omfatter oppdateringsfeil for Secure Boot-sertifikat, feil Secure Boot-tilstander, uventede BitLocker-gjenopprettingsmeldinger og oppstartsfeil etter konfigurasjonsendringer i Secure Boot.
Veiledningen forklarer hvordan du kontrollerer vedlikehold og konfigurasjon av Windows, ser gjennom relevante registerverdier og hendelseslogger og identifiserer når fastvare- eller plattformbegrensninger krever en OEM-oppdatering. Dette innholdet er ment for å diagnostisere problemer på eksisterende enheter. Den er ikke ment for planlegging av nye distribusjoner. Dette dokumentet oppdateres etter hvert som nye feilsøkingsscenarioer og -veiledninger identifiseres.
Slik fungerer vedlikehold av Secure Boot-sertifikater
Service av Secure Boot-sertifikat på Windows er en koordinert prosess mellom operativsystemet og enhetens UEFI-fastvare. Målet er å oppdatere kritiske klareringsankre samtidig som du bevarer muligheten til å starte opp på hvert trinn.
Prosessen drives av en oppgave planlagt av Windows, en registerbasert sekvens av oppdateringshandlinger og innebygd virkemåte for logging og nye forsøk. Sammen sikrer disse komponentene at Secure Boot-sertifikater og Windows oppstartsbehandling oppdateres på en kontrollert, ordnet måte, og bare etter at kravene er fullført.
Hvor du skal starte når du feilsøker
Når en enhet ikke ser ut til å gjøre forventet fremgang ved bruk av sertifikatoppdateringer for sikker oppstart, begynner du med å identifisere kategorien for problemet. De fleste problemer faller innenfor ett av fire områder: Windows-servicetilstand, oppdateringsmekanismen for sikker oppstart, fastvarevirkemåte eller en plattform- eller OEM-begrensning.
Begynn med kontrollene nedenfor, i rekkefølge. I mange tilfeller er disse trinnene tilstrekkelige til å forklare den observerte atferden og bestemme neste handlinger uten dypere undersøkelser.
Bekreft at du er kvalifisert for Windows-service og plattform
- Kontroller at enheten oppfyller de grunnleggende kravene for å motta oppdateringer for Secure Boot-sertifikatet:
- Enheten kjører en støttet versjon av Windows.
- De siste nødvendige sikkerhetsoppdateringene for Windows er installert.
- Sikker oppstart er aktivert i UEFI-fastvaren.
- Hvis noen av disse betingelsene ikke er oppfylt, må du håndtere dem før du fortsetter med videre feilsøking.
Kontroller oppgavestatusen Secure-Boot-Update
- Bekreft at Windows-mekanismen som er ansvarlig for å bruke sertifikatoppdateringer for sikker oppstart, er til stede og fungerer:
- Den planlagte oppgaven Secure-Boot-Update finnes.
- Oppgaven aktiveres og kjøres som Lokalt system.
- Oppgaven har kjørt minst én gang siden den nyeste Windows-sikkerhetsoppdateringen ble installert.
- Hvis oppgaven er deaktivert, slettet eller ikke kjører, kan ikke oppdateringer for Secure Boot-sertifikat brukes. Feilsøking bør fokusere på å gjenopprette oppgaven før andre årsaker undersøkes.
Kontrollere registerinnstillingene for forventet fremdrift
Se gjennom enhetens Secure Boot-servicetilstand i registret:- Undersøk UEFICA2023Status, UEFICA2023Error og UEFICA2023ErrorEvent.
- Undersøk tilgjengelige oppdateringer og sammenlign den med forventet fremdrift (se referanse og interne elementer).
Sammen indikerer disse verdiene om vedlikeholdet går normalt, om du prøver en operasjon på nytt, eller om det er stanset på et bestemt trinn.
Korrelere registertilstand med Secure Boot-hendelser
Se gjennom hendelser relatert til sikker oppstart i systemhendelsesloggen og koordiner dem med registertilstanden. Hendelsesdata bekrefter vanligvis om enheten fremskynder fremdriften, prøver på nytt på grunn av en midlertidig tilstand, eller blokkeres av et fastvare- eller plattformproblem.
Sammen angir registeret og hendelsesloggene vanligvis om virkemåten er forventet, midlertidig eller krever korrigerende tiltak.
Planlagt oppgave Secure-Boot-Update
Service av Secure Boot-sertifikater implementeres gjennom en planlagt oppgave i Windows kalt Secure-Boot-Update. Oppgaven er registrert på følgende bane:
Obs!
\Microsoft\Windows\PI\Secure-Boot-Update
Oppgaven kjører som et lokalt system. Som standard kjører den ved systemstart og deretter hver 12. time. Hver gang den kjøres, kontrollerer den om Sikker oppstart-oppdateringshandlinger venter, og forsøker å bruke dem i rekkefølge.
Hvis denne oppgaven er deaktivert eller mangler, kan ikke oppdateringer for Secure Boot-sertifikat brukes. Oppgaven Secure-Boot-Update må fortsatt være aktivert for at Secure Boot-tjenesten skal fungere.
Hvorfor en planlagt oppgave brukes
Sertifikatoppdateringer for Secure Boot krever koordinering mellom Windows og UEFI-fastvaren, inkludert skriving av UEFI-variabler som lagrer Secure Boot-nøkler og -sertifikater. En planlagt oppgave gjør at Windows kan prøve disse oppdateringene når systemet er i en tilstand der fastvarevariabler kan endres.
Den regelmessige 12-timers planen gir flere muligheter til å prøve oppdateringer på nytt hvis et tidligere forsøk mislyktes, eller hvis enheten fortsatt er slått på uten å starte på nytt. Denne utformingen bidrar til å sikre fremdrift uten å kreve manuell inngripen.
Registerbitmasken AvailableUpdates
Oppgaven Secure-Boot-Update drives av registerverdien AvailableUpdates . Denne verdien er en 32-biters bitmaske som finnes på:
Obs!
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Hver bit i verdien representerer en bestemt oppdateringshandling for Secure Boot. Oppdateringsprosessen starter når AvailableUpdates settes til en annen verdi enn null, enten automatisk av Windows eller eksplisitt av en administrator. En verdi som 0x5944 indikerer for eksempel at flere oppdateringshandlinger venter.
Når oppgaven Secure-Boot-Update kjøres, tolker den de angitte bitene som ventende arbeid og behandler dem i en definert rekkefølge.
Sekvensielle oppdateringer, logging og virkemåte for nye prøveforsøk
Sertifikatoppdateringer for sikker oppstart brukes i en fast rekkefølge. Hver oppdateringshandling er utformet for å være trygg å prøve på nytt og fullføres uavhengig av hverandre. Oppgaven Secure-Boot-Update går ikke videre til neste trinn før gjeldende handling lykkes, og den tilhørende biten fjernes fra AvailableUpdates.
Hver operasjon bruker standard UEFI-grensesnitt til å oppdatere Secure Boot-variabler som DB og KEK, eller til å installere den oppdaterte oppstartsbehandlingen for Windows. Windows registrerer resultatet av hvert trinn i systemhendelsesloggen. Suksesshendelser bekrefter fremdriften, mens mislykkede hendelser angir hvorfor en handling ikke kunne fullføres.
Hvis et oppdateringstrinn mislykkes, stopper oppgaven, logger feilen og lar den tilknyttede biten forlates. Operasjonen prøves på nytt neste gang oppgaven kjøres. Denne virkemåten for ny prøveversjon gjør det mulig for enheter å gjenopprette automatisk fra midlertidige forhold, for eksempel manglende fastvarestøtte eller forsinkede OEM-oppdateringer.
Administratorer kan spore fremdriften ved å koordinere registertilstand med oppføringer i hendelsesloggen. Registerverdier som UEFICA2023Status, UEFICA2023Error og UEFICA2023ErrorEvent, sammen med AvailableUpdates-bitmasken, angir hvilket trinn som er aktivt, fullført eller blokkert.
Denne kombinasjonen viser om enheten går normalt, prøver en operasjon på nytt eller har stoppet.
Integrasjon med OEM-fastvare
Sertifikatoppdateringer for sikker oppstart er avhengig av riktig virkemåte og støtte i enhetens UEFI-fastvare. Mens Windows orkestrerer oppdateringsprosessen, er fastvaren ansvarlig for å håndheve Secure Boot-policyen og vedlikeholde Secure Boot-databasene.
OEM-er har to kritiske elementer som muliggjør vedlikehold av Secure Boot-sertifikater:
- Plattformnøkkelsignerte nøkkelutvekslingsnøkler (KEK-er) som autoriserer installasjon av nye Secure Boot-sertifikater.
- Fastvareimplementeringer som bevarer, tilføyer og validerer Secure Boot-databaser på riktig måte under oppdateringer.
Hvis fastvaren ikke støtter disse virkemåtene fullt ut, kan Sikker oppstart-oppdateringer stoppe, prøve på nytt i det uendelige eller føre til oppstartsfeil. I disse tilfellene kan ikke Windows fullføre oppdateringen uten endringer i fastvaren.
Microsoft samarbeider med OEM-er for å identifisere fastvareproblemer og gjøre utbedrede oppdateringer tilgjengelige. Når feilsøking indikerer en fastvarebegrensning eller -defekt, må administratorer kanskje installere den nyeste UEFI-fastvareoppdateringen levert av enhetsprodusenten før oppdateringer av Secure Boot-sertifikatet kan fullføres.
Vanlige feilscenarier og løsninger
Secure Boot-oppdateringer brukes av den planlagte oppgaven Secure-Boot-Update basert på AvailableUpdates-registertilstanden .
Under normale forhold skjer disse trinnene automatisk og registrerer vellykkede hendelser etter hvert som hver fase fullføres. I noen tilfeller kan fastvarevirkemåte, plattformkonfigurasjon eller vedlikeholdskrav hindre fremdrift eller føre til uventet oppstartsvirkemåte.
Avsnittene nedenfor beskriver de vanligste feilscenarioene, hvordan du gjenkjenner dem, hvorfor de oppstår, og de nødvendige neste trinnene for å gjenopprette normal drift. Scenarioene er sortert fra de vanligste tilfellene til mer alvorlige tilfeller som påvirker oppstarten.
Sikker oppstart-oppdateringer gjelder ikke (ingen fremdrift)
Når Secure Boot-oppdateringer ikke viser fremdrift, betyr det vanligvis at oppdateringsprosessen aldri startet. Derfor mangler de forventede registerverdiene og hendelsesloggene for Secure Boot fordi oppdateringsmekanismen aldri ble utløst.
Hva skjedde
Oppdateringsprosessen for Secure Boot startet ikke, slik at ingen Secure Boot-sertifikater eller oppdatert oppstartsbehandling ble brukt på enheten.
Slik gjenkjenner du det
- Det finnes ingen registerverdier for Secure Boot-tjenester, for eksempel UEFICA2023Status.
- Forventede Secure Boot-hendelser (for eksempel 1043, 1044, 1045, 1799, 1801) mangler i systemhendelsesloggen.
- Enheten fortsetter å bruke eldre Secure Boot-sertifikater og oppstartskomponenter.
Hvorfor det skjer
Dette scenariet oppstår vanligvis når én eller flere av følgende betingelser er oppfylt:
- Den planlagte oppgaven Secure-Boot-Update er deaktivert eller mangler.
- Sikker oppstart er deaktivert i UEFI-fastvare.
- Enheten oppfyller ikke forutsetningene for Windows-service, for eksempel at den kjører en støttet Windows-versjon eller at nødvendige oppdateringer er installert.
Neste trinn
- Kontroller at enheten oppfyller kravene til Windows-vedlikehold og plattformkvalifisering.
- Bekreft at sikker oppstart er aktivert i fastvaren.
- Kontroller at den planlagte oppgaven SecureBootUpdate finnes og er aktivert.
Hvis den planlagte oppgaven er deaktivert eller mangler, følger du veiledningen i Sikker oppstart planlagt oppgave deaktivert eller slettet for å gjenopprette den. Når oppgaven er gjenopprettet, starter du enheten på nytt eller kjører oppgaven manuelt for å starte service av sikker oppstart.
Enheten starter i BitLocker-gjenoppretting etter Sikker oppstart-oppdatering
I noen tilfeller kan Sikker oppstart-relaterte oppdateringer føre til at en enhet går inn i BitLocker-gjenoppretting. Atferden kan være forbigående eller vedvarende, avhengig av den underliggende årsaken.
Scenario 1: Engangs BitLocker-gjenoppretting etter sikker oppstart-oppdatering
Hva som skjer
Enheten går inn i BitLocker-gjenoppretting ved første oppstart etter Sikker oppstart-oppdateringen, men starter normalt ved påfølgende omstarter.
Hvorfor det skjer
Under den første oppstarten etter oppdateringen rapporterer ikke fastvaren de oppdaterte verdiene for sikker oppstart når Windows prøver å forsegle BitLocker på nytt. Dette fører til en midlertidig uoverensstemmelse i målte oppstartsverdier og utløser gjenoppretting. Ved neste oppstart rapporterer fastvaren de oppdaterte verdiene på riktig måte, BitLocker reaktiveres på nytt, og problemet oppstår ikke.
Slik gjenkjenner du det
- BitLocker-gjenoppretting skjer én gang.
- Når du har angitt gjenopprettingsnøkkelen, ber ikke påfølgende oppstarter om gjenoppretting.
- Det finnes ingen pågående oppstartsordre eller PXE-involvering.
Neste trinn
- Skriv inn BitLocker-gjenopprettingsnøkkelen for å gjenoppta Windows.
- Se etter fastvareoppdateringer.
Scenario 2: Gjentatt BitLocker-gjenoppretting på grunn av PXE første oppstartskonfigurasjon
Hva som skjer
Enheten går inn i BitLocker-gjenoppretting ved hver oppstart.
Hvorfor det skjer
Enheten er konfigurert til å prøve PXE-oppstart (nettverk) først. PXE-oppstartsforsøket mislykkes, og fastvaren faller deretter tilbake til Windows-oppstartsbehandling på disken.
Dette resulterer i at to forskjellige signeringsinstanser måles i løpet av en enkelt oppstartssyklus:
- PXE-oppstartsbanen er signert av Microsoft UEFI CA 2011.
- Windows-oppstartsbehandlingen på disken er signert av Windows UEFI CA 2023.
Fordi BitLocker observerer ulike klareringskjeder for Secure Boot under oppstart, kan den ikke etablere et stabilt sett med TPM-målinger å forsegle på nytt mot. Som et resultat går BitLocker inn i gjenoppretting ved hver oppstart.
Slik gjenkjenner du det
- BitLocker-gjenoppretting utløses ved hver omstart.
- Ved å skrive inn gjenopprettingsnøkkelen kan Windows starte, men meldingen kommer tilbake ved neste oppstart.
- PXE eller nettverksoppstart konfigureres foran den lokale disken i fastvareoppstartsrekkefølge.
Neste trinn
- Konfigurer oppstartsrekkefølgen for fastvaren, slik at Windows-oppstartsbehandlingen på disken kommer først.
- Deaktiver PXE-oppstart hvis det ikke er nødvendig.
- Hvis PXE kreves, sørg for at PXE-infrastrukturen bruker en 2023-signert Windows-oppstartslaster.
Enheten starter ikke etter tilbakestilling av Sikker oppstart
Hva skjedde
Dette gjenspeiler en endring på fastvarenivå snarere enn et Windows-problem. Sikker oppstart-oppdateringen ble fullført, men etter en senere omstart starter ikke enheten opp i Windows.
Slik gjenkjenner du det
- Enheten starter ikke Windows og kan vise en fastvare- eller BIOS-melding som angir brudd på Secure Boot.
- Feilen oppstår etter at innstillingene for sikker oppstart tilbakestilles til standardinnstillingene for fastvaren.
- Hvis du deaktiverer Sikker oppstart, kan enheten starte på nytt.
Hvorfor det skjer
Hvis du tilbakestiller Secure Boot til fastvarestandarder, tømmes Secure Boot-databasene som er lagret i fastvaren. På enheter som allerede har gått over til den Windows UEFI CA 2023-signerte oppstartsbehandlingen, fjerner denne tilbakestillingen sertifikatene som kreves for å klarere denne oppstartsbehandlingen.
Som et resultat gjenkjenner ikke fastvaren lenger den installerte Windows oppstartsbehandlingen som klarert og blokkerer oppstartsprosessen.
Dette scenariet forårsakes ikke av selve Sikker oppstart-oppdateringen, men av en påfølgende fastvarehandling som fjerner de oppdaterte klareringsankrene.
Neste trinn
- Bruk gjenopprettingsverktøyet for sikker oppstart til å gjenopprette det nødvendige sertifikatet, slik at enheten kan starte på nytt.
- Etter gjenopprettingen må du kontrollere at enheten har den nyeste tilgjengelige fastvaren installert fra enhetsprodusenten.
- Unngå å tilbakestille Secure Boot til fastvarestandarder med mindre OEM-fastvaren inkluderer oppdaterte Secure Boot-standarder som stoler på 2023-sertifikatene.
Gjenopprettingsverktøy for sikker oppstart
Slik gjenoppretter du systemet:
- På en annen Windows-PC med Windows-oppdateringen for juli 2024 eller nyere installert, kopierer du SecureBootRecovery.efi fra C:\Windows\Boot\EFI\.
- Plasser filen på en FAT32-formatert USB-stasjon under \EFI\BOOT\ og gi den nytt navn til bootx64.efi.
- Start den berørte enheten fra USB-stasjonen, og la gjenopprettingsverktøyet kjøre. Verktøyet legger til Windows UEFI CA 2023 i databasen.
Når sertifikatet er gjenopprettet og systemet startes på nytt, skal Windows starte som normalt.
Viktig: Denne prosessen bruker bare ett av de nye sertifikatene på nytt. Når enheten er gjenopprettet, må du kontrollere at de nyeste sertifikatene er brukt på nytt, og vurdere å oppdatere systemets BIOS/UEFI til den nyeste versjonen som er tilgjengelig. Dette kan bidra til å forhindre en gjentakelse av problemet med tilbakestilling av Secure Boot, siden mange OEM-er har gitt ut fastvarereparasjoner for dette spesifikke problemet.
Enheten starter ikke etter Sikker oppstart-oppdatering på grunn av at fastvare overskriver DB-en
Hva skjedde
Når du har brukt oppdateringen av Secure Boot-sertifikatet og startet på nytt, starter ikke enheten og når ikke Windows.
Slik gjenkjenner du det
- Enheten mislykkes umiddelbart etter omstarten som kreves av Secure Boot-oppdateringen.
- En fastvarefeil eller Secure Boot-feil kan vises, eller systemet kan stoppe før Windows lastes inn.
- Hvis du deaktiverer Sikker oppstart, kan enheten starte.
Hvorfor det skjer
Dette problemet kan skyldes en feil i implementeringen av enhetens UEFI-fastvare.
Når Windows bruker sertifikatoppdateringer for sikker oppstart, forventes det at fastvaren legger til nye sertifikater i den eksisterende databasen for tillatt signatur (DB) for sikker oppstart. Noen fastvareimplementeringer overskriver databasen på feil måte i stedet for å tilføye den.
Når dette skjer,
- Tidligere klarerte sertifikater, inkludert Microsoft 2011 bootloader-sertifikatet, fjernes.
- Hvis systemet fortsatt bruker en oppstartsbehandling som er signert med 2011-sertifikatet på det tidspunktet, stoler ikke fastvaren på det lenger.
- Fastvaren avviser oppstartsbehandleren og blokkerer oppstartsprosessen.
I noen tilfeller kan DB-en også bli skadet i stedet for å overskrives rent, noe som fører til samme resultat. Denne virkemåten er observert i bestemte fastvareimplementeringer og forventes ikke på kompatibel fastvare.
Neste trinn
- Gå inn i fastvareoppsettmenyene, og prøv å tilbakestille innstillingene for Secure Boot.
- Hvis enheten starter etter tilbakestillingen, kan du se etter en fastvareoppdatering på enhetsprodusentens nettsted for kundestøtte som retter håndtering av Secure Boot DB.
- Hvis en fastvareoppdatering er tilgjengelig, må du installere den før du aktiverer Secure Boot på nytt og bruker Secure Boot-sertifikatoppdateringer på nytt.
Hvis tilbakestilling av Sikker oppstart ikke gjenoppretter oppstartsfunksjonaliteten, krever ytterligere gjenoppretting sannsynligvis OEM-spesifikk veiledning.
Sikker oppstart-oppdatering blokkert på grunn av manglende OEM-signert KEK
Hva skjedde
Oppdateringen av sertifikatet for sikker oppstart er ikke fullført og forblir blokkert under oppdateringen av nøkkelutvekslingsnøkkelen (KEK).
Slik gjenkjenner du det
- Registerverdien AvailableUpdates forblir angitt med KEK-biten (0x0004) og blir ikke fjernet.
- UEFICA2023Status går ikke videre til en fullført tilstand.
- Systemhendelsesloggen registrerer hendelses-ID 1803 gjentatte ganger, noe som indikerer at KEK-oppdateringen ikke kunne brukes.
- Enheten fortsetter å prøve oppdateringen på nytt uten å gjøre fremdrift.
Hvorfor det skjer
Oppdatering av Secure Boot KEK krever autorisasjon fra enhetens plattformnøkkel (PK), som eies av OEM.
For at oppdateringen skal lykkes, må enhetsprodusenten gi Microsoft en PK-signert KEK for den bestemte plattformen. Denne OEM-signerte KEK er inkludert i Windows-oppdateringer og gjør det mulig for Windows å oppdatere fastvare-KEK-variabelen.
Hvis OEM-en ikke har levert en PK-signert KEK for enheten, kan ikke Windows fullføre KEK-oppdateringen. I denne tilstanden:
- Sikker oppstart-oppdateringer er blokkert av design.
- Windows kan ikke omgå den manglende autorisasjonen.
- Enheten kan forbli ute av stand til å fullføre service av Secure Boot-sertifikatet.
Dette kan skje på eldre enheter eller enheter som ikke støttes, der OEM-en ikke lenger tilbyr fastvare- eller nøkkeloppdateringer. Det finnes ingen støttet manuell gjenopprettingsbane for denne tilstanden.
Oppdateringshendelser og feilindikatorer for sertifikat for sikker oppstart
Når sertifikatoppdateringer for sikker oppstart ikke brukes, registrerer Windows diagnosehendelser som forklarer hvorfor fremdriften ble blokkert. Disse hendelsene skrives når oppdatering av Secure Boot signature database (DB) eller Key Exchange Key (KEK) ikke kan fullføres trygt på grunn av fastvare, plattformtilstand eller konfigurasjonsforhold. Scenariene i denne delen refererer til disse hendelsene for å identifisere vanlige feilmønstre og fastslå den hensiktsmessige utbedringen. Denne delen er ment å støtte diagnostisering og tolkning av problemene som er beskrevet tidligere, ikke å introdusere nye feilscenarier.
Hvis du vil ha en fullstendig liste over hendelses-ID-er, beskrivelser og eksempeloppføringer, kan du se Secure Boot DB og DBX variable update events (KB5016061).
KEK-oppdateringsfeil (DB-oppdateringer lykkes, KEK gjør det ikke)
En enhet kan oppdatere sertifikater i Secure Boot DB, men mislykkes under KEK-oppdateringen. Når dette skjer, kan ikke Sikker oppstart-oppdateringen fullføres.
Symptomer
- DB-sertifikathendelser angir fremdrift, men KEK-fasen er ikke fullført.
- AvailableUpdates forblir satt til 0x4004, og den 0x0004 biten fjernes ikke etter at flere oppgaver kjøres.
- Hendelsen 1795 eller 1803 kan være til stede.
Tolkning
- 1795 angir vanligvis feil i fastvaren under forsøk på å oppdatere en Secure Boot-variabel.
- 1803 angir at KEK-oppdateringen ikke kan godkjennes fordi en nødvendig OEM PK-signert KEK-nyttelast ikke er tilgjengelig for plattformen.
Neste trinn
- For 1795 ser du etter OEM-fastvareoppdateringer og kontrollerer fastvarestøtten for variable oppdateringer for sikker oppstart.
- For 1803 bekrefter du om OEM-en har gitt Microsoft den PK-signerte KEK som kreves for enhetsmodellen.
KEK-oppdateringsfeil på virtuelle gjestemaskiner driftet på Hyper-V
På virtuelle Hyper-V-maskiner krever sertifikatoppdateringer for sikker oppstart at Windows-oppdateringene for mars 2026 er installert på både Hyper-V-verten og gjesteoperativsystemet.
Oppdateringsfeil rapporteres fra gjesten, men hendelsen indikerer hvor utbedring kreves:
- Hendelse 1795 (for eksempel «Mediet er skrivebeskyttet») rapportert i gjesten angir at Hyper-V-verten mangler oppdateringen for mars 2026 og må oppdateres.
- Hendelse 1803 rapportert i gjesten angir at selve den virtuelle gjestemaskinen mangler oppdateringen for mars 2026 og må oppdateres.
Referanser og interne elementer
Denne delen inneholder avansert referanseinformasjon ment for feilsøking og støtte. Den er ikke ment for distribusjonsplanlegging. Den viderefører Secure Boot-servicemekanikken som ble oppsummert tidligere, og gir detaljert referansemateriale for tolkning av registertilstand og hendelseslogger.
Obs! Når du konfigurerer via gruppepolicy eller Microsoft Intune, bør du ikke forveksle to lignende innstillinger. Verdien AvailableUpdatesPolicy representerer den konfigurerte policytilstanden. I mellomtiden gjenspeiler AvailableUpdates den pågående arbeidstilstanden for bitfjerning. Begge kan gi samme resultat, men de fungerer forskjellig fordi policyen gjelder på nytt over tid.
AvailableUpdates-biter som brukes til sertifikatservice
Bitene nedenfor brukes for handlingene for sertifikat- og oppstartsbehandling som er beskrevet i dette dokumentet. Rekkefølge-kolonnen gjenspeiler rekkefølgen som oppgaven Secure-Boot-Update behandler hver bit i.
| Rekkefølge | Bit-innstilling | Bruk |
|---|---|---|
| 1 | 0x0040 | Denne biten forteller den planlagte oppgaven å legge til Windows UEFI CA 2023-sertifikatet i databasen for sikker oppstart. Dette gjør at Windows kan klarere oppstartsbehandlere som er signert med dette sertifikatet. |
| 2 | 0x0800 | Denne biten forteller den planlagte oppgaven å bruke Microsoft Option ROM UEFI CA 2023 på DB. Betinget virkemåte: Når 0x4000 flagget er angitt, vil den planlagte oppgaven først kontrollere databasen for Microsoft Corporation UEFI CA 2011-sertifikatet . Det vil bare bruke Microsoft Option ROM UEFI CA 2023-sertifikatethvis 2011-sertifikatet finnes. |
| 3 | 0x1000 | Denne biten forteller den planlagte oppgaven å bruke Microsoft UEFI CA 2023 på databasen. Betinget virkemåte: Når 0x4000 flagget er angitt, vil den planlagte oppgaven først kontrollere databasen for Microsoft Corporation UEFI CA 2011-sertifikatet . Det vil bare bruke Microsoft UEFI CA 2023-sertifikatethvis 2011-sertifikatet finnes. |
| Modifikator (virkemåteflagg) | 0x4000 | Denne biten endrer virkemåten til 0x0800 og 0x1000 bitene slik at Microsoft UEFI CA 2023 og Microsoft Option ROM UEFI CA 2023 bare brukes hvis DB-en allerede inneholder Microsoft Corporation UEFI CA 2011. For å bidra til å sikre at enhetens sikkerhetsprofil forblir den samme, bruker denne biten bare disse nye sertifikatene hvis enheten stoler på Microsoft Corporation UEFI CA 2011-sertifikatet. Ikke alle Windows-enheter stoler på dette sertifikatet. |
| 4 | 0x0004 | Denne biten ber den planlagte oppgaven se etter en nøkkelutvekslingsnøkkel signert med enhetens plattformnøkkel (PK). PK administreres av OEM. OEM-er signerer Microsoft KEK med sin PK og leverer den til Microsoft der den er inkludert i månedlige kumulative oppdateringer. |
| 5 | 0x0100 | Denne biten forteller den planlagte oppgaven å bruke oppstartsbehandlingen, signert av Windows UEFI CA 2023, på oppstartspartisjonen. Dette erstatter den signerte oppstartsbehandlingen for Microsoft Windows Production PCA 2011 . |
Merknader:
- Den 0x4000 biten forblir angitt etter at alle andre biter er behandlet.
- Hver bit behandles av den planlagte oppgaven Secure-Boot-Update i rekkefølgen ovenfor.
- Hvis den 0x0004 biten ikke kan behandles på grunn av en manglende PK-signert KEK, vil den planlagte oppgaven fortsatt bruke oppdateringen for oppstartsbehandling angitt av bit 0x0100.
Forventet fremdrift (TilgjengeligeOppdateringer)
Når en operasjon er fullført, fjerner Windows den tilknyttede biten fra AvailableUpdates. Hvis en operasjon mislykkes, loggfører Windows en hendelse og prøver på nytt når oppgaven kjøres på nytt.
Tabellen nedenfor viser den forventede fremdriften av AvailableUpdates-verdier etter hvert som hver oppdateringshandling for Secure Boot fullføres.
| Trinn | Bitbehandlet | Tilgjengelige Oppdateringer | Beskrivelse | Vellykket hendelse logget | Mulige feilhendelseskoder |
|---|---|---|---|---|---|
| Start | 0x5944 | Starttilstand før service av Secure Boot-sertifikat begynner. | - | - | |
| 1 | 0x0040 | 0x5944 → 0x5904 | Windows UEFI CA 2023 legges til i Secure Boot DB. | 1036 | 1032, 1795, 1796, 1802 |
| 2 | 0x0800 | 0x5904 → 0x5104 | Legg til Microsoft Option ROM UEFI CA 2023 i databasen hvis enheten tidligere klarerte Microsoft UEFI CA 2011. | 1044 | 1032, 1795, 1796, 1802 |
| 3 | 0x1000 | 0x5104 → 0x4104 | Microsoft UEFI CA 2023 legges til i DB hvis enheten tidligere klarerte Microsoft UEFI CA 2011. | 1045 | 1032, 1795, 1796, 1802 |
| 4 | 0x0004 | 0x4104 → 0x4100 | Ny Microsoft KEK 2K CA 2023, signert av OEM-plattformnøkkelen, brukes. | 1043 | 1032, 1795, 1796, 1802, 1803 |
| 5 | 0x0100 | 0x4100 → 0x4000 | Oppstartsbehandling signert av Windows UEFI CA 2023 er installert. | 1799 | 1797 |
Obs!
- Når operasjonen som er knyttet til en bit, er fullført, fjernes den biten fra AvailableUpdates.
- Hvis en av disse operasjonene mislykkes, loggføres en hendelse, og operasjonen prøves på nytt neste gang den planlagte oppgaven kjøres.
- Den 0x4000 biten er en modifikator og fjernes ikke. Den endelige verdien for AvailableUpdates på 0x4000 angir at alle gjeldende oppdateringshandlinger er fullført.
- Hendelsene 1032, 1795, 1796, 1802 angir vanligvis fastvare- eller plattformbegrensninger.
- Hendelsen 1803 angir manglende OEM PK-signert KEK.
Utbedringsprosedyrer
Denne delen inneholder trinnvise prosedyrer for å løse bestemte problemer med Secure Boot. Hver prosedyre er begrenset til en veldefinert tilstand og er ment å følges først etter at den første diagnosen bekrefter at problemet gjelder. Bruk disse fremgangsmåtene til å gjenopprette forventet virkemåte for sikker oppstart og tillate at sertifikatoppdateringer fortsetter trygt. Ikke bruk disse fremgangsmåtene bredt eller forebyggende.
Aktiverer sikker oppstart i fastvare
Hvis sikker oppstart er deaktivert i fastvaren til en enhet, kan du se Windows 11 og sikker oppstart for mer informasjon om hvordan du aktiverer sikker oppstart.
Planlagt oppgave for sikker oppstart er deaktivert eller slettet
Den planlagte oppgaven Secure-Boot-Update er nødvendig for at Windows skal kunne bruke sertifikatoppdateringer for sikker oppstart. Hvis oppgaven er deaktivert eller mangler, vil ikke vedlikehold av Secure Boot-sertifikatet komme videre.
Oppgavedetaljer
| Oppgavenavn | sikker oppstart-oppdatering |
|---|---|
| Aktivitetsbane | \Microsoft\Windows\PI\ |
| Full bane | \Microsoft\Windows\PI\Secure-Boot-Update |
| Kjører som | SYSTEM (lokalt system) |
| Utløsere | Ved oppstart og hver 12. time |
| Obligatorisk tilstand | Aktivert |
Slik sjekker du oppgavestatus
Kjør fra en hevet PowerShell-ledetekst:
schtasks.exe /query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V
Se etter Status-feltet :
| Status | Betydning |
|---|---|
| Klar | Oppgaven finnes og er aktivert. |
| Deaktivert | Oppgaven finnes, men må være aktivert. |
| Feil / Ikke funnet | Oppgaven mangler og må opprettes på nytt. |
Slik aktiverer eller oppretter du oppgaven på nytt
Hvis statusfeltet for Secure-Boot-Update er Deaktivert, Feil eller Ikke funnet, bruker du eksempelskriptet til å aktivere oppgaven: Eksempel på Enable-SecureBootUpdateTask.ps1
Obs! Dette er et eksempelskript og støttes ikke av Microsoft. Administratorer bør se gjennom og tilpasse den til miljøet.
Eksempel:
Obs!
.\Enable-SecureBootUpdateTask.ps1 -Stille
Kjør veiledning
- Hvis du ser Ingen tilgang, kjører du PowerShell på nytt som administrator.
- Hvis skriptet ikke kan kjøre på grunn av kjøringspolicy, kan du bruke en omgåelse av prosessomfang:
Obs!
Set-ExecutionPolicy -Omfangsprosess -Omgåelse av ExecutionPolicy