Secure Booti tõrkeotsingujuhend

Kui Secure Booti värskendused ei näita edenemist, tähendab see tavaliselt, et värskendusprotsessi ei alustatud kunagi. Seetõttu puuduvad eeldatavad Secure Booti registriväärtused ja sündmuselogid, kuna värskendusmehhanismi ei käivitatud kunagi.

Mis juhtus

Secure Booti värskendamise protsess ei käivitunud, seega ei rakendatud seadmele turbekäivituse serte ega värskendatud käivitushaldurit.

Kuidas seda ära tunda?

• Secure Booti teeninduse registriväärtusi pole (nt UEFICA2023Status).

• Eeldatud turvalise algkäivituse sündmused (nt 1043, 1044, 1045, 1799, 1801) on süsteemi sündmuselogist puudu.

• Seade kasutab jätkuvalt vanemaid Secure Booti serte ja algkäivituse komponente.

Miks see juhtub?

See stsenaarium ilmneb tavaliselt siis, kui üks või mitu järgmistest tingimustest on täidetud:

• Secure-Boot-Update'i ajastatud toiming on keelatud või puudub.

• Turvaline käivitamine on UEFI püsivara puhul keelatud.

• Seade ei vasta Windowsi teeninduse eeltingimustele ( nt kas käitate toetatud Windowsi versiooni või olete installinud nõutavad värskendused).

Mida edasi teha?

• Veenduge, et seade vastaks Windowsi teeninduse ja platvormi nõuetele.

• Veenduge, et turvaline käivitamine oleks püsivara puhul lubatud.

• Veenduge, et SecureBootUpdate'i ajastatud toiming oleks olemas ja lubatud.

Kui ajastatud toiming on keelatud või puudub, järgige selle taastamiseks teemas Secure Booti ajastatud toiming keelatud või kustutatud toodud juhiseid. Pärast toimingu taastamist taaskäivitage seade või käivitage toiming Secure Booti teeninduse käivitamiseks käsitsi.

Mõnel juhul võivad turvalise käivitamisega seotud värskendused põhjustada seadme sisenemist BitLockeri taasteteenusesse. Sõltuvalt selle aluseks olevast põhjusest võib käitumine olla mööduv või püsiv.

1. stsenaarium: Onetime BitLockeri taaste pärast secure Booti värskendust

Mis juhtub?

Seade siseneb BitLockeri taaste esimesele algkäivitusele pärast secure Booti värskendust, kuid käivitub tavaliselt järgmisel taaskäivitamisel.

Miks see juhtub?

Pärast värskendamist esimesel algkäivitusel ei teata püsivara veel värskendatud turvalise algkäivituse väärtustest, kui Windows proovib BitLockerit uuesti kasutada. See põhjustab ajutise lahknevuse mõõdetud algkäivitusväärtustes ja käivitab taaste. Järgmisel algkäivitusel teatab püsivara värskendatud väärtused õigesti, BitLocker uuesti ja probleem ei kordu.

Kuidas seda ära tunda?

• BitLockeri taastamine toimub üks kord.

• Pärast taastevõtme sisestamist ei küsi järgmised algkäivitused taastet.

• Käimasolevat algkäivitusjärjestust ega PXE-ga seotud tellimust pole olemas.

Mida edasi teha?

• Windowsi jätkamiseks sisestage BitLockeri taastevõti.

• Otsige püsivaravärskendusi.

2. stsenaarium: korduv BitLockeri taaste PXE esimese algkäivituse konfiguratsiooni tõttu

Mis juhtub?

Seade siseneb BitLockeri taaste iga algkäivituse.

Miks see juhtub?

Seade on konfigureeritud proovima esmalt PXE (võrgu) algkäivitamist. PXE algkäivituskatse nurjub ja püsivara läheb seejärel tagasi kettal töötava Windowsi algkäivitushalduri juurde.

Selle tulemusena mõõdetakse ühe algkäivitustsükli jooksul kahte erinevat allkirjastamisasutust:

• PXE algkäivitustee on allkirjastanud Microsoft UEFI CA 2011.

• Kettal töötava Windowsi käivitushalduri on allkirjastanud Windows UEFI CA 2023.

Kuna BitLocker jälgib käivitamisel erinevaid Secure Booti usalduskette, ei saa see luua stabiilset TPM-i mõõtmiste kogumit, millega uuesti töötada. Selle tulemusena siseneb BitLocker taaste iga algkäivituse.

Kuidas seda ära tunda?

• BitLockeri taaste käivitatakse igal taaskäivitamisel.

• Taastevõtme sisestamine võimaldab Windowsil käivituda, kuid viip naaseb järgmisel algkäivitusel.

• PXE või võrgu algkäivitus on konfigureeritud püsivara algkäivitusjärjestuses enne kohalikku ketast.

Mida edasi teha?

• Konfigureerige püsivara algkäivituse järjestus, et kettal olev Windowsi käivitushaldur oleks esimene.

• Kui PXE-algkäivitus pole nõutav, keelake see.

• Kui PXE on nõutav, veenduge, et PXE-taristu kasutaks 2023-allkirjastatud Windowsi algkäivituslaadurit.

Mis juhtus

See kajastab püsivarataseme muudatust, mitte Windowsi probleemi. Turvaline algkäivituse värskendus on lõpule viidud, kuid pärast hilisemat taaskäivitamist ei käivitu seade enam Windowsis.

Kuidas seda ära tunda?

• Seade ei käivita Windowsi ja võib kuvada püsivara või BIOS-i teate, mis viitab turvalise algkäivituse rikkumisele.

• Tõrge ilmneb pärast turvalise algkäivituse sätete lähtestamist püsivara vaikesäteteks.

• Turvalise käivitamise keelamine võib lubada seadmel uuesti algkäivitada.

Miks see juhtub?

Turvalise algkäivituse lähtestamisel püsivara vaikesätetele kustutatakse püsivarasse salvestatud secure Booti andmebaasid. Seadmetes, mis on juba üle minna Windows UEFI CA 2023 allkirjastatud käivitushaldur, see lähtestamine eemaldab serdid, mis on vajalikud selle käivitushalduri usaldamiseks.

Selle tulemusena ei tuvasta püsivara enam installitud Windowsi käivitushaldurit usaldusväärsena ja blokeerib algkäivitusprotsessi.

Seda stsenaariumi ei põhjusta Secure Booti värskendus ise, vaid sellele järgnev püsivara toiming, mis eemaldab värskendatud usaldusankrud.

Mida edasi teha?

• Vajaliku serdi taastamiseks kasutage Secure Booti taasteutiliiti, et seade saaks uuesti algkäivitada.

• Pärast taastamist veenduge, et seadmel oleks seadme tootjalt installitud uusim saadaolev püsivara.

• Vältige turvalise algkäivituse lähtestamist püsivara vaikesätetele, kui OEM-i püsivara ei sisalda värskendatud turbekäivituse vaikesätteid, mis usaldavad 2023 serte.

Secure Booti taasteutiliit

Süsteemi taastamiseks tehke järgmist.

1. Teise Windowsi arvutisse, kuhu on installitud 2024. aasta juuli või uuem Windowsi värskendus, kopeerige SecureBootRecovery.efi kohast C:\Windows\Boot\EFI\.

2. Paigutage fail FAT32-vormingus USB-draivile jaotises \EFI\BOOT\ ja nimetage see ümber bootx64.efi-ks.

3. Käivitage mõjutatud seade USB-draivilt ja lubage taasteutiliidi käivitamine. Utiliit lisab Windows UEFI CA 2023 andmebaasi.

Pärast serdi taastamist ja süsteemi taaskäivitamist peaks Windows käivituma tavapäraselt.

Oluline: Selle toiminguga rakendatakse uuesti ainult üks uus sert. Kui seade on taastatud, veenduge, et selle uusimad serdid oleksid uuesti rakendatud, ja kaaluge süsteemi BIOS-i/UEFI-liidese värskendamist uusimale saadaolevale versioonile. See võib takistada turvalise algkäivituse lähtestamise probleemi kordumist, kuna paljud OEM-id on välja andnud selle konkreetse probleemi püsivaraparandused.

Mis juhtus

Pärast secure Boot serdi värskenduse rakendamist ja taaskäivitamist ei käivitu seade ja ei jõua Windowsi.

Kuidas seda ära tunda?

• Seade nurjub kohe pärast Secure Booti värskenduse nõutavat taaskäivitamist.

• Võidakse kuvada püsivara või turvalise käivitamise tõrge või süsteem võib peatuda enne Windowsi laadimist.

• Turvalise käivitamise keelamine võib lubada seadmel algkäivitada.

Miks see juhtub?

Selle probleemi põhjuseks võib olla seadme UEFI püsivara juurutamise viga.

Kui Windows rakendab turvalise käivitamise serdi värskendused, eeldatakse, et püsivara lisab olemasolevale turvalise algkäivituse lubatud allkirjaandmebaasile (DB) uued serdid. Mõned püsivara juurutamised kirjutavad DB sellele lisamise asemel valesti üle.

Sel juhul

• Eemaldatakse varem usaldusväärsed serdid, sh Microsoft 2011 alglaaduri sert.

• Kui süsteem kasutab endiselt 2011. aasta serdiga allkirjastatud käivitushaldurit, ei usalda püsivara seda enam.

• Püsivara hülgab käivitushalduri ja blokeerib algkäivitusprotsessi.

Mõnel juhul võib andmebaasi ka rikutud saada, mitte üle kirjutada, mistõttu tulemus on sama. Seda käitumist on täheldatud kindlates püsivara juurutamistes ja seda ei eeldata ühilduvas püsivaras.

Mida edasi teha?

• Sisestage püsivara häälestuse menüüd ja proovige lähtestada turvalise algkäivituse sätteid.

• Kui seade käivitub pärast lähtestamist, otsige seadme tootja tugiteenuste saidilt püsivaravärskendust, mis parandab Secure Boot DB käsitsemist.

• Kui püsivaravärskendus on saadaval, installige see enne secure Booti uuesti lubamist ja secure Booti serdi värskenduste uuesti rakendamist.

Kui turvalise algkäivituse lähtestamine ei taasta algkäivitusfunktsiooni, on edasiseks taastamiseks tõenäoliselt vaja OEM-i kohaseid juhiseid.

Mis juhtus

Secure Booti serdi värskendamist ei viida lõpule ja see jääb Võtme Exchange'i võtme (KEK) värskendusetapis blokeerituks.

Kuidas seda ära tunda?

• AvailableUpdatesi registriväärtus jääb keK-bitise (0x0004) väärtuseks ja seda ei kustutata.

• UEFICA2023Status ei edene lõpuleviidud olekusse.

• Süsteemisündmuselogi salvestab korduvalt sündmuse ID-d 1803, mis näitab, et KEK-i värskendust ei saanud rakendada.

• Seade proovib värskendust uuesti ilma edasiminekut tegemata.

Miks see juhtub?

Secure Boot KEK-i värskendamiseks on vaja autoriseerimist OEM-ile kuuluva seadme platvormivõtme (PK) kaudu.

Värskenduse õnnestumiseks peab seadme tootja andma Microsoftile PK-allkirjaga KEK-i konkreetse platvormi jaoks. See OEM-i allkirjastatud KEK sisaldub Windowsi värskendustes ja võimaldab Windowsil värskendada püsivara KEK muutujat.

Kui OEM pole seadme jaoks PK-allkirjaga KEK-i esitanud, ei saa Windows KEK-i värskendust lõpule viia. Selles olekus:

• Secure Booti värskendused on kujunduse järgi blokeeritud.

• Windows ei saa puuduva autoriseerimisega töötada.

• Seade ei saa secure Booti serdi hooldust jäädavalt lõpule viia.

See võib juhtuda vanemates või toe lõppemise seadmetes, kus OEM ei paku enam püsivara- ega võtmevärskendusi. Selle tingimuse jaoks pole toetatud käsitsi taastamise teed.

tagasi üles

Kui turvalise algkäivituse serdi värskenduste rakendamine nurjub, salvestab Windows diagnostikasündmused, mis selgitavad, miks edenemine blokeeriti. Need sündmused kirjutatakse Secure Booti signatuuri andmebaasi (DB) või Key Exchange Key (KEK) värskendamisel ei saa püsivara, platvormi oleku või konfiguratsioonitingimuste tõttu ohutult lõpule viia. Selle jaotise stsenaariumid viitavad nendele sündmustele, et tuvastada levinud tõrkemustrid ja määratleda sobiv parandus. Selle jaotise eesmärk on toetada eespool kirjeldatud probleemide diagnoosimist ja tõlgendamist, mitte uute tõrkestsenaariumide sisseseadmist.

Sündmuste ID-de, kirjelduste ja näidiskirjete täieliku loendi leiate teemast Secure Boot DB ja DBX muutuja värskendussündmused (KB5016061).

KEK värskendustõrge (DB värskendused õnnestuvad, KEK seda ei tee)

Seade saab secure Boot DB serte värskendada, kuid KEK-i värskendamise ajal nurjub. Selle ilmnemisel ei saa Secure Booti värskendamist lõpule viia.

Tunnused

• DB serdi sündmused näitavad edenemist, kuid KEK-etappi ei viida lõpule.

• AvailableUpdates jääb väärtuseks 0x4004 ja pärast mitme toimingu käitamist 0x0004 bitti ei tühjendata.

• Sündmus 1795 või 1803 võib olla olemas.

Tõlgendamine

• 1795 tähistab tavaliselt püsivara tõrget secure Booti muutuja värskendamise katsel.

• 1803 näitab, et KEK värskendust ei saa autoriseerimiseks lubada, kuna nõutav OEM-i PK allkirjastatud KEK-i last pole platvormi jaoks saadaval.

Järgmised toimingud

• Operatsioonisüsteemis 1795 otsige OEM-i püsivaravärskendusi ja valideerige secure Booti muutujatega värskenduste püsivaratugi.

• Operatsioonisüsteemis 1803 kontrollige, kas OEM on andnud Microsoftile seadme mudeli jaoks nõutava PK-allkirjaga KEK-i.

KEK värskendustõrge Hyper-V-s majutatud külalis-virtuaalarvutites 

Hyper-V virtuaalarvutites peavad turvalise algkäivituse serdi värskendused nii Hyper-V hosti kui ka guest OS-i jaoks olema installitud 2026. aasta märtsi Windowsi värskendused.

Värskendamistõrgetest teatatakse külalises, kuid sündmus näitab, kus on vaja parandust teha.

• Sündmus 1795 (nt "Meedium on kirjutuskaitstud") on külalises teatatud, et Hyper-V hostil puudub 2026. aasta märtsi värskendus ja see tuleb värskendada.

• Sündmus 1803 , millest teatati külalises, näitab, et külalisvirtarvutil endal puudub 2026. aasta märtsi värskendus ja see tuleb värskendada.