Risoluzione dei problemi
Si applica a
Data di pubblicazione originale: 19 marzo 2026
ID KB: 5085046
Contenuto dell'articolo
Panoramica
Questa pagina guida gli amministratori e il supporto tecnico per la diagnosi e la risoluzione dei problemi relativi all'avvio protetto nei dispositivi Windows. Gli argomenti includono errori di aggiornamento del certificato di avvio protetto, stati di avvio protetto non corretti, richieste di ripristino impreviste di BitLocker e errori di avvio a seguito di modifiche alla configurazione di avvio protetto.
Le linee guida spiegano come verificare la manutenzione e la configurazione di Windows, esaminare i valori del Registro di sistema e i log eventi rilevanti e identificare quando le limitazioni del firmware o della piattaforma richiedono un aggiornamento OEM. Questo contenuto è destinato alla diagnosi dei problemi nei dispositivi esistenti. Non è destinato a pianificare nuove distribuzioni. Questo documento verrà aggiornato man mano che verranno identificati nuovi scenari di risoluzione dei problemi e le indicazioni.
Funzionamento della manutenzione dei certificati di avvio protetto
Manutenzione del certificato di avvio protetto in Windows è un processo coordinato tra il sistema operativo e il firmware UEFI di un dispositivo. L'obiettivo è quello di aggiornare gli ancoraggi di trust critico mantenendo la possibilità di avvio in ogni fase.
Il processo è basato su un'attività pianificata di Windows, una sequenza di azioni di aggiornamento basata sul Registro di sistema e un comportamento predefinito di registrazione e ripetizione dei tentativi. Insieme, questi componenti assicurano che i certificati di avvio protetto e il gestore di avvio di Windows vengano aggiornati in modo controllato e ordinato e solo dopo l'esito positivo dei passaggi dei prerequisiti.
Da dove iniziare durante la risoluzione dei problemi
Quando un dispositivo non sembra effettuare lo stato di avanzamento previsto applicando gli aggiornamenti del certificato di avvio protetto, inizia identificando la categoria del problema. La maggior parte dei problemi rientrano in una delle quattro aree seguenti: stato di manutenzione di Windows, meccanismo di aggiornamento dell'avvio protetto, comportamento del firmware o limitazione di piattaforma o OEM.
Iniziare con i controlli riportati di seguito, nell'ordine indicato. In molti casi, questi passaggi sono sufficienti per spiegare il comportamento osservato e determinare le azioni successive senza un'analisi più approfondita.
-
Verifica l'idoneità alla piattaforma e alla manutenzione di Windows
-
Verifica che il dispositivo soddisfi i requisiti di base per ricevere gli aggiornamenti del certificato di avvio protetto:
-
Il dispositivo esegue una versione supportata di Windows.
-
Vengono installati gli aggiornamenti della sicurezza di Windows più recenti necessari.
-
Avvio protetto è abilitato nel firmware UEFI.
-
Se una di queste condizioni non viene soddisfatta, risolverla prima di proseguire con la risoluzione dei problemi.
-
-
Verificare lo stato dell'attività Secure-Boot-Update
-
Verifica che il meccanismo di Windows responsabile dell'applicazione degli aggiornamenti del certificato di avvio protetto sia presente e funzionante:
-
L'attività programmata Secure-Boot-Update esiste.
-
L'attività viene abilitata ed eseguita come sistema locale.
-
L'attività è stata eseguita almeno una volta dall'installazione dell'aggiornamento della sicurezza di Windows più recente.
-
Se l'attività è disabilitata, eliminata o non è in esecuzione, non è possibile applicare gli aggiornamenti del certificato di avvio protetto. La risoluzione dei problemi dovrebbe concentrarsi sul ripristino dell'attività prima di analizzare altre cause.
-
-
Controllare le impostazioni del Registro di sistema per la progressione prevista
Controlla lo stato di manutenzione di Avvio protetto del dispositivo nel Registro di sistema:
-
Esaminare UEFICA2023Status, UEFICA2023Error e UEFICA2023ErrorEvent.
-
Esaminare AvailableUpdates e confrontarlo con la progressione prevista (vedere Riferimenti e interni).
Insieme, questi valori indicano se l'esecuzione della manutenzione è in corso normalmente, se si sta riprovando un'operazione o se è bloccata in un passaggio specifico.
-
-
Correlare lo stato del Registro di sistema con gli eventi di avvio protetto
Esaminare gli eventi correlati all'avvio protetto nel registro eventi di sistema e correlarli con lo stato del Registro di sistema. I dati degli eventi in genere verificano se il dispositivo sta avanzando, riprova a causa di una condizione transitoria o è bloccato da un problema del firmware o della piattaforma.
Insieme, il Registro di sistema e i registri eventi in genere indicano se il comportamento è previsto, temporaneo o richiede azioni correttive.
Attività pianificata Secure-Boot-Update
La manutenzione del certificato di avvio protetto viene implementata tramite un'attività pianificata di Windows denominata Secure-Boot-Update. L'attività viene registrata nel percorso seguente:
\Microsoft\Windows\PI\Secure-Boot-Update
L'attività viene eseguita come sistema locale. Per impostazione predefinita, viene eseguito all'avvio del sistema e successivamente ogni 12 ore. Ogni volta che viene eseguito, controlla se le azioni di aggiornamento di Avvio protetto sono in sospeso e tenta di applicarle in sequenza.
Se questa attività è disabilitata o mancante, non è possibile applicare gli aggiornamenti del certificato di avvio protetto. L'attività Secure-Boot-Update deve rimanere abilitata per il funzionamento della manutenzione di Avvio protetto.
Perché viene usata un'attività programmata
Gli aggiornamenti del certificato di avvio protetto richiedono il coordinamento tra Windows e il firmware UEFI, inclusa la scrittura di variabili UEFI per l'archiviazione di chiavi e certificati di avvio protetto. Un'attività pianificata consente a Windows di provare questi aggiornamenti quando il sistema si trova in uno stato in cui è possibile modificare le variabili firmware.
La pianificazione ricorrente di 12 ore offre ulteriori opportunità per riprovare gli aggiornamenti se un tentativo precedente non è riuscito o se il dispositivo è rimasto acceso senza riavviarsi. Questa progettazione consente di garantire progressi in avanti senza richiedere l'intervento manuale.
Maschera di bit del Registro di sistema AvailableUpdates
L'attività Secure-Boot-Update è basata sul valore del Registro di sistema AvailableUpdates . Questo valore è una maschera di bit a 32 bit che si trova in:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Ogni bit nel valore rappresenta un'azione specifica di aggiornamento dell'avvio protetto. Il processo di aggiornamento inizia quando AvailableUpdates è impostato su un valore diverso da zero, automaticamente da Windows o in modo esplicito da un amministratore. Ad esempio, un valore come 0x5944 indica che sono in sospeso più azioni di aggiornamento.
Quando viene eseguita l'attività Secure-Boot-Update, interpreta i bit impostati come lavori in sospeso e li elabora in un ordine definito.
Aggiornamenti sequenziali, registrazione e comportamento di nuovo processo
Gli aggiornamenti del certificato di avvio protetto vengono applicati in un ordine fisso. Ogni azione di aggiornamento è progettata per essere sicura di riprovare e completarsi in modo indipendente. L'attività Secure-Boot-Update non avanza al passaggio successivo fino all'esito positivo dell'azione corrente e il bit corrispondente viene cancellato da AvailableUpdates.
Ogni operazione utilizza interfacce UEFI standard per aggiornare le variabili di avvio protetto, ad esempio DB e KEK, o per installare il boot manager di Windows aggiornato. Windows registra il risultato di ogni passaggio nel registro eventi di sistema. Gli eventi di successo confermano lo stato di avanzamento, mentre gli eventi di errore indicano il motivo per cui non è stato possibile completare un'azione.
Se un passaggio di aggiornamento non riesce, l'attività interrompe l'elaborazione, registra l'errore e lascia il bit associato impostato. L'operazione viene ritentata alla successiva esecuzione dell'attività. Questo comportamento di nuovo processo consente ai dispositivi di ripristinarsi automaticamente in seguito a condizioni temporanee, ad esempio supporto del firmware mancante o aggiornamenti OEM ritardati.
Gli amministratori possono tenere traccia dell'avanzamento correlando lo stato del Registro di sistema con le voci del registro eventi. I valori del Registro di sistema come UEFICA2023Status, UEFICA2023Error e UEFICA2023ErrorEvent, insieme alla maschera di bit AvailableUpdates , indicano quale passaggio è attivo, completato o bloccato.
Questa combinazione indica se il dispositivo progredisce normalmente, riprova un'operazione o se è bloccato.
Integrazione con firmware OEM
Gli aggiornamenti del certificato di avvio protetto dipendono dal comportamento corretto e dal supporto nel firmware UEFI di un dispositivo. Mentre Windows orchestra il processo di aggiornamento, il firmware è responsabile dell'applicazione dei criteri di avvio protetto e della gestione dei database di avvio protetto.
Gli OEM forniscono due elementi critici che consentono la manutenzione dei certificati di avvio protetto:
-
Chiavi di exchange chiave con firma chiave della piattaforma che autorizzano l'installazione di nuovi certificati di avvio protetto.
-
Implementazioni del firmware che conservano, accodano e convalidano correttamente i database di avvio protetto durante gli aggiornamenti.
Se il firmware non supporta completamente questi comportamenti, gli aggiornamenti di Avvio protetto possono bloccarsi, riprovare a tempo indeterminato o causare errori di avvio. In questi casi, Windows non può completare l'aggiornamento senza modifiche al firmware.
Microsoft collabora con gli OEM per identificare i problemi del firmware e rendere disponibili gli aggiornamenti corretti. Quando la risoluzione dei problemi indica una limitazione o un difetto del firmware, gli amministratori potrebbero dover installare l'aggiornamento più recente del firmware UEFI fornito dal produttore del dispositivo prima che gli aggiornamenti del certificato di avvio protetto possano essere completati correttamente.
Scenari di errore e risoluzioni comuni
Gli aggiornamenti di avvio protetto vengono applicati dall'attività pianificata Secure-Boot-Update in base allo stato del Registro di sistema AvailableUpdates .
In condizioni normali, questi passaggi si verificano automaticamente e registrano gli eventi di successo al completamento di ogni fase. In alcuni casi, il comportamento del firmware, la configurazione della piattaforma o i prerequisiti di manutenzione possono impedire lo stato di avanzamento o causare un comportamento di avvio imprevisto.
Le sezioni seguenti descrivono gli scenari di errore più comuni, come riconoscerli, perché si verificano e i passaggi successivi appropriati per ripristinare il normale funzionamento. Gli scenari sono ordinati dalla più comune a casi più gravi che influiscono sull'avvio.
Quando gli aggiornamenti di Avvio protetto non mostrano alcun avanzamento, in genere significa che il processo di aggiornamento non è mai stato avviato. Di conseguenza, i valori del Registro di sistema e i registri eventi di avvio protetto previsti non sono presenti perché il meccanismo di aggiornamento non è mai stato attivato.
Cos'è successo
Il processo di aggiornamento dell'avvio protetto non è stato avviato, quindi al dispositivo non sono stati applicati certificati di avvio protetto o gestione di avvio aggiornato.
Come riconoscerlo
-
Non sono presenti valori del Registro di sistema di manutenzione di Secure Boot, ad esempio UEFICA2023Status.
-
Gli eventi di avvio protetto previsti (ad esempio 1043, 1044, 1045, 1799, 1801) non sono presenti nel registro eventi di sistema.
-
Il dispositivo continua a usare i certificati di avvio protetto e i componenti di avvio meno recenti.
Perché succede
Questo scenario si verifica in genere quando si verifica una o più delle condizioni seguenti:
-
L'attività pianificata Secure-Boot-Update è disabilitata o mancante.
-
Avvio protetto è disabilitato nel firmware UEFI.
-
Il dispositivo non soddisfa i prerequisiti di manutenzione di Windows, ad esempio l'esecuzione di una versione di Windows supportata o l'installazione degli aggiornamenti necessari.
Operazioni successive
-
Verifica che il dispositivo soddisfi i requisiti di manutenzione e idoneità della piattaforma Windows.
-
Verifica che Avvio protetto sia abilitato nel firmware.
-
Verificare che l'attività programmata SecureBootUpdate esista e sia abilitata.
Se l'attività pianificata è disabilitata o mancante, segui le indicazioni in Attività pianificata avvio protetto disabilitata o eliminata per ripristinarla. Dopo aver ripristinato l'attività, riavvia il dispositivo o esegui l'attività manualmente per avviare la manutenzione di Avvio protetto.
In alcuni casi, gli aggiornamenti correlati all'avvio protetto possono causare l'immissione di ripristino di BitLocker in un dispositivo. Il comportamento può essere transitoria o persistente, a seconda della causa sottostante.
Scenario 1: ripristino di BitLocker onetime dopo l'aggiornamento di avvio protetto
Che succede
Il dispositivo immette il ripristino di BitLocker al primo avvio dopo l'aggiornamento di avvio protetto, ma viene avviato normalmente nei riavvii successivi.
Perché succede
Durante il primo avvio dopo l'aggiornamento, il firmware non segnala ancora i valori di avvio protetto aggiornati quando Windows tenta di eseguire nuovamente BitLocker. Ciò causa una mancata corrispondenza temporanea nei valori di avvio misurati e attiva il ripristino. All'avvio successivo, il firmware segnala i valori aggiornati correttamente, BitLocker esegue nuovamente il resealing e il problema non si ripete.
Come riconoscerlo
-
Il ripristino di BitLocker si verifica una volta.
-
Dopo aver immesso il codice di ripristino, gli avvii successivi non richiedono il ripristino.
-
Non è presente alcun ordine di avvio o coinvolgimento PXE in corso.
Operazioni successive
-
Immetti la chiave di ripristino di BitLocker per riprendere Windows.
-
Verifica la disponibilità di aggiornamenti del firmware.
Scenario 2: ripristino ripetuto di BitLocker a causa della configurazione del primo avvio PXE
Che succede
Il dispositivo immette il ripristino di BitLocker a ogni avvio.
Perché succede
Il dispositivo è configurato per tentare prima l'avvio PXE (rete). Il tentativo di avvio PXE non riesce e il firmware torna quindi alla gestione di avvio di Windows su disco.
Di conseguenza , due diverse autorità di firma vengono misurate durante un singolo ciclo di avvio:
-
Il percorso di avvio PXE è firmato da Microsoft UEFI CA 2011.
-
Gestione avvio di Windows su disco è firmato dalla CA 2023 della UEFI di Windows.
Poiché BitLocker osserva diverse catene di trust di avvio protetto durante l'avvio, non può stabilire un set stabile di misure TPM da usare di nuovo. Di conseguenza, BitLocker immette il ripristino a ogni avvio.
Come riconoscerlo
-
Il ripristino di BitLocker viene attivato a ogni riavvio.
-
L'immissione della chiave di ripristino consente l'avvio di Windows, ma la richiesta viene restituita all'avvio successivo.
-
PXE o avvio di rete è configurato prima del disco locale nell'ordine di avvio del firmware.
Operazioni successive
-
Configura l'ordine di avvio del firmware, in modo che gestione di avvio di Windows su disco sia il primo.
-
Disabilita l'avvio PXE se non è necessario.
-
Se È necessario PXE, verifica che l'infrastruttura PXE usi un caricatore di avvio di Windows con firma 2023.
Cos'è successo
Questo riflette una modifica a livello di firmware anziché un problema di Windows. L'aggiornamento dell'avvio protetto è stato completato correttamente, ma dopo un riavvio successivo il dispositivo non viene più avviato in Windows.
Come riconoscerlo
-
Il dispositivo non riesce ad avviare Windows e potrebbe visualizzare un messaggio relativo al firmware o al BIOS che indica una violazione di avvio protetto.
-
L'errore si verifica dopo il ripristino delle impostazioni di avvio protetto alle impostazioni predefinite del firmware.
-
La disabilitazione di Avvio protetto potrebbe consentire al dispositivo di eseguire di nuovo l'avvio.
Perché succede
La reimpostazione dell'avvio protetto alle impostazioni predefinite del firmware cancella i database di avvio protetto archiviati nel firmware. Nei dispositivi che sono già stati convertiti in Gestione avvio con firma UEFI di Windows 2023, questa reimpostazione rimuove i certificati necessari per considerare attendibile tale boot manager.
Di conseguenza, il firmware non riconosce più il boot manager di Windows installato come attendibile e blocca il processo di avvio.
Questo scenario non è causato dall'aggiornamento di avvio protetto, ma da un'azione firmware successiva che rimuove gli ancoraggi attendibili aggiornati.
Operazioni successive
-
Usa l'utilità di ripristino di avvio protetto per ripristinare il certificato richiesto, in modo che il dispositivo possa eseguire di nuovo l'avvio.
-
Dopo il ripristino, assicurati che il dispositivo disponga del firmware più recente installato dal produttore del dispositivo.
-
Evita di reimpostare l'avvio protetto alle impostazioni predefinite del firmware, a meno che il firmware OEM non includa valori predefiniti di avvio protetto aggiornati che consideri attendibili i certificati 2023.
Utilità di ripristino avvio protetto
Per ripristinare il sistema:
-
In un secondo PC Windows con l'aggiornamento di Windows di luglio 2024 o versione successiva installato, copiare SecureBootRecovery.efi da C:\Windows\Boot\EFI\.
-
Posiziona il file in un'unità USB in formato FAT32 in \EFI\BOOT\ e rinominalo in bootx64.efi.
-
Avvia il dispositivo interessato dall'unità USB e consenti l'esecuzione dell'utilità di ripristino. L'utilità aggiungerà la CA 2023 dell'interfaccia UEFI di Windows al database.
Dopo il ripristino del certificato e il riavvio del sistema, Windows dovrebbe avviarsi normalmente.
Importante: Questo processo riapplica solo uno dei nuovi certificati. Una volta ripristinato il dispositivo, verifica che siano stati riapplicati i certificati più recenti e valuta l'aggiornamento del BIOS/UEFI del sistema alla versione più recente disponibile. Ciò consente di evitare la ricorrenza del problema di reimpostazione dell'avvio protetto, poiché molti OEM hanno rilasciato correzioni del firmware per questo problema specifico.
Cos'è successo
Dopo l'applicazione dell'aggiornamento del certificato di avvio protetto e il riavvio, l'avvio del dispositivo non riesce e non raggiunge Windows.
Come riconoscerlo
-
Il dispositivo ha esito negativo subito dopo il riavvio richiesto dall'aggiornamento di avvio protetto.
-
Potrebbe essere visualizzato un errore di firmware o avvio protetto o il sistema può arrestarsi prima del caricamento di Windows.
-
La disabilitazione di Avvio protetto potrebbe consentire l'avvio del dispositivo.
Perché succede
Questo problema potrebbe essere causato da un difetto nell'implementazione del firmware UEFI del dispositivo.
Quando Windows applica gli aggiornamenti del certificato di avvio protetto, è previsto che il firmware accoda nuovi certificati al database di firma (DB) di avvio protetto esistente. Alcune implementazioni del firmware sovrascrivono erroneamente il DATABASE invece di aggiungervi.
In questo caso,
-
I certificati attendibili in precedenza, incluso il certificato del bootloader Di Microsoft 2011, vengono rimossi.
-
Se il sistema usa ancora un boot manager firmato con il certificato 2011 a quel punto, il firmware non lo considera più attendibile.
-
Il firmware rifiuta il boot manager e blocca il processo di avvio.
In alcuni casi, il DB può anche risultare danneggiato anziché sovrascritto in modo pulito, portando allo stesso risultato. Questo comportamento è stato osservato in implementazioni specifiche del firmware e non è previsto nel firmware conforme.
Operazioni successive
-
Immetti i menu di configurazione del firmware e prova a ripristinare le impostazioni di avvio protetto.
-
Se il dispositivo viene avviato dopo la reimpostazione, controlla il sito di supporto del produttore del dispositivo per un aggiornamento del firmware che corregge la gestione di Secure Boot DB.
-
Se è disponibile un aggiornamento del firmware, installalo prima di abilitare nuovamente Avvio protetto e riapplicare gli aggiornamenti del certificato di avvio protetto.
Se il ripristino dell'avvio protetto non ripristina la funzionalità di avvio, è probabile che un ulteriore ripristino richieda indicazioni specifiche per OEM.
Cos'è successo
L'aggiornamento del certificato di avvio protetto non viene completato e rimane bloccato nella fase di aggiornamento della chiave di exchange (KEK).
Come riconoscerlo
-
Il valore del Registro di sistema AvailableUpdates rimane impostato con il bit KEK (0x0004) e non viene cancellato.
-
UEFICA2023Status non avanza a uno stato completato.
-
Il registro eventi di sistema registra ripetutamente l'ID evento 1803, a indicare che non è stato possibile applicare l'aggiornamento DIK.
-
Il dispositivo continua a ripetere l'aggiornamento senza avanzare.
Perché succede
L'aggiornamento di Secure Boot KEK richiede l'autorizzazione dalla chiave di piattaforma (PK) del dispositivo, di proprietà dell'OEM.
Affinché l'aggiornamento abbia esito positivo, il produttore del dispositivo deve fornire a Microsoft un KEK firmato PK per tale piattaforma specifica. Questo KEK firmato da OEM è incluso negli aggiornamenti di Windows e consente a Windows di aggiornare la variabile KEK del firmware.
Se l'OEM non ha fornito un KEK firmato da PK per il dispositivo, Windows non può completare l'aggiornamento di KEK. In questo stato:
-
Gli aggiornamenti di Avvio protetto sono bloccati dalla progettazione.
-
Windows non può aggirare l'autorizzazione mancante.
-
Il dispositivo può rimanere definitivamente in grado di completare la manutenzione del certificato di avvio protetto.
Ciò può verificarsi nei dispositivi meno recenti o fuori supporto in cui l'OEM non fornisce più aggiornamenti del firmware o delle chiavi. Non esiste alcun percorso di ripristino manuale supportato per questa condizione.
Quando gli aggiornamenti del certificato di avvio protetto non vengono applicati, Windows registra gli eventi di diagnostica che spiegano il motivo per cui lo stato di avanzamento è stato bloccato. Questi eventi vengono scritti durante l'aggiornamento del database di firma di avvio protetto (DB) o chiave di exchange chiave (KEK) non può essere completato in modo sicuro a causa di firmware, stato della piattaforma o condizioni di configurazione. Gli scenari in questa sezione fanno riferimento a questi eventi per identificare i modelli di errore comuni e determinare la correzione appropriata. Questa sezione è stata progettata per supportare la diagnosi e l'interpretazione dei problemi descritti in precedenza e non per introdurre nuovi scenari di errore.
Per un elenco completo di ID evento, descrizioni e voci di esempio, vedere Secure Boot DB and DBX variable update events (KB5016061).
Errore di aggiornamento di KEK (gli aggiornamenti DB hanno esito positivo, KEK no)
Un dispositivo può aggiornare correttamente i certificati nel database di avvio protetto, ma non riesce durante l'aggiornamento di KEK. In questo caso, il processo di aggiornamento di Avvio protetto non può essere completato.
Sintomi
-
Gli eventi del certificato DB indicano lo stato di avanzamento, ma la fase di KEK non è stata completata.
-
AvailableUpdates rimane impostato su 0x4004 e il bit 0x0004 non viene cancellato dopo l'esecuzione di più attività.
-
L'evento 1795 o 1803 potrebbe essere presente.
Interpretazione
-
1795 indica in genere un errore del firmware durante il tentativo di aggiornamento di una variabile di avvio protetto.
-
1803 indica che l'aggiornamento KEK non può essere autorizzato perché un payload KEK firmato OEM richiesto non è disponibile per la piattaforma.1803 indicates that the KEK update cannot be authorized because a OEM PK-signed KEK payload isn't available for the platform.
Passaggi successivi
-
Per 1795, verifica la disponibilità di aggiornamenti del firmware OEM e convalida il supporto del firmware per gli aggiornamenti delle variabili di avvio protetto.
-
Per 1803, verifica se l'OEM ha fornito a Microsoft la CHIAVE DIK firmata PK richiesta per il modello di dispositivo.
Errore di aggiornamento di KEK nelle macchine virtuali guest ospitate su Hyper-V
Nelle macchine virtuali Hyper-V, gli aggiornamenti del certificato di avvio protetto richiedono che gli aggiornamenti di Windows di marzo 2026 siano installati sia nell'host Hyper-V che nel sistema operativo guest.
Gli errori di aggiornamento vengono segnalati dall'interno del guest, ma l'evento indica dove è necessaria una correzione:
-
L'evento 1795 (ad esempio, "Il supporto è protetto da scrittura") riportato nel guest indica che all'host Hyper-V manca l'aggiornamento di marzo 2026 e deve essere aggiornato.
-
L'evento 1803 riportato nel guest indica che alla macchina virtuale guest manca l'aggiornamento di marzo 2026 e deve essere aggiornata.
Riferimenti ed interni
Questa sezione contiene informazioni di riferimento avanzate destinate alla risoluzione dei problemi e al supporto. Non è destinato alla pianificazione della distribuzione. Si espande sui meccanismi di manutenzione secure boot riepilogati in precedenza e fornisce materiale di riferimento dettagliato per l'interpretazione dei registri di stato del Registro di sistema e degli eventi.
Nota (distribuzioni gestite dall'IT):: se configurate tramite Criteri di gruppo o Microsoft Intune, non devono essere confuse due impostazioni simili. Il valore AvailableUpdatesPolicy rappresenta lo stato del criterio configurato. Nel frattempo, AvailableUpdates riflette lo stato di lavoro in corso e di cancellazione dei bit. Entrambi possono generare lo stesso risultato, ma si comportano in modo diverso perché i criteri si applicano di nuovo nel tempo.
AvailableUpdates bits used for certificate servicing
I bit seguenti vengono usati per le azioni relative al certificato e al boot manager descritte in questo documento. La colonna Ordine riflette la sequenza in cui l'attività Secure-Boot-Update elabora ogni bit.
|
Ordine |
Impostazione di bit |
uso |
|---|---|---|
|
1 |
0x0040 |
Questo bit indica all'attività pianificata di aggiungere il certificato UEFI CA 2023 di Windows al db di avvio protetto. Ciò consente a Windows di considerare attendibili i responsabili di avvio firmati da questo certificato. |
|
2 |
0x0800 |
Questo bit indica all'attività programmata di applicare la UEFI CA 2023 della ROM di opzione Microsoft al DATABASE. Comportamento condizionale: quando il flag 0x4000 è impostato, l'attività programmata controlla prima il database per il certificato UEFI CA 2011 di Microsoft Corporation. Applicherà il certificato UEFI CA 2023 della Microsoft Option ROMsolo se è presente il certificato 2011. |
|
3 |
0x1000 |
Questo bit indica all'attività programmata di applicare la CA 2023 di Microsoft UEFI al database. Comportamento condizionale: quando il flag 0x4000 è impostato, l'attività programmata controlla prima il database per il certificato UEFI CA 2011 di Microsoft Corporation . Il certificato CA 2023 della UEFI Microsoft verrà applicato solo se è presente il certificato 2011. |
|
Modificatore (flag di comportamento) |
0x4000 |
Questo bit modifica il comportamento dei bit 0x0800 e 0x1000 in modo che la UEFI CA 2023 e la UEFI 202 3 di Microsoft Option ROMvengano applicate solo se il DATABASE contiene già la UEFI DI Microsoft Corporation 2011. Per garantire che il profilo di sicurezza del dispositivo rimanga invariato, questo bit applica questi nuovi certificati solo se il dispositivo considera attendibile il certificato UEFI CA 2011 di Microsoft Corporation. Non tutti i dispositivi Windows considera attendibile questo certificato. |
|
4 |
0x0004 |
Questo bit indica all'attività pianificata di cercare una chiave di Exchange chiave firmata dalla chiave di piattaforma (PK) del dispositivo. Il PK è gestito dall'OEM. Gli OEM firmano la chiave di gestione delle chiavi di Microsoft con il proprio codice PK e la recapitano a Microsoft, dove è inclusa negli aggiornamenti cumulativi mensili. |
|
5 |
0x0100 |
Questo bit indica all'attività pianificata di applicare alla partizione di avvio il boot manager firmato dalla CA 2023 dell'interfaccia UEFI di Windows. Questa operazione sostituirà il boot manager firmato di Microsoft Windows Production PCA 2011. |
Note:
-
Il bit 0x4000 rimarrà impostato dopo l'elaborazione di tutti gli altri bit.
-
Ogni bit viene elaborato dall'attività pianificata Secure-Boot-Update nell'ordine indicato sopra.
-
Se il bit 0x0004 non può essere elaborato a causa di un KEK firmato PK mancante, l'attività pianificata continuerà ad applicare l'aggiornamento di boot manager indicato da bit 0x0100.
Progressione prevista (AvailableUpdates)
Quando un'operazione viene completata correttamente, Windows cancella il bit associato da AvailableUpdates. Se un'operazione non riesce, Windows registra un evento e ripete i tentativi quando l'attività viene eseguita di nuovo.
La tabella seguente mostra la progressione prevista dei valori di AvailableUpdates al completamento di ogni azione di aggiornamento dell'avvio protetto.
|
Passaggio |
Bit elaborato |
Disponibile Aggiornamenti |
Descrizione |
Operazione riuscita registrata |
Codici evento di errore possibili |
|---|---|---|---|---|---|
|
Start |
0x5944 |
Stato iniziale prima dell'inizio della manutenzione del certificato di avvio protetto. |
- |
- |
|
|
1 |
0x0040 |
0x5944 → 0x5904 |
Windows UEFI CA 2023 viene aggiunto al db di avvio protetto. |
1036 |
1032, 1795, 1796, 1802 |
|
2 |
0x0800 |
0x5904 → 0x5104 |
Aggiungere Microsoft Option ROM UEFI CA 2023 al database se il dispositivo in precedenza attendibile microsoft UEFI CA 2011. |
1044 |
1032, 1795, 1796, 1802 |
|
3 |
0x1000 |
0x5104 → 0x4104 |
Microsoft UEFI CA 2023 viene aggiunto al database se il dispositivo in precedenza attendibile microsoft UEFI CA 2011. |
1045 |
1032, 1795, 1796, 1802 |
|
4 |
0x0004 |
0x4104 → 0x4100 |
Viene applicata la nuova CA 2023 Microsoft KEK 2K firmata dalla chiave di piattaforma OEM. |
1043 |
1032, 1795, 1796, 1802, 1803 |
|
5 |
0x0100 |
0x4100 → 0x4000 |
Boot manager firmato da WINDOWS UEFI CA 2023 è installato. |
1799 |
1797 |
Note
-
Una volta completata l'operazione associata a un bit, tale bit viene cancellato da AvailableUpdates.
-
Se una di queste operazioni non riesce, viene registrato un evento e l'operazione viene ritentata alla successiva esecuzione dell'attività programmata.
-
Il bit 0x4000 è un modificatore e non viene cancellato. Il valore finale di 0x4000 AvailableUpdates indica il completamento corretto di tutte le azioni di aggiornamento applicabili.
-
Gli eventi 1032, 1795, 1796 e 1802 indicano in genere limitazioni del firmware o della piattaforma.
-
L'evento 1803 indica che manca KEK firmato da OEM PK.
Procedure di correzione
In questa sezione vengono fornite procedure dettagliate per risolvere specifici problemi di avvio protetto. Ogni procedura è limitata a una condizione ben definita e deve essere seguita solo dopo che la diagnosi iniziale conferma l'applicazione del problema. Usa queste procedure per ripristinare il comportamento di avvio protetto previsto e consentire agli aggiornamenti dei certificati di procedere in modo sicuro. Non applicare queste procedure su vasta scala o preventivamente.
Abilitazione dell'avvio protetto nel firmware
Se Avvio protetto è disabilitato nel firmware di un dispositivo, vedi Windows 11 e avvio protetto per informazioni dettagliate sull'abilitazione dell'avvio protetto.
Attività pianificata avvio protetto disabilitata o eliminata
L'attività pianificata Secure-Boot-Update è necessaria affinché Windows applichi gli aggiornamenti del certificato di avvio protetto. Se l'attività è disabilitata o mancante, la manutenzione del certificato di avvio protetto non si progredisce.
Dettagli attività
|
Nome attività |
Aggiornamento di avvio protetto |
|
Percorso attività |
\Microsoft\Windows\PI. |
|
Percorso completo |
\Microsoft\Windows\PI\Secure-Boot-Update |
|
Viene eseguito come |
SISTEMA (Sistema locale) |
|
Attivazione |
All'avvio e ogni 12 ore |
|
Stato obbligatorio |
Abilitato |
Come controllare lo stato delle attività
Esegui da un prompt di PowerShell con privilegi elevati: schtasks.exe /Query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V
Cercare il campo Stato:
|
Stato |
Significato |
|---|---|
|
Pronto |
L'attività esiste ed è abilitata. |
|
Disattivato |
L'attività esiste ma deve essere abilitata. |
|
Errore/Non trovato |
L'attività non è presente e deve essere ricreata. |
Come abilitare o ricreare l'attività
Se il campo di stato per Secure-Boot-Update è disabilitato, errore o non trovato, usare lo script di esempio per abilitare l'attività: esempio Enable-SecureBootUpdateTask.ps1
Nota: si tratta di uno script di esempio e non è supportato da Microsoft. Gli amministratori devono rivederla e adattarla al proprio ambiente.
Esempio:
.\Enable-SecureBootUpdateTask.ps1 -Quiet
Linee guida
-
Se viene visualizzato Access negato, eseguire di nuovo PowerShell come amministratore.
-
Se lo script non viene eseguito a causa dei criteri di esecuzione, usare un bypass dell'ambito di processo:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Serve aiuto?
Vuoi altre opzioni?
Esplorare i vantaggi dell'abbonamento e i corsi di formazione, scoprire come proteggere il dispositivo e molto altro ancora.
Le community aiutano a porre e a rispondere alle domande, a fornire feedback e ad ascoltare gli esperti con approfondite conoscenze.
