Nota
- Data di pubblicazione originale: 19 marzo 2026
- ID KB: 5085046
Contenuto dell'articolo
- Panoramica
- Come funziona la manutenzione di un certificato di avvio protetto
- Da dove iniziare durante la risoluzione dei problemi
- Attività pianificata Secure-Boot-Update
- Perché viene usata un'attività pianificata
- Maschera di bit del Registro di sistema AvailableUpdates
- Integrazione con firmware OEM
- Scenari di errore comuni e risoluzioni
- Riferimenti e interni
- Bit AvailableUpdates usati per la manutenzione dei certificati
- Progressione prevista (AvailableUpdates)
- Procedure di bonifica
- Abilitazione dell'avvio protetto nel firmware
- Attività pianificata di avvio protetto disabilitata o eliminata
Panoramica
Questa pagina guida gli amministratori e i professionisti del supporto tecnico nella diagnosi e nella 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 di BitLocker impreviste ed errori di avvio successivi a modifiche alla configurazione di avvio protetto.
Le linee guida illustrano come verificare la manutenzione e la configurazione di Windows, esaminare i valori del Registro di sistema e i registri eventi pertinenti 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 alla pianificazione di nuove distribuzioni. Questo documento verrà aggiornato man mano che vengono identificati nuovi scenari di risoluzione dei problemi e linee guida.
Come funziona la manutenzione del certificato di avvio protetto
La manutenzione del certificato di avvio protetto in Windows è un processo coordinato tra il sistema operativo e il firmware UEFI di un dispositivo. L'obiettivo è aggiornare i trust anchor critici mantenendo la possibilità di avvio in ogni fase.
Il processo è gestito da un'attività pianificata di Windows, una sequenza di azioni di aggiornamento basata sul Registro di sistema e un comportamento predefinito di registrazione e riprova. Insieme, questi componenti assicurano che i certificati di avvio protetto e Windows Boot Manager vengano aggiornati in modo controllato e ordinato e solo dopo il completamento dei passaggi dei prerequisiti.
Da dove iniziare durante la risoluzione dei problemi
Quando un dispositivo non sembra compiere i progressi previsti nell'applicazione degli aggiornamenti del certificato di avvio protetto, inizia identificando la categoria del problema. La maggior parte dei problemi rientra in una delle quattro aree seguenti: stato di manutenzione di Windows, meccanismo di aggiornamento dell'avvio protetto, comportamento del firmware o limitazione della piattaforma o dell'OEM.
Inizia con i controlli qui sotto, nell'ordine. In molti casi, questi passaggi sono sufficienti per spiegare il comportamento osservato e determinare le azioni successive senza un'indagine più approfondita.
Verifica l'idoneità della piattaforma e della manutenzione di Windows
- Verificare 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.
- Sono installati gli ultimi aggiornamenti della sicurezza di Windows richiesti.
- L'avvio protetto è abilitato nel firmware UEFI.
- Se una di queste condizioni non viene soddisfatta, affrontarla prima di continuare con ulteriori procedure di 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à pianificata Secure-Boot-Update esiste.
- L'attività è abilitata e viene eseguita come Sistema locale.
- L'attività è stata eseguita almeno una volta dall'installazione dell'ultimo aggiornamento della sicurezza di Windows.
- Se l'attività è disabilitata, eliminata o non in esecuzione, gli aggiornamenti del certificato di avvio protetto non possono essere applicati. La risoluzione dei problemi dovrebbe concentrarsi sul ripristino dell'attività prima di analizzare altre cause.
Controlla le impostazioni del registro per la progressione prevista
Esaminare lo stato di manutenzione dell'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 la manutenzione sta procedendo normalmente, riprova un'operazione o si è 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 sugli eventi in genere confermano 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 indicano in genere se il comportamento è previsto, temporaneo o richiede un'azione correttiva.
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:
Nota
\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 dell'avvio protetto sono in sospeso e tenta di applicarle in sequenza.
Se questa attività è disabilitata o mancante, gli aggiornamenti del certificato di avvio protetto non possono essere applicati. L'attività Secure-Boot-Update deve rimanere abilitata per il funzionamento della manutenzione dell'avvio protetto.
Perché viene usata un'attività pianificata
Gli aggiornamenti dei certificati di avvio protetto richiedono il coordinamento tra il firmware Windows e UEFI, inclusa la scrittura di variabili UEFI che archiviano chiavi e certificati di avvio protetto. Un'attività pianificata consente a Windows di tentare questi aggiornamenti quando il sistema si trova in uno stato in cui le variabili del firmware possono essere modificate.
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 l'avanzamento in avanti senza richiedere interventi manuali.
Maschera di bit del Registro di sistema AvailableUpdates
L'attività Secure-Boot-Update è guidata dal valore del Registro di sistema AvailableUpdates . Questo valore è una maschera di bit a 32 bit che si trova in:
Nota
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Ogni bit nel valore rappresenta un'azione di aggiornamento di avvio protetto specifica. 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 lavoro in sospeso e li elabora in un ordine definito.
Aggiornamento sequenziale, registrazione e nuovo comportamento di prova
Gli aggiornamenti del certificato di avvio protetto vengono applicati in un ordine fisso. Ogni azione di aggiornamento è progettata per essere sicura da riprovare e viene completata in modo indipendente. L'attività Secure-Boot-Update non avanza al passaggio successivo fino a quando l'azione corrente non ha esito positivo e il bit corrispondente viene cancellato da AvailableUpdates.
Ogni operazione utilizza interfacce UEFI standard per aggiornare le variabili di avvio protetto, ad esempio il database e la chiave KEK, o per installare il gestore di avvio automatico 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 impostato il bit associato. L'operazione viene ritentata alla successiva esecuzione dell'attività. Questo comportamento di ripetizione delle versioni di prova consente ai dispositivi di eseguire automaticamente il ripristino da condizioni temporanee, ad esempio il supporto del firmware mancante o gli aggiornamenti OEM ritardati.
Gli amministratori possono tenere traccia dello stato 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 sta procedendo normalmente, riprova un'operazione o si è bloccato.
Integrazione con firmware OEM
Gli aggiornamenti del certificato di avvio protetto dipendono dal comportamento e dal supporto corretti 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 manutenzione dei database di avvio protetto.
Gli OEM forniscono due elementi critici che consentono la manutenzione del certificato di avvio protetto:
- Chiavi KEK (Platform Key-Signed Key Exchange) 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'ultimo aggiornamento del firmware UEFI fornito dal produttore del dispositivo prima che gli aggiornamenti del certificato di avvio protetto possano essere completati correttamente.
Scenari di errore comuni e risoluzioni
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 l'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 dai casi più comuni a quelli più gravi che hanno un impatto sull'avvio.
Aggiornamenti di avvio protetto non applicati (nessuno stato di avanzamento)
Quando gli aggiornamenti di avvio protetto non mostrano 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 boot manager aggiornati.
Come riconoscerlo
- Non sono presenti valori del registro di sistema di manutenzione per l'avvio protetto, 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 vecchi certificati di avvio protetto e i componenti di avvio.
Perché si verifica
Questo scenario si verifica in genere quando si verificano una o più delle condizioni seguenti:
- L'attività pianificata Secure-Boot-Update è disabilitata o mancante.
- L'avvio protetto è disabilitato nel firmware UEFI.
- Il dispositivo non soddisfa i prerequisiti di manutenzione di Windows, ovvero l'esecuzione di una versione di Windows supportata o l'installazione degli aggiornamenti necessari.
Passaggi successivi
- Verifica che il dispositivo soddisfi i requisiti di idoneità alla piattaforma e alla manutenzione di Windows.
- Verifica che l'avvio protetto sia abilitato nel firmware.
- Verificare che l'attività pianificata SecureBootUpdate esista e sia abilitata.
Se l'attività pianificata è disabilitata o mancante, seguire le indicazioni in Avvio protetto attività pianificata disabilitata o eliminata per ripristinarla. Dopo aver ripristinato l'attività, riavvia il dispositivo o eseguila manualmente per avviare la manutenzione dell'avvio protetto.
Il dispositivo viene avviato in BitLocker ripristino dopo l'aggiornamento dell'avvio protetto
In alcuni casi, gli aggiornamenti correlati all'avvio protetto possono causare l'attivazione del ripristino di BitLocker da parte di un dispositivo. Il comportamento può essere transitorio o persistente, a seconda della causa sottostante.
Scenario 1: Ripristino occasionale di BitLocker dopo l'aggiornamento dell'avvio protetto
Cosa accade
Il dispositivo entra nel ripristino di BitLocker al primo avvio dopo l'aggiornamento dell'avvio protetto, ma viene avviato normalmente ai riavvii successivi.
Perché si verifica
Durante il primo avvio dopo l'aggiornamento, il firmware non segnala ancora i valori di avvio protetto aggiornati quando Windows tenta di risigillare BitLocker. Ciò causa una mancata corrispondenza temporanea nei valori di avvio misurati e attiva il ripristino. All'avvio successivo, il firmware segnala correttamente i valori aggiornati, BitLocker viene risigillato correttamente e il problema non si ripresenta.
Come riconoscerlo
- Il ripristino di BitLocker viene eseguito una sola volta.
- Dopo aver immesso la chiave di ripristino, gli avvii successivi non richiedono il ripristino.
- Non è presente alcun ordine di avvio in corso o coinvolgimento PXE.
Passaggi successivi
- 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
Cosa accade
Il dispositivo entra nel ripristino di BitLocker a ogni avvio.
Perché si verifica
Il dispositivo è configurato per tentare prima l'avvio PXE (di rete). Il tentativo di avvio PXE non riesce e il firmware torna a usare Windows Boot Manager su disco.
Ciò comporta la misurazione di due diverse autorità di firma durante un singolo ciclo di avvio:
- Il percorso di avvio PXE è firmato dalla CA UEFI 2011 di Microsoft.
- Windows Boot Manager su disco è firmato dalla CA UEFI 2023 di Windows.
Poiché BitLocker osserva catene di attendibilità di avvio protetto diverse durante l'avvio, non può stabilire un set stabile di misurazioni del TPM da utilizzare per il ribollaggio. Di conseguenza, BitLocker entra in 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 l'avvio di rete è configurato prima del disco locale nell'ordine di avvio del firmware.
Passaggi successivi
- Configura l'ordine di avvio del firmware, in modo che il Boot Manager di Windows su disco sia il primo.
- Disabilita l'avvio PXE se non è necessario.
- Se PXE è necessario, assicurarsi che l'infrastruttura PXE usi un boot loader Windows firmato 2023.
Il dispositivo non riesce ad avviarsi dopo la reimpostazione dell'avvio protetto
Cos'è successo?
Ciò riflette una modifica a livello di firmware piuttosto che un problema di Windows. L'aggiornamento di 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 del firmware o del BIOS che indica una violazione di avvio protetto.
- L'errore si verifica dopo il ripristino delle impostazioni di avvio protetto ai valori predefiniti del firmware.
- La disabilitazione dell'avvio protetto potrebbe consentire di riavviare il dispositivo.
Perché si verifica
La reimpostazione dell'avvio protetto ai valori predefiniti del firmware cancella i database di avvio protetto archiviati nel firmware. Nei dispositivi che sono già passati al boot manager firmato dalla CA UEFI 2023 di Windows, questa reimpostazione rimuove i certificati necessari per considerare attendibile tale boot manager.
Di conseguenza, il firmware non riconosce più il Windows Boot Manager installato come attendibile e blocca il processo di avvio.
Questo scenario non è causato dall'aggiornamento dell'avvio protetto, ma da un'azione successiva del firmware che rimuove i trust anchor aggiornati.
Passaggi successivi
- Usa l'utilità di ripristino Secure Boot per ripristinare il certificato richiesto, in modo che il dispositivo possa riavviarsi.
- Dopo il ripristino, assicurati che il dispositivo disponga del firmware più recente disponibile installato dal produttore del dispositivo.
- Evita di reimpostare le impostazioni predefinite del firmware per l'avvio protetto a meno che il firmware OEM non includa impostazioni predefinite di avvio protetto aggiornate che considerino attendibili i certificati del 2023.
Utilità di ripristino di avvio protetto
Per ripristinare il sistema:
- In un secondo PC Windows con l'aggiornamento di Windows di luglio 2024 o più recente installato, copiare SecureBootRecovery.efi da C:\Windows\Boot\EFI\.
- Inserire il file in un'unità USB formattata con FAT32 in \EFI\BOOT\ e rinominarlo in bootx64.efi.
- Avviare il dispositivo interessato dall'unità USB e consentire l'esecuzione dell'utilità di ripristino. L'utilità aggiungerà la CA UEFI di Windows 2023 al DB.
Dopo il ripristino del certificato e il riavvio del sistema, Windows dovrebbe avviarsi normalmente.
Importante: Questo processo riapplicherà solo uno dei nuovi certificati. Dopo il ripristino del dispositivo, verifica che siano stati riapplicati i certificati più recenti e valuta la possibilità di aggiornare il BIOS o UEFI del sistema alla versione più recente disponibile. In questo modo è possibile evitare il ripetersi del problema di reimpostazione dell'avvio protetto, poiché molti OEM hanno rilasciato correzioni del firmware per questo problema specifico.
Il dispositivo non riesce ad avviarsi dopo l'aggiornamento dell'avvio protetto a causa della sovrascrittura del firmware nel database
Cos'è successo?
Dopo aver applicato l'aggiornamento del certificato di avvio protetto e averlo riavviato, il dispositivo non riesce ad avviarsi e non raggiunge Windows.
Come riconoscerlo
- Il dispositivo non riesce immediatamente dopo il riavvio richiesto dall'aggiornamento dell'avvio protetto.
- Potrebbe essere visualizzato un errore del firmware o di avvio protetto oppure il sistema può arrestarsi prima del caricamento di Windows.
- La disabilitazione dell'avvio protetto potrebbe consentire l'avvio del dispositivo.
Perché si verifica
Questo problema potrebbe essere causato da un difetto nell'implementazione del firmware UEFI del dispositivo.
Quando Windows applica gli aggiornamenti dei certificati di avvio protetto, il firmware deve aggiungere nuovi certificati al database delle firme consentite per l'avvio protetto esistente. Alcune implementazioni del firmware sovrascrivono in modo errato il DB invece di aggiungervi l'elemento.
In questo caso,
- I certificati precedentemente attendibili, 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 danneggiarsi anziché sovrascriverlo in modo pulito, portando allo stesso risultato. Questo comportamento è stato osservato in implementazioni specifiche del firmware e non è previsto in firmware conforme.
Passaggi successivi
- Immettere i menu di configurazione del firmware e provare a ripristinare le impostazioni di avvio protetto.
- Se il dispositivo viene avviato dopo la reimpostazione, consultare il sito di supporto del produttore del dispositivo per un aggiornamento del firmware che corregga la gestione del database di avvio protetto.
- Se è disponibile un aggiornamento del firmware, installalo prima di riabilitare l'avvio protetto e riapplicare gli aggiornamenti del certificato di avvio protetto.
Se la reimpostazione dell'avvio protetto non ripristina la funzionalità di avvio, è probabile che un ulteriore ripristino richieda indicazioni specifiche dell'OEM.
Aggiornamento dell'avvio protetto bloccato a causa della mancanza della chiave KEK firmata dall'OEM
Cos'è successo?
L'aggiornamento del certificato di avvio protetto non viene completato e rimane bloccato nella fase di aggiornamento della chiave di scambio delle chiavi (KEK).
Come riconoscerlo
- Il valore del Registro di sistema AvailableUpdates rimane impostato con il bit KEK (0x0004) e non viene cancellato.
- UEFICA2023Status non passa a uno stato completato.
- Il registro eventi di sistema registra ripetutamente l'ID evento 1803, indicando che non è stato possibile applicare l'aggiornamento KEK.
- Il dispositivo continua a riprovare l'aggiornamento senza avanzare in avanti.
Perché si verifica
L'aggiornamento della chiave KEK di avvio protetto richiede l'autorizzazione della chiave della piattaforma (PK) del dispositivo, che è di proprietà dell'OEM.
Affinché l'aggiornamento abbia esito positivo, il produttore del dispositivo deve fornire a Microsoft una chiave KEK con firma PK per tale piattaforma specifica. Questa KEK firmata dall'OEM è inclusa negli aggiornamenti di Windows e consente a Windows di aggiornare la variabile KEK del firmware.
Se l'OEM non ha fornito una chiave KEK con firma PK per il dispositivo, Windows non può completare l'aggiornamento della KEK. In questo stato:
- Gli aggiornamenti di avvio protetto sono bloccati per impostazione predefinita.
- Windows non può risolvere il problema dell'autorizzazione mancante.
- Il dispositivo può rimanere permanentemente incapace di completare la manutenzione del certificato di avvio protetto.
Ciò può verificarsi su dispositivi meno recenti o non supportati in cui l'OEM non fornisce più aggiornamenti del firmware o delle chiavi. Non esiste un percorso di ripristino manuale supportato per questa condizione.
Eventi di aggiornamento del certificato di avvio protetto e indicatori di errore
Quando gli aggiornamenti del certificato di avvio protetto non vengono applicati, Windows registra eventi di diagnostica che spiegano perché lo stato di avanzamento è stato bloccato. Questi eventi vengono scritti quando l'aggiornamento del database delle firme di avvio protetto (DB) o della chiave di scambio delle chiavi (KEK) non può essere completato in modo sicuro a causa del firmware, dello stato della piattaforma o delle condizioni di configurazione. Gli scenari in questa sezione fanno riferimento a questi eventi per identificare modelli di errore comuni e determinare la correzione appropriata. Questa sezione ha lo scopo di supportare la diagnosi e l'interpretazione dei problemi descritti in precedenza, non di introdurre nuovi scenari di errore.
Per un elenco completo degli ID evento, delle descrizioni e delle voci di esempio, vedere Eventi di aggiornamento delle variabili (KB5016061) del database di avvio protetto e DBX.
Errore di aggiornamento KEK (gli aggiornamenti del database hanno esito positivo, KEK no)
Un dispositivo può aggiornare correttamente i certificati nel database di avvio protetto, ma non riesce durante l'aggiornamento della KEK. In questo caso, il processo di aggiornamento dell'avvio protetto non può essere completato.
Sintomi
- Gli eventi del certificato database indicano lo stato di avanzamento, ma la fase KEK non è completata.
- AvailableUpdates rimane impostato su 0x4004 e il bit 0x0004 non viene cancellato dopo più esecuzioni di attività.
- Potrebbero essere presenti gli eventi 1795 o 1803 .
Interpretazione
- 1795 indica in genere un errore del firmware durante il tentativo di aggiornare una variabile di avvio protetto.
- 1803 indica che l'aggiornamento KEK non può essere autorizzato perché un payload KEK OEM firmato PK richiesto non è disponibile per la piattaforma.
Passaggi successivi
- Per la versione 1795, verificare la disponibilità di aggiornamenti del firmware OEM e verificare la disponibilità di aggiornamenti del firmware per gli aggiornamenti delle variabili di avvio protetto.
- Per 1803, verificare se l'OEM ha fornito a Microsoft la chiave KEK con firma PK necessaria per il modello del dispositivo.
Errore di aggiornamento della chiave KEK nelle macchine virtuali guest ospitate in Hyper-V
Nelle macchine virtuali Hyper-V, gli aggiornamenti del certificato di avvio protetto richiedono l'installazione degli aggiornamenti di Windows di marzo 2026 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 la correzione:
- L'evento 1795 (ad esempio, "Il supporto è protetto da scrittura") segnalato nel guest , indica che all'host Hyper-V manca l'aggiornamento di marzo 2026 e deve essere aggiornato.
- L'evento 1803 segnalato nel guest indica che alla macchina virtuale guest manca l'aggiornamento di marzo 2026 e deve essere aggiornata.
Riferimenti e interni
Questa sezione contiene informazioni di riferimento avanzate per la risoluzione dei problemi e il supporto. Non è destinato alla pianificazione della distribuzione. Espande i meccanismi di manutenzione di avvio protetto riepilogati in precedenza e fornisce materiale di riferimento dettagliato per l'interpretazione dello stato del Registro di sistema e dei registri 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 dei criteri configurati. Nel frattempo, AvailableUpdates riflette lo stato di lavoro di cancellazione bit in corso. Entrambi possono portare allo stesso risultato, ma si comportano in modo diverso perché la politica si riapplica nel tempo.
Bit AvailableUpdates usati per la manutenzione dei certificati
I bit seguenti vengono utilizzati per le azioni di certificato e boot manager descritte in questo documento. La colonna Ordine riflette la sequenza in cui l'attività Secure-Boot-Update elabora ogni bit.
| Ordine | Impostazione bit | Utilizzo |
|---|---|---|
| 1 | 0x0040 | Questo bit indica all'attività pianificata di aggiungere il certificato CA UEFI 2023 di Windows al database di avvio protetto. Ciò consente a Windows di considerare attendibili i boot manager firmati da questo certificato. |
| 2 | 0x0800 | Questo bit indica all'attività pianificata di applicare Microsoft Option ROM UEFI CA 2023 al DB. Comportamento condizionale: quando il flag di 0x4000 è impostato, l'attività pianificata controllerà prima il database per il certificato CA UEFI 2011 di Microsoft Corporation . Verrà applicato il certificato Microsoft Option ROM UEFI CA 2023solo se è presente il certificato 2011. |
| 3 | 0x1000 | Questo bit indica all'attività pianificata di applicare Microsoft UEFI CA 2023 al DB. Comportamento condizionale: quando il flag di 0x4000 è impostato, l'attività pianificata controllerà prima il database per il certificato CA UEFI 2011 di Microsoft Corporation . Verrà applicato il certificato Microsoft UEFI CA 2023solo se è presente il certificato 2011. |
| Modificatore (flag di comportamento) | 0x4000 | Questo bit modifica il comportamento dei bit 0x0800 e 0x1000 in modo che la CA UEFI 2023 Microsoft e la ROM facoltativa Microsoft UEFI CA 2023 vengano applicate solo se il database contiene già la CA UEFI 2011 di Microsoft Corporation. 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 CA UEFI 2011 di Microsoft Corporation. Non tutti i dispositivi Windows considerano attendibile questo certificato. |
| 4 | 0x0004 | Questo bit indica all'attività pianificata di cercare una chiave di scambio chiavi firmata dalla chiave della piattaforma (PK) del dispositivo. La chiave di distribuzione viene gestita dall'OEM. Gli OEM firmano la chiave KEK Microsoft con la propria chiave primaria e la consegnano a Microsoft, dove è inclusa negli aggiornamenti cumulativi mensili. |
| 5 | 0x0100 | Questo bit indica all'attività pianificata di applicare il boot manager, firmato dalla CA UEFI di Windows 2023, alla partizione di avvio. Questo sostituirà il boot manager firmato Microsoft Windows Production PCA 2011 . |
Note:
- Il 0x4000 bit rimarrà impostato dopo l'elaborazione di tutti gli altri bit.
- Ogni bit viene elaborato dall'attività pianificata Secure-Boot-Update nell'ordine mostrato sopra.
- Se il bit 0x0004 non può essere elaborato a causa di una chiave KEK PK firmata mancante, l'attività pianificata applicherà comunque l'aggiornamento di Boot Manager indicato dal 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 riprova quando l'attività viene eseguita di nuovo.
La tabella seguente mostra l'avanzamento previsto dei valori AvailableUpdates al completamento di ogni azione di aggiornamento dell'avvio protetto.
| Passaggio | Bit elaborati | Aggiornamenti disponibili | Descrizione | Evento di esito positivo registrato | Possibili codici evento di errore |
|---|---|---|---|---|---|
| Inizio | 0x5944 | Stato iniziale prima dell'inizio della manutenzione del certificato di avvio protetto. | - | - | |
| 1 | 0x0040 | 0x5944 → 0x5904 | Windows UEFI CA 2023 viene aggiunto al database di avvio protetto. | 1036 | 1032, 1795, 1796, 1802 |
| 2 | 0x0800 | 0x5904 → 0x5104 | Aggiungere Microsoft Option ROM UEFI CA 2023 al database se il dispositivo ha precedentemente considerato 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 ha precedentemente considerato attendibile Microsoft UEFI CA 2011. | 1045 | 1032, 1795, 1796, 1802 |
| 4 | 0x0004 | 0x4104 → 0x4100 | Viene applicata la nuova Microsoft KEK 2K CA 2023 firmata dalla chiave della 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 correttamente l'operazione associata a un bit, tale bit viene cancellato da AvailableUpdates.
- Se una di queste operazioni ha esito negativo, viene registrato un evento e l'operazione viene ritentata alla successiva esecuzione dell'attività pianificata.
- Il 0x4000 bit è un modificatore e non viene cancellato. Un valore finale di AvailableUpdates pari a 0x4000 indica il completamento corretto di tutte le azioni di aggiornamento applicabili.
- Gli eventi 1032, 1795, 1796, 1802 in genere indicano limitazioni del firmware o della piattaforma.
- L'evento 1803 indica la KEK OEM firmata da PK mancante.
Procedure di bonifica
In questa sezione vengono fornite procedure dettagliate per risolvere problemi specifici di avvio protetto. Ogni procedura è finalizzata a una condizione ben definita e deve essere seguita solo dopo che la diagnosi iniziale conferma che il problema si applica. Usare 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 in modo generale o preventivo.
Abilitazione dell'avvio protetto nel firmware
Se l'avvio protetto è disabilitato nel firmware di un dispositivo, vedi Windows 11 e avvio protetto per informazioni dettagliate sull'abilitazione dell'avvio protetto.
Attività pianificata di avvio protetto disabilitata o eliminata
L'attività pianificata Secure-Boot-Update è necessaria a Windows per applicare gli aggiornamenti del certificato di avvio protetto. Se l'attività è disabilitata o mancante, la manutenzione del certificato di avvio protetto non progredisce.
Dettagli attività
| Nome attività | Secure-Boot-Update |
|---|---|
| Percorso attività | \Microsoft\Windows\PI\ |
| Percorso completo | \Microsoft\Windows\PI\Secure-Boot-Update |
| Funziona come | SYSTEM (Sistema locale) |
| Trigger | All'avvio e ogni 12 ore |
| Stato obbligatorio | Attivato |
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. |
| Condividi | L'attività esiste ma deve essere abilitata. |
| Errore / Non trovato | L'attività è mancante 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 esaminarlo e adattarlo al proprio ambiente.
Esempio:
Nota
.\Enable-SecureBootUpdateTask.ps1 -Silenzioso
Esecuzione di linee guida
- Se vedi Accesso negato, esegui nuovamente PowerShell come amministratore.
- Se lo script non viene eseguito a causa dei criteri di esecuzione, usare un bypass dell'ambito del processo:
Nota
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass