Ghid de depanare secure Boot
Se aplică la
Data de publicare inițială: 19 martie 2026
ID KB: 5085046
În acest articol
Prezentare generală
Această pagină ghidează administratorii și specialiștii în asistență în diagnosticarea și rezolvarea problemelor legate de bootarea securizată pe dispozitivele Windows. Printre subiecte se numără erorile de actualizare a certificatului de bootare securizată, stările de bootare securizată incorecte, solicitările de recuperare BitLocker neașteptate și erorile de boot după modificările de configurație secure Boot.
Instrucțiunile vă arată cum să verificați service-ul și configurarea Windows, să revizuiți valorile de registry relevante și jurnalele de evenimente și să identificați când limitările firmware-ului sau platformei necesită o actualizare OEM. Acest conținut este destinat diagnosticării problemelor de pe dispozitivele existente. Aceasta nu este destinată planificării de implementări noi. Acest document va fi actualizat pe măsură ce sunt identificate noi scenarii de depanare și instrucțiuni.
Cum funcționează service-ul certificatului Secure Boot
Serviciul Secure Boot Certificate Service din Windows este un proces coordonat între sistemul de operare și firmware-ul UEFI al dispozitivului. Scopul este să actualizați ancorele critice de încredere, păstrând în același timp capacitatea de a boota în fiecare etapă.
Procesul este condus de o activitate programată Windows, o secvență de acțiuni de actualizare bazate pe registry și un comportament încorporat de înregistrare în jurnal și reîncercare. Împreună, aceste componente asigură că certificatele Secure Boot și managerul de boot Windows sunt actualizate într-o manieră controlată, ordonată și numai după ce pașii necesari reușesc.
De unde să începeți atunci când depanați
Atunci când un dispozitiv nu pare să facă progresul așteptat prin aplicarea actualizărilor certificatului de bootare securizată, începeți prin a identifica categoria problemei. Majoritatea problemelor se încadrează într-una dintre cele patru zone: starea serviciilor Windows, mecanismul de actualizare secure boot, comportamentul firmware-ului sau o platformă sau limitareA OEM.
Începeți cu verificările de mai jos, în ordine. În multe cazuri, acești pași sunt suficienți pentru a explica comportamentul observat și pentru a determina acțiunile următoare fără investigații aprofundate.
-
Confirmați eligibilitatea pentru serviciile și platforma Windows
-
Verificați dacă dispozitivul îndeplinește cerințele de bază pentru a primi actualizări ale certificatului de bootare securizată:
-
Dispozitivul rulează o versiune acceptată de Windows.
-
Sunt instalate cele mai recente actualizări de securitate Windows necesare.
-
Bootul securizat este activat în firmware-ul UEFI.
-
Dacă oricare dintre aceste condiții nu sunt îndeplinite, remediați-le înainte de a continua depanarea.
-
-
Verificați starea activității Secure-Boot-Update
-
Confirmați că mecanismul Windows responsabil cu aplicarea actualizărilor certificatelor de bootare securizată este prezent și funcționează:
-
Activitatea programată Secure-Boot-Update există.
-
Activitatea este activată și rulează ca Sistem local.
-
Activitatea a rulat cel puțin o dată de când a fost instalată cea mai recentă actualizare de securitate Windows.
-
Dacă activitatea este dezactivată, ștearsă sau nu rulează, actualizările certificatului de bootare securizată nu pot fi aplicate. Depanarea ar trebui să se concentreze pe restaurarea activității înainte de a investiga alte cauze.
-
-
Verificați setările de registry pentru progresia așteptată
Revizuiți starea de service Secure Boot a dispozitivului în registry:
-
Examinați UEFICA2023Status, UEFICA2023Error și UEFICA2023ErrorEvent.
-
Examinați AvailableUpdates și comparați-o cu progresia așteptată (consultați Referințe și Interne).
Împreună, aceste valori indică dacă service-ul progresează normal, dacă se reîncearcă o operațiune sau dacă s-a oprit la un anumit pas.
-
-
Corelați starea de registry cu evenimentele Secure Boot
Revizuiți evenimentele legate de bootarea securizată din jurnalul de evenimente de sistem și corelați-le cu starea de registry. Datele evenimentului confirmă de obicei dacă dispozitivul progresează înainte, dacă reîncearcă din cauza unei condiții tranzitorii sau dacă este blocat de o problemă de firmware sau de platformă.
Împreună, registry și jurnalele de evenimente indică de obicei dacă comportamentul este așteptat, temporar sau necesită acțiuni corective.
Secure-Boot-Update scheduled task
Service-ul secure boot certificate este implementat printr-o activitate programată Windows numită Secure-Boot-Update. Activitatea este înregistrată în următoarea cale:
\Microsoft\Windows\PI\Secure-Boot-Update
Activitatea rulează ca Sistem local. În mod implicit, rulează la pornirea sistemului și la fiecare 12 ore după aceasta. De fiecare dată când rulează, verifică dacă acțiunile de actualizare Secure Boot sunt în așteptare și încearcă să le aplice în secvență.
Dacă această activitate este dezactivată sau lipsește, actualizările certificatului de bootare securizată nu pot fi aplicate. Activitatea Secure-Boot-Update trebuie să rămână activată pentru ca serviciul Secure Boot să funcționeze.
De ce este utilizată o activitate planificată
Actualizările certificatelor de boot securizat necesită coordonare între firmware-ul Windows și UEFI, inclusiv scrierea variabilelor UEFI care stochează chei secure boot și certificate. O activitate planificată permite Ca Windows să încerce aceste actualizări atunci când sistemul se află într-o stare în care variabilele firmware pot fi modificate.
Programul recurent de 12 ore oferă oportunități suplimentare de a reîncerca actualizările dacă o încercare anterioară a eșuat sau dacă dispozitivul a rămas pornit fără repornire. Această proiectare ajută la asigurarea progresului înainte fără a fi nevoie de intervenție manuală.
Mască de biți AvailableUpdates registry
Activitatea Secure-Boot-Update este determinată de valoarea de registry AvailableUpdates . Această valoare este o mască de biți pe 32 de biți situată la:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Fiecare bit din valoare reprezintă o anumită acțiune de actualizare Secure Boot. Procesul de actualizare începe atunci când AvailableUpdates este setat la o valoare non-zero, fie automat de către Windows, fie în mod explicit de către un administrator. De exemplu, o valoare, cum ar fi 0x5944 indică faptul că sunt în așteptare mai multe acțiuni de actualizare.
Atunci când rulează activitatea Secure-Boot-Update, aceasta interpretează biții setați ca lucru în așteptare și le procesează într-o ordine definită.
Actualizări secvențiale, înregistrare în jurnal și comportament reîncercări
Actualizările certificatului de bootare securizată se aplică într-o ordine fixă. Fiecare acțiune de actualizare este proiectată să fie sigură pentru a fi reîncercare și finalizată independent. Activitatea Secure-Boot-Update nu trece la pasul următor până când acțiunea curentă nu reușește, iar bitul corespunzător este golit din AvailableUpdates.
Fiecare operațiune utilizează interfețe UEFI standard pentru a actualiza variabilele Secure Boot, cum ar fi DB și KEK, sau pentru a instala managerul de boot Windows actualizat. Windows înregistrează rezultatul fiecărui pas din jurnalul de evenimente de sistem. Evenimentele de succes confirmă progresul înainte, în timp ce evenimentele de eroare indică motivul pentru care o acțiune nu a putut fi finalizată.
Dacă un pas de actualizare nu reușește, activitatea oprește procesarea, înregistrează eroarea și lasă setul de biți asociat. Operațiunea este reîncercată la următoarea rulare a activității. Acest comportament de rejudecare permite dispozitivelor să se recupereze automat din condiții temporare, cum ar fi lipsa suportului pentru firmware sau actualizări OEM întârziate.
Administratorii pot urmări progresul corelând starea de registry cu intrările din jurnalul de evenimente. Valori de registry, cum ar fi UEFICA2023Status, UEFICA2023Error și UEFICA2023ErrorEvent, împreună cu mască de biți AvailableUpdates , indică ce pas este activ, finalizat sau blocat.
Această combinație arată dacă dispozitivul progresează normal, dacă reîncearcă o operațiune sau este blocat.
Integrarea cu firmware-ul OEM
Actualizările certificatelor de bootare securizată depind de comportamentul corect și de suport în firmware-ul UEFI al dispozitivului. În timp ce Windows orchestra procesul de actualizare, firmware-ul este responsabil pentru impunerea politicii de bootare securizată și menținerea bazelor de date Secure Boot.
Producătorii OEM oferă două elemente critice care permit service-ul certificatului Secure Boot:
-
Chei exchange semnate cu cheie de platformă (KEKs) care autorizează instalarea de noi certificate secure boot.
-
Implementările de firmware care păstrează, adaugă și validează corect bazele de date secure Boot în timpul actualizărilor.
Dacă firmware-ul nu acceptă pe deplin aceste comportamente, actualizările Secure Boot pot să se blocheze, să reîncercați pe termen nelimitat sau să genereze erori de boot. În aceste cazuri, Windows nu poate finaliza actualizarea fără modificări ale firmware-ului.
Microsoft funcționează cu producătorii OEM pentru a identifica problemele de firmware și a face disponibile actualizările corectate. Atunci când depanarea indică o limitare de firmware sau un defect, poate fi necesar ca administratorii să instaleze cea mai recentă actualizare de firmware UEFI furnizată de producătorul dispozitivului înainte ca actualizările certificatului de bootare securizată să se poată finaliza cu succes.
Scenarii de eroare comune și rezolvări
Actualizările Secure Boot sunt aplicate de activitatea programată Secure-Boot-Update pe baza stării de registry AvailableUpdates .
În condiții normale, acești pași apar automat și înregistrează evenimente de succes pe măsură ce se termină fiecare etapă. În unele cazuri, comportamentul firmware-ului, configurația platformei sau cerințele preliminare de service pot împiedica progresul sau pot duce la un comportament de boot neașteptat.
Secțiunile de mai jos descriu cele mai comune scenarii de eroare, cum să le recunoașteți, de ce apar și următorii pași corespunzători pentru a restaura funcționarea normală. Scenariile sunt ordonate de la cele mai frecvente până la cazuri mai severe care afectează bootul.
Atunci când actualizările Secure Boot nu afișează niciun progres, acest lucru înseamnă de obicei că procesul de actualizare nu a început niciodată. Prin urmare, valorile de registry secure boot așteptate și jurnalele de evenimente lipsesc, deoarece mecanismul de actualizare nu a fost declanșat niciodată.
Ce s-a întâmplat
Procesul de actualizare Secure Boot nu a pornit, deci nu s-a aplicat niciun certificat secure Boot sau manager de boot actualizat la dispozitiv.
Cum se recunoaște
-
Nu există valori de registry pentru serviciul Secure Boot, cum ar fi UEFICA2023Status.
-
Evenimentele Secure Boot așteptate (de exemplu, 1043, 1044, 1045, 1799, 1801) lipsesc din jurnalul de evenimente de sistem.
-
Dispozitivul continuă să utilizeze certificate secure boot mai vechi și componente de boot.
De ce se întâmplă acest lucru
Acest scenariu apare de obicei atunci când una sau mai multe dintre condițiile următoare sunt adevărate:
-
Activitatea programată Secure-Boot-Update este dezactivată sau lipsește.
-
Bootul securizat este dezactivat în firmware-ul UEFI.
-
Dispozitivul nu îndeplinește cerințele preliminare de service Windows, cum ar fi rularea unei versiuni de Windows acceptate sau instalarea actualizărilor necesare.
Ce se poate face în continuare
-
Verificați dacă dispozitivul îndeplinește cerințele de service Windows și de eligibilitate pentru platformă.
-
Confirmați că opțiunea Bootare sigură este activată în firmware.
-
Asigurați-vă că activitatea programată SecureBootUpdate există și este activată.
Dacă activitatea planificată este dezactivată sau lipsește, urmați instrucțiunile din Activitate programată Boot securizat dezactivată sau ștearsă pentru a o restaura. După ce activitatea este restaurată, reporniți dispozitivul sau rulați activitatea manual pentru a iniția service Secure Boot.
În unele cazuri, actualizările legate de bootul securizat pot face ca un dispozitiv să intre în recuperarea BitLocker. Comportamentul poate fi tranzitoriu sau persistent, în funcție de cauza subiacentă.
Scenariul 1: Recuperarea Onetime BitLocker după actualizarea bootării securizate
Ce se întâmplă
Dispozitivul intră în recuperarea BitLocker la prima bootare după actualizarea Secure Boot, dar se încarcă în mod normal la repornirile ulterioare.
De ce se întâmplă acest lucru
În timpul primei încărcări după actualizare, firmware-ul nu raportează încă valorile Secure Boot actualizate atunci când Windows încearcă să resealizeze BitLocker. Acest lucru cauzează o nepotrivire temporară în valorile de boot măsurate și declanșează recuperarea. La următoarea pornire, firmware-ul raportează corect valorile actualizate, BitLocker se reînchide cu succes și problema nu se repetă.
Cum se recunoaște
-
Recuperarea BitLocker are loc o singură dată.
-
După ce introduceți cheia de recuperare, încărcările ulterioare nu solicită recuperarea.
-
Nu există ordine de bootare în curs sau implicare PXE.
Ce se poate face în continuare
-
Introduceți cheia de recuperare BitLocker pentru a relua Windows.
-
Căutați actualizări de firmware.
Scenariul 2: Recuperare BitLocker repetată din cauza primei configurații de boot PXE
Ce se întâmplă
Dispozitivul intră în recuperarea BitLocker la fiecare bootare.
De ce se întâmplă acest lucru
Dispozitivul este configurat să încerce mai întâi bootarea PXE (rețea). Încercarea de bootare PXE nu reușește, iar firmware-ul revine apoi la managerul de boot Windows de pe disc.
Acest lucru duce la măsurarea a două autorități de semnare diferite într-un singur ciclu de boot:
-
Calea de boot PXE este semnată de Microsoft UEFI CA 2011.
-
Managerul de boot Windows de pe disc este semnat de Windows UEFI CA 2023.
Deoarece BitLocker observă diferite lanțuri secure boot trust în timpul pornirii, nu poate stabili un set stabil de măsurători TPM față de care să se redimensioneze. Prin urmare, BitLocker intră în recuperare la fiecare bootare.
Cum se recunoaște
-
Recuperarea BitLocker este declanșată la fiecare repornire.
-
Introducerea cheii de recuperare permite ca Windows să pornească, dar solicitarea revine la următoarea bootare.
-
PXE sau bootarea de rețea este configurată înaintea discului local în ordinea de bootare a firmware-ului.
Ce se poate face în continuare
-
Configurați ordinea de bootare a firmware-ului, astfel încât managerul de boot Windows de pe disc să fie primul.
-
Dezactivați bootul PXE dacă nu este necesar.
-
Dacă este necesar PXE, asigurați-vă că infrastructura PXE utilizează un încărcător de boot Windows semnat 2023.
Ce s-a întâmplat
Acest lucru reflectă o modificare la nivel de firmware, nu o problemă cu Windows. Actualizarea Secure Boot s-a finalizat cu succes, dar după o repornire ulterioară, dispozitivul nu mai intră în Windows.
Cum se recunoaște
-
Dispozitivul nu reușește să pornească Windows și poate afișa un mesaj de firmware sau BIOS care indică o încălcare a bootării securizate.
-
Eroarea apare după ce setările secure boot sunt resetați la valorile implicite de firmware.
-
Dezactivarea Bootării securizate poate permite ca dispozitivul să booteze din nou.
De ce se întâmplă acest lucru
Resetarea Bootării securizate la valorile implicite de firmware șterge bazele de date Secure Boot stocate în firmware. Pe dispozitivele care au făcut deja tranziția la managerul de boot semnat Windows UEFI CA 2023, această resetare elimină certificatele necesare pentru a avea încredere în acel manager de boot.
Prin urmare, firmware-ul nu mai recunoaște managerul de boot Windows instalat ca fiind de încredere și blochează procesul de boot.
Acest scenariu nu este provocat de actualizarea Secure Boot propriu-zisă, ci de o acțiune de firmware ulterioară care elimină ancorele de încredere actualizate.
Ce se poate face în continuare
-
Utilizați utilitarul de recuperare Secure Boot pentru a restaura certificatul necesar, astfel încât dispozitivul să poată boota din nou.
-
După recuperare, asigurați-vă că dispozitivul are cel mai recent firmware disponibil instalat de la producătorul dispozitivului.
-
Evitați resetarea Bootării securizate la valorile implicite de firmware, cu excepția cazului în care firmware-ul OEM include valori implicite de bootare securizată actualizate care au încredere în certificatele 2023.
Utilitar de recuperare Secure Boot
Pentru a recupera sistemul:
-
Pe un al doilea PC Windows cu actualizarea Windows din iulie 2024 sau mai nouă instalată, copiați SecureBootRecovery.efi din C:\Windows\Boot\EFI\.
-
Plasați fișierul pe o unitate USB formatată FAT32 sub \EFI\BOOT\ și redenumiți-l în bootx64.efi.
-
Bootați dispozitivul afectat de pe unitatea USB și permiteți rularea utilitarului de recuperare. Utilitarul va adăuga Windows UEFI CA 2023 la DB.
După ce certificatul este restaurat și sistemul repornește, Windows ar trebui să pornească normal.
Important: Acest proces va reaplica doar unul dintre certificatele noi. După ce dispozitivul este recuperat, asigurați-vă că are cele mai recente certificate reaplicate și luați în considerare actualizarea BIOS/UEFI a sistemului la cea mai nouă versiune disponibilă. Acest lucru poate ajuta la prevenirea reapariției problemei cu resetarea bootării securizate, deoarece mulți producători OEM au lansat remedieri firmware pentru această problemă specifică.
Ce s-a întâmplat
După aplicarea actualizării și repornirii certificatului de bootare securizată, dispozitivul nu reușește să booteze și nu ajunge la Windows.
Cum se recunoaște
-
Dispozitivul nu reușește imediat după repornirea solicitată de actualizarea Secure Boot.
-
Poate fi afișată o eroare de firmware sau Secure Boot sau sistemul se poate opri înainte de încărcarea Windows.
-
Dezactivarea bootării securizate poate permite pornirea dispozitivului.
De ce se întâmplă acest lucru
Această problemă poate fi cauzată de un defect în implementarea firmware UEFI a dispozitivului.
Atunci când Windows aplică actualizările pentru certificatele secure boot, este de așteptat ca firmware-ul să adauge certificate noi la baza de date existentă de semnături permise pentru bootare securizată (DB). Unele implementări de firmware suprascrie incorect baza de date în loc să o adauge.
Când se întâmplă acest lucru,
-
Certificatele de încredere anterioare, inclusiv certificatul de bootloader Microsoft 2011, sunt eliminate.
-
Dacă sistemul utilizează în continuare un manager de boot semnat cu certificatul 2011 în acel moment, firmware-ul nu mai are încredere în el.
-
Firmware-ul respinge managerul de boot și blochează procesul de boot.
În unele cazuri, baza de date se poate deteriora, mai degrabă decât suprascrisă curat, conducând la același rezultat. Acest comportament a fost observat pe implementări de firmware specifice și nu este așteptat pe firmware-ul compatibil.
Ce se poate face în continuare
-
Introduceți meniurile de configurare firmware și încercați să resetați setările secure Boot.
-
Dacă dispozitivul se încarcă după resetare, verificați site-ul de asistență al producătorului dispozitivului pentru o actualizare de firmware care corectează gestionarea Secure Boot DB.
-
Dacă este disponibilă o actualizare de firmware, instalați-o înainte de a reactiva Bootarea securizată și de a reaplica actualizările certificatului de bootare securizată.
Dacă resetarea Secure Boot nu restaurează funcționalitatea de boot, recuperarea ulterioară necesită instrucțiuni specifice OEM.
Ce s-a întâmplat
Actualizarea certificatului de bootare securizată nu este finalizată și rămâne blocată în etapa de actualizare cheie Exchange Key (KEK).
Cum se recunoaște
-
Valoarea de registry AvailableUpdates rămâne setată cu bitul KEK (0x0004) și nu se golește.
-
UEFICA2023Status nu trece la o stare finalizată.
-
Jurnalul de evenimente de sistem înregistrează în mod repetat ID-ul de eveniment 1803, indicând faptul că actualizarea KEK nu a putut fi aplicată.
-
Dispozitivul continuă să reîncercați actualizarea fără a avansa.
De ce se întâmplă acest lucru
Actualizarea Secure Boot KEK necesită autorizare de la cheia de platformă a dispozitivului (PK), care este deținută de OEM.
Pentru ca actualizarea să reușească, producătorul dispozitivului trebuie să furnizeze Microsoft un KEK semnat PK pentru platforma respectivă. Acest KEK semnat OEM este inclus în actualizările Windows și permite Windows să actualizeze variabila KEK de firmware.
Dacă OEM nu a furnizat un KEK semnat PK pentru dispozitiv, Windows nu poate finaliza actualizarea KEK. În această stare:
-
Actualizările Secure Boot sunt blocate prin proiectare.
-
Windows nu poate ocoli autorizarea lipsă.
-
Dispozitivul poate rămâne permanent în imposibilitatea de a finaliza service-ul certificatului secure Boot.
Acest lucru se poate întâmpla pe dispozitive mai vechi sau care nu mai sunt în faza de asistență, atunci când producătorul OEM nu mai oferă actualizări de firmware sau cheie. Nu există nicio cale de recuperare manuală acceptată pentru această condiție.
Atunci când nu se aplică actualizările certificatului de bootare securizată, Windows înregistrează evenimente de diagnosticare care explică de ce s-a blocat progresul. Aceste evenimente sunt scrise atunci când actualizați baza de date cu semnături secure boot (DB) sau cheia Key Exchange (KEK) nu pot fi finalizate în siguranță din cauza condițiilor de firmware, de stare a platformei sau de configurare. Scenariile din această secțiune fac referire la aceste evenimente pentru a identifica modelele comune de erori și a determina remedierea corespunzătoare. Această secțiune este destinată să susțină diagnosticarea și interpretarea problemelor descrise anterior, pentru a nu introduce scenarii de eșec nou.
Pentru o listă completă a ID-urilor de eveniment, descrierilor și intrărilor de exemplu, consultați Evenimente de actualizare a variabilelor Secure Boot DB și DBX (KB5016061).
Eroare de actualizare KEK (actualizările DB au reușit, KEK nu)
Un dispozitiv poate actualiza cu succes certificatele din Secure Boot DB, dar nu reușește în timpul actualizării KEK. Când se întâmplă acest lucru, procesul de actualizare Secure Boot nu poate fi finalizat.
Simptome
-
Evenimentele certificatului DB indică progresul, dar etapa KEK nu este finalizată.
-
AvailableUpdates rămâne setat la 0x4004 și bitul 0x0004 nu este golit după ce rulează mai multe activități.
-
Este posibil să fie prezent evenimentul 1795 sau 1803 .
Interpretare
-
1795 indică de obicei eroarea de firmware în timp ce se încearcă actualizarea unei variabile Secure Boot.
-
1803 indică faptul că actualizarea KEK nu poate fi autorizată, deoarece o sarcină kek semnată OEM necesar nu este disponibilă pentru platformă.
Următorii pași
-
Pentru 1795, căutați actualizări de firmware OEM și validați suportul de firmware pentru actualizări variabile de bootare securizată.
-
Pentru 1803, confirmați dacă producătorul OEM a furnizat Microsoft kek semnat cu PK necesar pentru modelul dispozitivului.
Eroare de actualizare KEK pe mașini virtuale invitat găzduite pe Hyper-V
Pe mașinile virtuale Hyper-V, actualizările certificatelor Secure Boot necesită instalarea actualizărilor Windows din martie 2026 atât pe gazda Hyper-V, cât și pe sistemul de operare invitat.
Erorile de actualizare sunt raportate din interiorul invitatului, dar evenimentul indică unde este necesară remedierea:
-
Evenimentul 1795 (de exemplu, "Conținutul media este protejat la scriere") raportat în invitat indică faptul că gazdei Hyper-V îi lipsește actualizarea din martie 2026 și trebuie actualizată.
-
Evenimentul 1803 raportat în invitat indică faptul că mașinii virtuale invitat îi lipsește actualizarea din martie 2026 și trebuie actualizată.
Referință și interne
Această secțiune conține informații de referință complexe destinate pentru depanare și asistență. Acesta nu este destinat planificării implementării. Acesta se extinde pe mecanica secure boot service rezumate mai devreme și oferă materiale detaliate de referință pentru interpretarea registry stare și jurnale de evenimente.
Notă (implementări gestionate de IT): Atunci când este configurată prin Politică de grup sau Microsoft Intune, două setări similare nu ar trebui să fie confundate. Valoarea AvailableUpdatesPolicy reprezintă starea de politică configurată. Între timp, AvailableUpdates reflectă starea de lucru în curs de golire a biților. Ambele pot genera același rezultat, dar se comportă diferit, deoarece politica se aplică din nou în timp.
AvailableUpdates biți utilizați pentru service-ul certificatelor
Biții de mai jos sunt utilizați pentru acțiunile de certificat și manager de boot descrise în acest document. Coloana Ordine reflectă secvența în care activitatea Secure-Boot-Update procesează fiecare bit.
|
Comandă |
Setare bit |
Utilizare |
|---|---|---|
|
1 |
0x0040 |
Acest bit spune activității programate să adauge certificatul Windows UEFI CA 2023 la Secure Boot DB. Acest lucru permite ca Windows să acorde încredere managerilor de boot semnate de acest certificat. |
|
2 |
0x0800 |
Acest bit spune activității planificate să aplice Microsoft Option ROM UEFI CA 2023 la DB. Comportament condițional : Atunci când este setat semnalizatorul 0x4000, activitatea programată va verifica mai întâi baza de date pentru certificatul Microsoft Corporation UEFI CA 2011. Se va aplica certificatul Microsoft Option ROM UEFI CA 2023doar dacă certificatul 2011 este prezent. |
|
3 |
0x1000 |
Acest bit spune activității planificate să aplice Microsoft UEFI CA 2023 la baza de date. Comportament condiționat: Atunci când este setat semnalizatorul 0x4000 , activitatea programată va verifica mai întâi baza de date pentru certificatul Microsoft Corporation UEFI CA 2011 . Se va aplica certificatul Microsoft UEFI CA 2023doar dacă certificatul 2011 este prezent. |
|
Modificator (semnalizator de comportament) |
0x4000 |
Acest bit modifică comportamentul 0x0800 și 0x1000 biți, astfel încât Microsoft UEFI CA 2023 și Microsoft Option ROM UEFI CA 2023 să se aplice numai dacă baza de date conține deja Microsoft Corporation UEFI CA 2011. Pentru a vă asigura că profilul de securitate al dispozitivului rămâne același, acest bit aplică aceste certificate noi doar dacă dispozitivul are încredere în certificatul Microsoft Corporation UEFI CA 2011. Nu toate dispozitivele Windows au încredere în acest certificat. |
|
4 |
0x0004 |
Acest bit spune activității programate să caute o cheie Exchange semnată de cheia platformă a dispozitivului (PK). PK este gestionat de producătorul OEM. Producătorii OEM semnează Microsoft KEK cu PK-ul lor și îl livrează la Microsoft, unde este inclus în actualizările cumulative lunare. |
|
5 |
0x0100 |
Acest bit spune activității programate să aplice managerul de boot, semnat de Windows UEFI CA 2023, la partiția de boot. Aceasta va înlocui managerul de boot semnat Microsoft Windows Production PCA 2011. |
Note:
-
Bitul 0x4000 va rămâne setat după ce sunt procesați toți ceilalți biți.
-
Fiecare bit este procesat de activitatea programată Secure-Boot-Update, în ordinea de mai sus.
-
Dacă bitul 0x0004 nu poate fi procesat din cauza unui KEK semnat PK lipsă, activitatea programată va aplica în continuare actualizarea managerului de boot indicată de 0x0100 de biți.
Progresie așteptată (AvailableUpdates)
Atunci când o operațiune se termină cu succes, Windows golește bitul asociat din AvailableUpdates. Dacă o operațiune nu reușește, Windows înregistrează un eveniment și reîncearcă atunci când activitatea rulează din nou.
Tabelul de mai jos afișează progresia așteptată a valorilor AvailableUpdates pe măsură ce se termină fiecare acțiune de actualizare bootare securizată.
|
Pas |
Bit procesat |
Actualizări disponibile |
Descriere |
Eveniment de succes înregistrat |
Coduri de eveniment de eroare posibile |
|---|---|---|---|---|---|
|
Start |
0x5944 |
Starea inițială înainte să înceapă service-ul pentru certificatul Secure Boot. |
- |
- |
|
|
1 |
0x0040 |
0x5944 → 0x5904 |
Windows UEFI CA 2023 este adăugat la Secure Boot DB. |
1036 |
1032, 1795, 1796, 1802 |
|
2 |
0x0800 |
0x5904 → 0x5104 |
Adăugați Microsoft Option ROM UEFI CA 2023 la DB dacă dispozitivul a acordat anterior încredere Microsoft UEFI CA 2011. |
1044 |
1032, 1795, 1796, 1802 |
|
3 |
0x1000 |
0x5104 → 0x4104 |
Microsoft UEFI CA 2023 este adăugat la DB dacă dispozitivul a acordat anterior încredere Microsoft UEFI CA 2011. |
1045 |
1032, 1795, 1796, 1802 |
|
4 |
0x0004 |
0x4104 → 0x4100 |
Se aplică noul Microsoft KEK 2K CA 2023 semnat de cheia platformei OEM. |
1043 |
1032, 1795, 1796, 1802, 1803 |
|
5 |
0x0100 |
0x4100 → 0x4000 |
Managerul de boot semnat de Windows UEFI CA 2023 este instalat. |
1799 |
1797 |
Note
-
După finalizarea cu succes a operațiunii asociate cu un pic, acel bit este eliminat din AvailableUpdates.
-
Dacă una dintre aceste operațiuni nu reușește, se înregistrează un eveniment și operațiunea este reîncercată data viitoare când rulează activitatea planificată.
-
Bitul 0x4000 este modificator și nu este șters. O valoare finală AvailableUpdates a 0x4000 indică finalizarea cu succes a tuturor acțiunilor de actualizare aplicabile.
-
Evenimentele 1032, 1795, 1796, 1802 indică de obicei limitările de firmware sau de platformă.
-
Evenimentul 1803 indică lipsa kek semnat OEM PK.
Proceduri de remediere
Această secțiune oferă proceduri pas cu pas pentru remedierea problemelor specifice de bootare securizată. Fiecare procedură este definită într-o condiție bine definită și este destinată să fie urmată numai după ce diagnosticul inițial confirmă faptul că problema se aplică. Utilizați aceste proceduri pentru a restaura comportamentul de bootare securizat așteptat și a permite ca actualizările de certificate să continue în siguranță. Nu aplicați aceste proceduri pe scară largă sau preemptivă.
Activarea bootării securizate în firmware
Dacă opțiunea Bootare sigură este dezactivată în firmware-ul unui dispozitiv, consultați Windows 11 și Bootarea sigură pentru detalii despre activarea Bootării securizate.
Activitate programată Bootare securizată dezactivată sau ștearsă
Activitatea programată Secure-Boot-Update este necesară pentru ca Windows să aplice actualizări ale certificatului de bootare securizată. Dacă activitatea este dezactivată sau lipsește, serviciul secure Boot certificate nu va progresa.
Detalii activitate
|
Nume activitate |
Actualizare secure-boot |
|
Cale activitate |
\Microsoft\Windows\PI\ |
|
Cale completă |
\Microsoft\Windows\PI\Secure-Boot-Update |
|
Rulează ca |
SYSTEM (Sistem local) |
|
Declanșatoare, |
La pornire și la fiecare 12 ore |
|
Stare necesară |
Activat |
Cum se verifică starea activității
Rulați dintr-o solicitare PowerShell cu drepturi sporite: schtasks.exe /Query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V
Căutați câmpul Stare:
|
Stare |
Sensul |
|---|---|
|
Gata |
Activitatea există și este activată. |
|
Dezactivat |
Activitatea există, dar trebuie să fie activată. |
|
Eroare/ Negăsit |
Activitatea lipsește și trebuie recreată. |
Cum să activați sau să creați din nou activitatea
În cazul în care câmpul de stare pentru Secure-Boot-Update este Dezactivat, Eroare sau Negăsit, utilizați scriptul eșantion pentru a activa activitatea: Eșantion Enable-SecureBootUpdateTask.ps1
Notă: Acesta este un script eșantion și nu este acceptat de Microsoft. Administratorii ar trebui să o revizuiască și să o adapteze la mediul lor.
Exemplu:
.\Enable-SecureBootUpdateTask.ps1 - Silențios
Rulați instrucțiunile
-
Dacă vedeți Acces refuzat, rulați din nou PowerShell ca administrator.
-
Dacă scriptul nu va rula din cauza politicii de executare, utilizați o ocolire a domeniului de proces:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Aveți nevoie de ajutor suplimentar?
Doriți mai multe opțiuni?
Explorați avantajele abonamentului, navigați prin cursurile de instruire, aflați cum să vă securizați dispozitivul și multe altele.
Comunitățile vă ajută să adresați întrebări și să răspundeți la întrebări, să oferiți feedback și să primiți feedback de la experți cu cunoștințe bogate.
