Quando un PC con Windows 10 si blocca sempre nello stesso preciso momento dopo l’accensione, l’istinto porta dritto verso un guasto fisico. Alimentatore, calore eccessivo, memoria difettosa, scheda grafica capricciosa. Eppure, su alcune macchine datate ma ancora perfettamente in salute, la spiegazione si nasconde altrove, in un punto davvero poco intuitivo: una semplice attività pianificata dentro il sistema operativo. Diversi utenti hanno raccontato la stessa storia, ovvero un freeze totale dopo 5 minuti dall’avvio, senza schermate blu e senza alcun messaggio d’errore che aiuti a capire cosa stia succedendo.
La cosa curiosa è che il fenomeno colpisce vecchi computer con chip TPM 1.2, quelli che sulla carta non possono nemmeno passare a Windows 11. Tra questi ci sono anche i sistemi Windows 10 LTSC, installati apposta per allungare il supporto oltre la data di fine vita decisa da Microsoft per le edizioni Home e Pro. Il caso emblematico riguarda un Dell XPS 2720 All in One del 2013, architettura Haswell, con TPM 1.2 e Windows 10 LTSC 21H2 aggiornato in ogni sua parte. Dopo settimane di prove e reinstallazioni, il colpevole è saltato fuori: l’attività pianificata Secure Boot Update, nascosta nella cartella MicrosoftWindowsPI.
Un blocco che sembra hardware ma non lo è
Il comportamento, va detto, lascia spiazzati. Il sistema parte tranquillo, regge bene i primi minuti, poi di colpo si pianta del tutto. L’immagine sullo schermo resta congelata sull’ultimo fotogramma e anche mouse e tastiera smettono di rispondere all’istante. Nel registro eventi compare solo un Kernel Power 41, che però è semplicemente la conseguenza dello spegnimento forzato col pulsante tenuto premuto. Poco prima del blocco spunta invece l’evento TPM WMI 1026, con un messaggio sull’impossibilità di completare l’auto provisioning del modulo TPM.
Il dettaglio che cambia tutto arriva dalla modalità provvisoria. Avviando Windows 10 così, la macchina funziona senza un singolo intoppo. Segno evidente che la radice del problema non sta nei circuiti ma nel software.
Il ruolo di Secure Boot Update e perché il TPM 1.2 frena
L’attività incriminata è MicrosoftWindowsPISecure Boot Update, programmata per partire automaticamente proprio 5 minuti dopo l’avvio. Microsoft la usa per gestire l’aggiornamento delle chiavi Secure Boot e la manutenzione dei certificati UEFI, una faccenda diventata più delicata da quando è partito il programma di rinnovo dei certificati in vista della scadenza delle chiavi storiche.
Su una macchina normale questa operazione dura pochi secondi. Sui sistemi più recenti con chip TPM 2.0 non risultano segnalazioni. Le cose si complicano solo quando l’hardware monta ancora un modulo conforme alle specifiche 1.2. Il motivo è tecnico ma comprensibile. Il TPM 1.2 nasce in un’altra epoca e usa principalmente SHA 1 come algoritmo di hashing, mentre il 2.0 supporta in modo esteso SHA 256 e algoritmi più moderni, su cui si appoggiano molte procedure recenti per Secure Boot e attestazione dell’avvio.
L’ipotesi più solida è che Secure Boot Update provi a eseguire un’operazione che il vecchio chip non sa gestire. Magari una misurazione PCR basata su SHA 256, una verifica delle chiavi UEFI o una procedura di provisioning pensata per il 2.0. Se l’errore non viene gestito bene, il kernel resta in attesa di una risposta che non arriverà mai, in una condizione simile a un deadlock. Microsoft, almeno per ora, non ha confermato ufficialmente lo scenario: si tratta di una deduzione basata sui sintomi e sulla riproducibilità del fenomeno.
La soluzione che spegne il blocco
Trovata la causa, la correzione è quasi banale. Basta disattivare l’attività con un comando PowerShell:
Disable-ScheduledTask -TaskPath “MicrosoftWindowsPI” -TaskName “Secure-Boot-Update”
Disabilitata l’operazione, il sistema torna stabile, tutti gli altri servizi restano attivi e il freeze sparisce. Come misura extra si può anche disattivare temporaneamente il supporto TPM nel BIOS, così da reggere anche dopo eventuali reinstallazioni. Attenzione però: chi usa funzioni di sicurezza moderne dovrebbe pensarci bene, perché spegnere il TPM blocca BitLocker nella configurazione standard, limita Windows Hello e rende inutilizzabile Credential Guard.
La parte più insidiosa è proprio questa, ovvero che il difetto imita alla perfezione un guasto fisico, portando a sostituire pezzi sanissimi o addirittura a buttare via l’intero PC. La coincidenza dei 5 minuti spinge poi a cercare colpe nei profili energetici, nelle temperature o nei driver. In realtà quel timer coincide esattamente col ritardo impostato per l’attività. Per chi gestisce workstation datate, in particolare piattaforme Haswell, Ivy Bridge e generazioni simili ancora con TPM 1.2, conviene verificare il comportamento con calma, senza saltare a conclusioni affrettate.
Windows 10 resta peraltro pienamente supportato tramite il programma ESU, gli Extended Security Updates, oltre alle edizioni LTSC. Da capire se Microsoft deciderà di intervenire e se introdurrà una gestione più robusta degli errori per questo tipo di scenari.