Ghid de depanare a pornirii sigure

În acest articol

• Prezentare generală
• Cum funcționează service-ul unui certificat Secure Boot
• De unde să începeți când depanați
• Activitate planificată de pornire sigură
• De ce se utilizează o activitate planificată
• Masca de biți de registry AvailableUpdates
• Integrarea cu firmware-ul OEM
• Scenarii de eroare comune și soluții
• Referințe și contexte interne
• Biți de actualizări disponibile utilizați pentru întreținerea certificatelor
• Progresul așteptat (AvailableUpdates)
• Proceduri de remediere
• Activarea bootării sigure în firmware
• Pornire sigură, activitate planificată, dezactivată sau ștearsă

Prezentare generală

Această pagină ghidează administratorii și inginerii din asistență în diagnosticarea și rezolvarea problemelor legate de pornirea securizată pe dispozitivele Windows. Printre subiecte se numără erorile de actualizare a certificatului de pornire sigură, stările incorecte ale pornirii sigure, solicitările neașteptate de recuperare BitLocker și erorile de boot în urma modificărilor de configurație a pornirii sigure.

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 ale platformei necesită o actualizare OEM. Acest conținut este destinat diagnosticării problemelor de pe dispozitivele existente. Acesta nu este menit pentru planificarea de noi implementări. Acest document va fi actualizat pe măsură ce sunt identificate noi scenarii de depanare și instrucțiuni.

înapoi sus

Cum funcționează service-ul certificatului Secure Boot

Asistența certificatului de pornire sigură în Windows este un proces coordonat între sistemul de operare și firmware-ul UEFI al unui dispozitiv. Scopul este de a actualiza ancorele critice de încredere, păstrând în același timp capacitatea de a porni în fiecare etapă.

Procesul este condus de o activitate programată Windows, de o secvență de acțiuni de actualizare bazată pe registry și de comportament încorporat în înregistrare în jurnal și reîncercări. Împreună, aceste componente asigură că certificatele de pornire sigură și managerul de boot Windows sunt actualizate într-o manieră controlată, ordonată și numai după ce pașii necesari preliminari reușesc.

înapoi sus

De unde să începeți când depanați

Atunci când un dispozitiv nu pare să facă progresul așteptat la aplicarea actualizărilor certificatului de pornire sigură, începeți prin a identifica categoria problemei. Majoritatea problemelor se încadrează într-unul dintre cele patru domenii: starea de service Windows, mecanismul de actualizare Bootare sigură, comportamentul firmware-ului sau o limitare a platformei sau 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 a determina acțiunile următoare fără o investigație mai aprofundată.

1. Confirmați service-ul Windows și eligibilitatea platformei

   1. Verificați dacă dispozitivul îndeplinește cerințele de bază pentru a primi actualizări ale certificatului de pornire sigură:
   2. Dispozitivul rulează o versiune acceptată de Windows.
   3. Sunt instalate cele mai recente actualizări de securitate Windows necesare.
   4. Bootarea sigură este activată în firmware-ul UEFI.
   5. Dacă oricare dintre aceste condiții nu este îndeplinită, rezolvați-le înainte de a continua depanarea ulterioară.

2. Verificarea stării activității Secure-Boot-Update

   1. Confirmați că mecanismul Windows responsabil pentru aplicarea actualizărilor certificatului de pornire sigură este prezent și funcționează:
   2. Activitatea planificată Secure-Boot-Update există.
   3. Activitatea este activată și rulează ca Sistem local.
   4. Activitatea a rulat cel puțin o dată de când a fost instalată cea mai recentă actualizare de securitate Windows.
   5. Dacă activitatea este dezactivată, ștearsă sau nu rulează, actualizările certificatelor de pornire sigură nu se pot aplica. Depanarea trebuie să se concentreze pe restaurarea activității înainte de a investiga alte cauze.

3. Verificați setările de registry pentru progresul așteptat
   Revizuiți starea de service Secure Boot a dispozitivului în registry:

   1. Examinați UEFICA2023Status, UEFICA2023Error și UEFICA2023ErrorEvent.
   2. Examinați AvailableUpdates și comparați-le cu progresia așteptată (consultați Reference and Internals).

   Împreună, aceste valori indică dacă deservirea se desfășoară normal, dacă se reîncearcă o operațiune sau dacă se blochează la un anumit pas.

4. Corelați starea registry cu evenimentele de pornire sigură
   Revizuiți evenimentele legate de pornirea sigură din jurnalul de evenimente de sistem și corelați-le cu starea de registry. Datele de eveniment confirmă, de obicei, dacă dispozitivul face progrese, reîncearcă din cauza unei condiții temporare sau 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 dacă necesită o măsură corectivă.

înapoi sus

Activitate planificată de pornire sigură

Serviciul certificatului de pornire sigură este implementat printr-o activitate programată Windows, numită Secure-Boot-Update. Activitatea este înregistrată la următoarea cale:

Activitatea rulează ca Sistem local. În mod implicit, acesta rulează la pornirea sistemului și după aceea o dată la 12 ore. De fiecare dată când rulează, verifică dacă acțiunile de actualizare a pornirii sigure sunt în așteptare și încearcă să le aplice în ordine.

Dacă această activitate este dezactivată sau lipsește, actualizările certificatelor de pornire sigură nu se pot aplica. Activitatea Pornire sigură și actualizare trebuie să rămână activată pentru ca serviciul Pornire sigură să funcționeze.

înapoi sus

De ce se utilizează o activitate planificată

Actualizările certificatelor Secure Boot necesită coordonarea între Windows și firmware-ul UEFI, inclusiv scrierea variabilelor UEFI care stochează cheile și certificatele Secure Boot. O activitate planificată permite 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 încerca din nou actualizările dacă o încercare anterioară nu a reușit sau dacă dispozitivul a rămas pornit fără a reporni. Această proiectare asigură progresul înainte fără a necesita intervenție manuală.

înapoi sus

Masca de biți de registry AvailableUpdates

Activitatea de pornire sigură și actualizare este determinată de valoarea de registry AvailableUpdates . Această valoare este o mască de biți pe 32 de biți aflată la:

Fiecare bit din valoare reprezintă o acțiune specifică de actualizare a pornirii sigure. Procesul de actualizare începe atunci când AvailableUpdates este setat la o valoare diferită de zero, fie automat de Windows, fie în mod explicit de un administrator. De exemplu, o valoare precum 0x5944 indică faptul că există mai multe acțiuni de actualizare în așteptare.

Atunci când activitatea de pornire sigură și actualizare rulează, aceasta interpretează biții setați ca lucru în așteptare și îi procesează într-o ordine definită.

înapoi sus

Actualizări secvențiale, înregistrare în jurnal și comportament de reîncercare

Actualizările certificatelor de pornire sigură se aplică într-o ordine fixă. Fiecare acțiune de actualizare este proiectată să fie sigură și poate fi reîncercată și se finalizează în mod 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 de pornire sigură, cum ar fi baza de date ș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 reușită confirmă progresul înainte, în timp ce evenimentele de eroare indică de ce o acțiune nu a putut fi finalizată.

Dacă un pas de actualizare nu reușește, activitatea nu mai este procesată, înregistrează eroarea și lasă bitul asociat setat. Operațiunea este reîncercată următoarea dată când se execută activitatea. Acest comportament de reîncercare permite dispozitivelor să se recupereze automat după condiții temporare, cum ar fi absența asistenței firmware sau actualizările OEM întârziate.

Administratorii pot urmări progresul corelând starea registry cu intrările din jurnalul de evenimente. Valorile de registry precum UEFICA2023Status, UEFICA2023Error și UEFICA2023ErrorEvent, împreună cu masca de biți AvailableUpdates , indică ce pas este activ, finalizat sau blocat.

Această combinație arată dacă dispozitivul progresează normal, reîncearcă o operațiune sau se blochează.

înapoi sus

Integrarea cu firmware-ul OEM

Actualizările certificatelor de pornire sigură depind de comportamentul corect și de asistența din firmware-ul UEFI al unui dispozitiv. În timp ce Windows orchestrează procesul de actualizare, firmware-ul este responsabil pentru impunerea politicii de pornire sigură și întreținerea bazelor de date de pornire sigură.

Producătorii OEM furnizează două elemente critice care permit service-ul certificatului de pornire sigură:

• Chei Exchange cu cheie semnată cu chei de platformă (KEK) care autorizează instalarea de noi certificate Secure Boot.
• Implementări de firmware care păstrează, adaugă și validează corect bazele de date Pornire sigură în timpul actualizărilor.

Dacă firmware-ul nu acceptă pe deplin aceste comportamente, actualizările pornirii sigure se pot bloca, pot reîncerca pe termen nelimitat sau pot cauza erori de bootare. În aceste cazuri, Windows nu poate finaliza actualizarea fără modificări ale firmware-ului.

Microsoft lucrează cu producătorii OEM pentru a identifica problemele de firmware și a face disponibile actualizările corectate. Atunci când depanarea indică o limitare sau un defect de firmware, poate fi necesar ca administratorii să instaleze cea mai recentă actualizare de firmware UEFI furnizată de producătorul dispozitivului înainte ca actualizările certificatelor de pornire sigură să se poată finaliza cu succes.

înapoi sus

Scenarii de eroare comune și soluții

Actualizările pornirii sigure sunt aplicate de activitatea planificată Secure-Boot-Update pe baza stării de registry AvailableUpdates .

În condiții normale, acești pași au loc automat și înregistrează evenimente de succes pe măsură ce se termină fiecare etapă. În unele cazuri, comportamentul firmware-ului, configurarea platformei sau cerințele preliminare de service pot împiedica progresul sau pot duce la un comportament de încărcare neașteptat.

Secțiunile de mai jos descriu cele mai comune scenarii de eroare, cum să le recunoașteți, de ce apar și pașii următori corespunzători pentru a restabili funcționarea normală. Scenariile sunt ordonate de la cele mai întâlnite la cele mai severe cazuri cu impact asupra pornirii.

Actualizările pornirii sigure nu se aplică (niciun progres)

Atunci când actualizările Bootare sigură nu arată niciun progres, aceasta înseamnă de obicei că procesul de actualizare nu a început niciodată. Prin urmare, valorile de registry Secure Boot și jurnalele de evenimente așteptate lipsesc, deoarece mecanismul de actualizare nu a fost declanșat niciodată.

Ce s-a întâmplat

Procesul de actualizare Secure Boot nu a început, astfel că nu au fost aplicate pe dispozitiv niciun certificat Secure Boot sau manager de boot actualizat.

Cum să-l recunoașteți

• Nu sunt prezente valori de registry pentru întreținerea pornirii sigure, cum ar fi UEFICA2023Status.
• Evenimentele de pornire sigură așteptate (de exemplu, 1043, 1044, 1045, 1799, 1801) lipsesc din jurnalul de evenimente de sistem.
• Dispozitivul continuă să utilizeze certificate Secure Boot și componente de boot mai vechi.

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 planificată pentru pornirea sigură este dezactivată sau lipsește.
• Bootarea sigură este dezactivată în firmware-ul UEFI.
• Dispozitivul nu îndeplinește cerințele preliminare de întreținere Windows, cum ar fi rularea unei versiuni acceptate de Windows sau instalarea actualizărilor necesare.

Ce să faceți în continuare

• Verificați dacă dispozitivul îndeplinește cerințele de eligibilitate și de service Windows pentru platformă.
• Confirmați că opțiunea Bootare sigură este activată în firmware.
• Asigurați-vă că există și că este activată activitatea planificată SecureBootUpdate .

Dacă activitatea programată este dezactivată sau lipsește, urmați instrucțiunile din Pornire sigură, activitate planificată, dezactivată sau ștearsă pentru a o restaura. După ce se restaurează activitatea, reporniți dispozitivul sau rulați-o manual pentru a iniția serviciul de pornire sigură.

Dispozitivul pornește în recuperarea BitLocker după actualizarea pornirii sigure

În unele cazuri, actualizările legate de bootarea sigură pot face un dispozitiv să intre în recuperarea BitLocker. Comportamentul poate fi temporar sau persistent, în funcție de cauza subiacentă.

Scenariul 1: Recuperare BitLocker unică după actualizarea pornirii sigure

Ce se întâmplă

Dispozitivul intră în recuperarea BitLocker la prima pornire după actualizarea pornirii sigure, dar pornește normal la repornirile ulterioare.

De ce se întâmplă acest lucru

În timpul primei porniri după actualizare, firmware-ul nu raportează încă valorile actualizate ale pornirii sigure atunci când Windows încearcă să sigileze din nou BitLocker. Acest lucru cauzează o nepotrivire temporară a valorilor de bootare măsurate și declanșează recuperarea. La următoarea pornire, firmware-ul raportează corect valorile actualizate, BitLocker se resigilează cu succes, iar problema nu se repetă.

Cum să-l recunoașteți

• Recuperarea BitLocker are loc o singură dată.
• După ce introduceți cheia de recuperare, încărcările ulterioare nu solicită recuperarea.
• Nu este prezentă nicio comandă de bootare în curs de desfășurare sau implicarea PXE.

Ce să faceți în continuare

• Introduceți cheia de recuperare BitLocker pentru a relua Windows.
• Căutați actualizări de firmware.

Scenariul 2: Recuperare BitLocker repetată datorită configurării primei porniri PXE

Ce se întâmplă

Dispozitivul intră în recuperarea BitLocker la fiecare pornire.

De ce se întâmplă acest lucru

Dispozitivul este configurat să încerce mai întâi încărcarea PXE (rețea). Încercarea de boot PXE nu reușește, iar firmware-ul revine apoi la managerul de boot Windows de pe disc.

Acest lucru determină măsurarea a două autorități de semnare diferite pe parcursul unui singur ciclu de pornire:

• 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 de încredere Secure Boot în timpul pornirii, nu poate stabili un set stabil de măsurători TPM împotriva cărora să se resigileze. Prin urmare, BitLocker intră în recuperare la fiecare pornire.

Cum să-l recunoașteți

• Recuperarea BitLocker este declanșată la fiecare repornire.
• Introducerea cheii de recuperare permite pornirea Windows, dar solicitarea revine la următoarea pornire.
• PXE sau bootarea în rețea este configurată înaintea discului local în ordinea de bootare firmware.

Ce să faceți î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 bootarea 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.

Dispozitivul nu reușește să pornească după resetarea Secure Boot

Ce s-a întâmplat

Aceasta reflectă o modificare la nivel de firmware, mai degrabă decât o problemă Windows. Actualizarea pornirii sigure s-a finalizat cu succes, dar, după o repornire ulterioară, dispozitivul nu mai pornește în Windows.

Cum să-l recunoașteți

• Dispozitivul nu reușește să pornească Windows și poate afișa un mesaj de firmware sau BIOS indicând o încălcare a bootării securizate.
• Eroarea apare după ce setările Secure Boot sunt resetate la valorile implicite de firmware.
• Dezactivarea bootării sigure poate permite dispozitivului să booteze din nou.

De ce se întâmplă acest lucru

Resetarea Bootării sigure la valorile implicite de firmware șterge bazele de date Pornire sigură stocate în firmware. Pe dispozitivele care au făcut deja tranziția la managerul de boot semnat de Windows UEFI CA 2023, această resetare elimină certificatele necesare pentru a acorda încredere managerului de încărcare respectiv.

Prin urmare, firmware-ul nu mai recunoaște managerul de boot Windows instalat ca fiind de încredere și blochează procesul de pornire.

Acest scenariu nu este cauzat de actualizarea pornirii sigure propriu-zise, ci de o acțiune de firmware ulterioară care elimină ancorele de încredere actualizate.

Ce să faceți î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 instalat cel mai recent firmware disponibil de la producătorul dispozitivului.
• Evitați resetarea Bootării sigure la valorile implicite de firmware, cu excepția cazului în care firmware-ul OEM include valori implicite Secure Boot actualizate care acordă încredere certificatelor 2023.

Utilitarul de recuperare Secure Boot

Pentru a recupera sistemul:

1. Pe un al doilea PC Windows cu actualizarea Windows din iulie 2024 sau mai recentă instalată, copiați SecureBootRecovery.efi din C:\Windows\Boot\EFI\.
2. Plasați fișierul pe o unitate USB formatată cu FAT32, sub \EFI\BOOT\ și redenumiți-l în bootx64.efi.
3. Porniți dispozitivul afectat de pe unitatea USB și permiteți ca utilitarul de recuperare să ruleze. Utilitarul va adăuga Windows UEFI CA 2023 la baza de date.

După ce certificatul este restaurat și sistemul repornește, Windows ar trebui să pornească normal.

Important: Acest proces va aplica din nou 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 de resetare a pornirii securizate, deoarece mulți producători OEM au lansat remedieri de firmware pentru această problemă specifică.

Bootarea dispozitivului nu reușește după actualizarea pornirii sigure din cauza suprascrierii firmware-ului bazei de date

Ce s-a întâmplat

După aplicarea actualizării certificatului Secure Boot și repornire, dispozitivul nu reușește să booteze și nu ajunge la Windows.

Cum să-l recunoașteți

• Dispozitivul nu reușește imediat după repornirea solicitată de actualizarea Secure Boot.
• Se poate afișa o eroare de firmware sau de pornire sigură sau sistemul se poate opri înainte de încărcarea Windows.
• Dezactivarea bootării sigure poate permite bootarea dispozitivului.

De ce se întâmplă acest lucru

Această problemă poate fi cauzată de un defect în implementarea firmware-ului UEFI al dispozitivului.

Atunci când Windows aplică actualizări ale certificatului de pornire sigură, firmware-ul este de așteptat să adauge certificate noi la baza de date cu semnături permise Pornire sigură (DB) existente. Unele implementări de firmware suprascriu incorect baza de date în loc să o adauge.

Atunci când se întâmplă acest lucru,

• Certificatele de încredere anterioare, inclusiv certificatul de bootloader Microsoft 2011, sunt eliminate.
• Dacă sistemul utilizează încă un manager de încărcare semnat cu certificatul 2011 în acel moment, firmware-ul nu îi mai acordă încredere.
• Firmware-ul respinge managerul de încărcare și blochează procesul de pornire.

În unele cazuri, baza de date poate deveni mai degrabă coruptă decât suprascrisă curat, ducând la același rezultat. Acest comportament a fost observat pe implementările de firmware specifice și nu este de așteptat pentru firmware-ul conform.

Ce să faceți în continuare

• Intrați în meniurile de configurare a firmware-ului și încercați să resetați setările pornirii sigure.
• Dacă dispozitivul pornește după resetare, consultați site-ul de asistență al producătorului dispozitivului pentru o actualizare de firmware care corectează manipularea Secure Boot DB.
• Dacă este disponibilă o actualizare de firmware, instalați-o înainte de a reactiva Pornirea sigură și de a aplica din nou actualizările certificatului de pornire sigură.

Dacă resetarea Bootării sigure nu restaurează funcționalitatea de pornire, recuperarea ulterioară necesită probabil instrucțiuni specifice producătorului OEM.

Actualizarea Secure Boot a fost blocată din cauza lipsei KEK semnat de OEM

Ce s-a întâmplat

Actualizarea certificatului Secure Boot nu este finalizată și rămâne blocată în etapa de actualizare a cheii Key Exchange (KEK).

Cum să-l recunoașteți

• Valoarea de registry AvailableUpdates rămâne setată cu bitul KEK (0x0004) și nu se golește.
• UEFICA2023Status nu progresează la o stare terminată.
• 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ă încerce din nou actualizarea fără să facă progrese.

De ce se întâmplă acest lucru

Actualizarea KEK Secure Boot necesită autorizare de la cheia de platformă (PK) a dispozitivului, care este deținută de producătorul 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 firmware.

Dacă producătorul OEM nu a furnizat un KEK semnat PK pentru dispozitiv, Windows nu poate finaliza actualizarea KEK. În această stare:

• Actualizările pornirii sigure sunt blocate prin proiectare.
• Windows nu poate ocoli autorizarea lipsă.
• Dispozitivul poate rămâne permanent imposibilă de finalizarea serviciului certificatului Secure Boot.

Acest lucru se poate întâmpla pe dispozitive mai vechi sau care nu beneficiază de asistență, unde producătorul OEM nu mai oferă firmware sau actualizări de cheie. Nu există nicio cale de recuperare manuală acceptată pentru această stare.

înapoi sus

Evenimente de actualizare a certificatului Secure Boot și indicatori de eroare

Atunci când actualizările certificatului Secure Boot nu reușesc să se aplice, Windows înregistrează evenimentele de diagnosticare care explică de ce a fost blocat progresul. Aceste evenimente sunt scrise atunci când actualizarea bazei de date de semnături Secure Boot (DB) sau a cheii de schimb de chei (KEK) nu poate fi finalizată în siguranță din cauza firmware-ului, a stării platformei sau a condițiilor 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ă sprijine diagnosticarea și interpretarea problemelor descrise mai sus, nu să introducă noi scenarii de eroare.

Pentru o listă completă a ID-urilor de evenimente, descrieri și intrări cu exemple, consultați Evenimente de actualizare variabilă DB și DBX (KB5016061) Pornire sigură.

Eroare de actualizare KEK (actualizările bazei de date reușesc, KEK nu)

Un dispozitiv poate actualiza cu succes certificatele din baza de date Secure Boot, dar nu reușește în timpul actualizării KEK. Atunci când se întâmplă acest lucru, procesul de actualizare Pornire sigură nu poate fi finalizat.

Simptome

• Evenimentele de certificat DB indică un progres, dar etapa KEK nu este finalizată.
• AvailableUpdates rămâne setat la 0x4004, iar 0x0004 bit nu este golit după mai multe rulări de activități.
• Evenimentul 1795 sau 1803 ar putea fi prezent.

Interpretare

• 1795 indică de obicei o eroare de firmware în timp ce încercați să actualizați o variabilă de pornire sigură.
• 1803 indică faptul că actualizarea KEK nu poate fi autorizată, deoarece o sarcină KEK necesară semnată de PK OEM nu este disponibilă pentru platformă.

Următorii pași

• Pentru 1795, verificați dacă există actualizări de firmware OEM și validați suportul firmware pentru actualizările variabilelor Pornire sigură.
• Pentru 1803, confirmați dacă producătorul OEM a furnizat Microsoft KEK semnat PK necesar pentru modelul dispozitivului.

Eroare de actualizare KEK pe mașini virtuale invitate găzduite pe Hyper-V

Pe mașinile virtuale Hyper-V, actualizările certificatelor de pornire sigură 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 cadrul invitatului, dar evenimentul indică unde este necesară remedierea:

• Evenimentul 1795 (de exemplu, "Elementele media sunt protejate la scriere") raportate î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 invitate în sine lipsește actualizarea din martie 2026 și trebuie actualizată.

înapoi sus

Referințe și contexte interne

Această secțiune conține informații de referință complexe destinate depanării și asistenței. Acesta nu este destinat planificării implementării. Aceasta extinde mecanismele de service ale pornirii sigure sintetizate mai sus și oferă materiale de referință detaliate pentru interpretarea jurnalelor de evenimente și a stării registry.

Notă (implementări gestionate de IT): atunci când sunt configurate prin Politica de grup sau Microsoft Intune, nu trebuie confundate două setări similare. Valoarea AvailableUpdatesPolicy reprezintă starea de politică configurată. Între timp, AvailableUpdates reflectă starea de lucru în curs, pentru curățarea biților. Ambele pot conduce la același rezultat, dar se comportă diferit, deoarece politica se aplică din nou în timp.

înapoi sus

Biți de actualizări disponibile utilizați pentru întreținerea certificatelor

Biturile de mai jos sunt utilizate pentru acțiunile de certificate și manager de boot descrise în acest document. Coloana Ordine reflectă secvența în care activitatea Pornire-Pornire-Actualizare Securizată procesează fiecare bit.

Comandă	Setare de biți	Utilizare
1	0x0040	Acest bit îi spune activității programate să adauge certificatul Windows UEFI CA 2023 la baza de date Secure Boot. Acest lucru permite ca Windows să acorde încredere managerilor de boot semnați cu acest certificat.
2	0x0800	Acest bit îi spune activității programate să aplice Microsoft Option ROM UEFI CA 2023 la baza de date. Comportament condiționat: Când este setată semnalizarea 0x4000 , activitatea programată va verifica mai întâi baza de date pentru certificatul Microsoft Corporation UEFI CA 2011 . Va aplica certificatul Microsoft Option ROM UEFI CA 2023doar dacă este prezent certificatul 2011.
3	0x1000	Acest bit spune activității programate să aplice Microsoft UEFI CA 2023 la baza de date. Comportament condiționat: Când este setată semnalizarea 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ă este prezent certificatul 2011.
Modificator (semnalizare 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 în cazul în care 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 acordă încredere certificatului Microsoft Corporation UEFI CA 2011. Nu toate dispozitivele Windows acordă încredere acestui certificat.
4	0x0004	Acest bit spune activității programate să caute o cheie de schimb de chei semnată de cheia de platformă a dispozitivului (PK). PK este gestionat de producătorul OEM. Producătorii OEM semnează KEK Microsoft cu PK și îl livrează la Microsoft, unde este inclus în actualizările cumulative lunare.
5	0x0100	Acest bit spune activității planificate să aplice managerul de boot, semnat de Windows UEFI CA 2023, la partiția de boot. Acesta va înlocui managerul de boot semnat Microsoft Windows Production PCA 2011 .

Note:

• Bitul de 0x4000 va rămâne setat după ce sunt procesați toți ceilalți biți.
• Fiecare bit este procesat de activitatea planificată Secure-Boot-Update în ordinea arătată mai sus.
• Dacă 0x0004 bit nu poate fi procesat din cauza unui KEK lipsă semnat PK, activitatea programată va aplica în continuare actualizarea managerului de boot indicată de 0x0100 biți.

înapoi sus

Progresul 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ă când activitatea rulează din nou.

Tabelul de mai jos afișează progresia așteptată a valorilor AvailableUpdates pe măsură ce se finalizează fiecare acțiune de actualizare a pornirii sigure.

Pasul	Bit procesat	Actualizări disponibile	Descriere	Eveniment de succes înregistrat	Coduri de eveniment de eroare posibile
Start		0x5944	Starea inițială înainte de începerea serviciului pentru certificatul Secure Boot.	-	-
1	0x0040	0x5944 → 0x5904	Windows UEFI CA 2023 este adăugat la baza de date Pornire sigură.	1036	1032, 1795, 1796, 1802
2	0x0800	0x5904 → 0x5104	Adăugați Microsoft Option ROM UEFI CA 2023 la baza de date 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 baza de date 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ă ce operațiunea asociată cu un bit se finalizează cu succes, acel bit este golit din AvailableUpdates.
• Dacă una dintre aceste operațiuni nu reușește, un eveniment este înregistrat în jurnal, iar operațiunea este reîncercată următoarea dată când rulează activitatea programată.
• Bitul 0x4000 este un modificator și nu este golit. O valoare finală AvailableUpdates de 0x4000 indică finalizarea cu succes a tuturor acțiunilor de actualizare aplicabile.
• Evenimentele 1032, 1795, 1796, 1802 indică de obicei limitări legate de firmware sau platformă.
• Evenimentul 1803 indică faptul că lipsește KEK semnat PK OEM.

înapoi sus

Proceduri de remediere

Această secțiune oferă proceduri pas cu pas pentru a remedia problemele specifice cu bootarea sigură. Fiecare procedură este definită pentru o condiție bine definită și este destinată să fie urmată numai după ce diagnosticul inițial confirmă că problema se aplică. Utilizați aceste proceduri pentru a restaura comportamentul așteptat de pornire sigură și pentru a permite ca actualizările certificatelor să continue în siguranță. Nu aplicați aceste proceduri pe scară largă sau preventivă.

înapoi sus

Activarea bootării sigure în firmware

Dacă Bootarea sigură este dezactivată în firmware-ul unui dispozitiv, consultați Windows 11 și bootarea sigură pentru detalii despre activarea bootării sigure.

înapoi sus

Pornire sigură, activitate planificată, dezactivată sau ștearsă

Activitatea planificată Secure-Boot-Update este necesară pentru ca Windows să aplice actualizări ale certificatului Secure Boot. Dacă activitatea este dezactivată sau lipsește, service-ul certificatului Secure Boot nu va progresa.

Detalii despre activitate

Nume activitate	Secure-Boot-Update
Cale de activitate	\Microsoft\Windows\PI\
Cale completă	\Microsoft\Windows\PI\Secure-Boot-Update
Rulează ca	SYSTEM (Sistem local)
Triggere	La pornire și la fiecare 12 ore
Stare necesară	Activat

Cum să verificați 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	Semnificație
Pregătit	Activitatea există și este activată.
Disabled	Activitatea există, dar trebuie să fie activată.
Eroare/Negăsit	Activitatea lipsește și trebuie creată din nou.

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: Exemplu 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:

Instrucțiuni de rulare

• Dacă vedeți Acces refuzat, rulați din nou PowerShell ca Administrator.
• Dacă scriptul nu va rula din cauza politicii de execuție, utilizați o ocolire a domeniului de proces:

înapoi sus