Windows 10 si blocca dopo 5 minuti: il caso legato a Secure Boot

Un blocco totale del sistema Windows 10 che si manifesta sempre allo stesso istante dopo l’avvio porta quasi inevitabilmente a sospettare un guasto hardware. Alimentazione, surriscaldamento, memoria difettosa, problemi al sottosistema grafico: sono le prime ipotesi che vengono in mente quando Windows 10 “si congela” senza schermate blu, senza errori evidenti e senza alcuna possibilità di recupero. Eppure, su alcune piattaforme datate ancora perfettamente funzionanti, la causa può nascondersi in un componente molto meno intuitivo: una attività pianificata integrata nel sistema operativo.

Diversi utenti di Windows 10 hanno segnalato il freeze dopo 5 minuti di avvio del sistema operativo. La cosa curiosa è che il problema si presenta su vecchie macchine con chip TPM 1.2 che, sulla carta non possono aggiornare a Windows 11, compresi sistemi Windows 10 LTSC installati proprio per estendere il supporto del sistema operativo oltre la data di End of Life fissata da Microsoft per le edizioni Home e Pro.

La vicenda riguarda un PC Dell XPS 2720 All-in-One del 2013 basato su architettura Haswell, equipaggiato con chip TPM 1.2 e Windows 10 LTSC 21H2 completamente aggiornato. Dopo settimane di analisi, test e reinstallazioni, l’origine di un freeze riproducibile esattamente cinque minuti dopo ogni avvio è stata individuata nell’attività pianificata Secure-Boot-Update, presente nella cartella Microsoft\Windows\PI. Il caso merita attenzione perché mette in evidenza una possibile incompatibilità tra meccanismi moderni di manutenzione di Secure Boot e hardware progettato oltre dieci anni fa.

Blocco di Windows 10 dopo 5 minuti: un sintomo che sembra hardware ma non lo è

Il comportamento osservato risulta, di primo acchito, estremamente insolito. Il sistema Windows 10 rimane stabile durante la fase di avvio e nei primi minuti di utilizzo, per poi bloccarsi completamente dopo circa 5 minuti. L’immagine sul monitor rimane congelata sull’ultimo frame visualizzato e anche mouse e tastiera cessano immediatamente di rispondere.

Il registro eventi riporta soltanto un successivo Kernel-Power 41, generato dallo spegnimento forzato tramite pressione prolungata del pulsante di alimentazione. Poco prima del blocco compare l’evento TPM-WMI 1026 con il messaggio relativo all’impossibilità di effettuare l’auto provisioning del modulo TPM.

Il dettaglio più interessante arriva dall’uso della modalità provvisoria: avviando Windows 10 in questa modalità, il sistema rimane funzionante senza alcun problema.

Il ruolo dell’attività Secure-Boot-Update

L’attività responsabile del blocco anomalo di Windows 10 risulta essere Microsoft\Windows\PI\Secure-Boot-Update, operazione impostata per l’esecuzione automatica (tramite Utilità di pianificazione Windows) proprio 5 minuti dopo l’avvio del sistema.

Microsoft utilizza questa attività per gestire operazioni legate all’aggiornamento delle chiavi Secure Boot e alla manutenzione dei certificati UEFI: ne abbiamo parlato spesso in altri nostri articoli.

La presenza dell’attività pianificata Microsoft\Windows\PI\Secure-Boot-Update è infatti diventata ancora più importante con il programma di aggiornamento dei certificati Secure Boot in vista della scadenza delle chiavi storiche utilizzate dai sistemi Windows.

In condizioni normali l’attività completa il proprio lavoro in pochi secondi; su sistemi più recenti dotati di chip TPM 2.0 non risultano segnalazioni di problemi analoghi. La situazione sembra cambiare però quando l’hardware monta ancora un modulo TPM conforme alle specifiche 1.2.

Perché TPM 1.2 può rappresentare un problema

Il TPM 1.2 nasce in un’epoca precedente all’introduzione di numerose funzioni oggi considerate standard. Le differenze rispetto a TPM 2.0 non riguardano soltanto aspetti di sicurezza ma anche algoritmi crittografici supportati, modalità di gestione delle policy e meccanismi di misurazione dell’integrità del sistema.

TPM 1.2 utilizza principalmente SHA-1 come algoritmo di hashing nativo, mentre TPM 2.0 supporta in modo esteso SHA-256 e altri algoritmi moderni. Diverse procedure adottate dalle versioni più recenti di Windows per Secure Boot e attestazione dell’avvio si basano proprio su queste funzionalità avanzate.

L’ipotesi è che Secure-Boot-Update tenti di eseguire una operazione TPM incompatibile con il firmware del chip installato.

Potrebbe trattarsi di una misurazione PCR (Platform Configuration Register) basata sull’algoritmo crittografico SHA-256, di una verifica delle chiavi di sicurezza UEFI utilizzate durante l’avvio del sistema oppure di una procedura di configurazione iniziale (provisioning) sviluppata originariamente per TPM 2.0. Se l’errore non è gestito correttamente, il kernel può restare in attesa di una risposta che non arriverà mai, causando una condizione simile a un deadlock, cioè un blocco permanente del processo.

Microsoft non ha pubblicato, almeno al momento, documentazione tecnica che confermi ufficialmente questo specifico scenario: si tratta di una mera deduzione supportata dai sintomi osservati e dalla riproducibilità del problema.

La soluzione che ha eliminato il blocco di Windows 10

Dopo aver individuato la causa, la correzione si è rivelata sorprendentemente semplice. È bastato disabilitare l’attività Secure-Boot-Update per impedire l’esecuzione della procedura responsabile del blocco. Di seguito il comando PowerShell utilizzabile allo scopo:

Disable-ScheduledTask -TaskPath "\Microsoft\Windows\PI\" -TaskName "Secure-Boot-Update"

Una volta disattivata l’attività, il sistema torna stabile, con tutti gli altri servizi Windows attivi. Nessun freeze, nessun evento anomalo e nessuna necessità di ulteriori modifiche.

Come ulteriore misura preventiva si può temporaneamente disattivare il supporto TPM a livello di BIOS in modo da mantenere il sistema stabile anche dopo reinstallazioni del sistema operativo.

Chi utilizza funzionalità di sicurezza moderne dovrebbe però valutare attentamente questa opzione. La disattivazione del TPM impedisce infatti l’uso di BitLocker nella configurazione standard, limita Windows Hello, rende inutilizzabili funzionalità come Credential Guard.

Un caso che potrebbe interessare molti sistemi datati

La parte più insidiosa della vicenda è che il problema imita perfettamente un guasto hardware. L’assenza di schermate blu e messaggi diagnostici porta facilmente a sostituire componenti perfettamente funzionanti o addirittura a dismettere l’intero computer.

La coincidenza temporale dei 5 minuti induce inoltre a cercare la causa nei profili energetici, nelle temperature o nei driver grafici. In realtà il timer corrisponde esattamente al ritardo configurato per l’esecuzione dell’attività Secure-Boot-Update.

Per chi gestisce workstation datate, soprattutto sistemi Haswell, Ivy Bridge e piattaforme della stessa generazione ancora con chip TPM 1.2, vale la pena verificare con attenzione il comportamento della macchina, senza trarre conclusioni affrettate.

Resta da capire se Microsoft interverrà per risolvere il problema (Windows 10 è un sistema operativo pienamente supportato attraverso il programma ESU, Extended Security Updates; per non parlare delle edizioni LTSC) e se introdurrà in futuro una gestione più robusta degli errori per questi scenari.