Microsoft ha ampliato le linee guida su un bug di arresto di Windows innescato dagli aggiornamenti di gennaio 2026, confermando che colpisce più sistemi di quanto inizialmente segnalato. Secondo BleepingComputer, il problema può causare il riavvio di alcuni dispositivi anziché lo spegnimento o l'ibernazione quando sono abilitate specifiche configurazioni di sicurezza.
Per la maggior parte degli utenti, il sintomo è simile a "il mio PC non si spegne". Per i team IT, il vero problema è la compatibilità tra le funzionalità di sicurezza che si basano sulla virtualizzazione e il percorso di aggiornamento.
Cosa sta succedendo sui computer interessati
BleepingComputer segnala che dopo l'installazione di determinati aggiornamenti, alcuni PC compatibili con Secure Launch e con Virtual Secure Mode (VSM) abilitata non riescono a spegnersi o a entrare in ibernazione; il sistema si riavvia.
Questo non è solo fastidioso. Può:
- Interrompere le finestre di patching e manutenzione
- Confondere le politiche di gestione dell'alimentazione
- Aumento dell'usura (riavvii inaspettati)
- Lasciare i sistemi in stati inaspettati per i flussi di lavoro di crittografia e conformità
Quali versioni e aggiornamenti di Windows sono coinvolti
Per BleepingComputer:
- Sono stati identificati come interessati i sistemi Windows 11 23H2 con KB5073455 installato (e System Guard Secure Launch abilitato).
- Poco dopo, Microsoft ha rilasciato aggiornamenti fuori banda (OOB) per risolvere quel caso specifico.
- Successivamente Microsoft ha aggiornato la sua dashboard per confermare un comportamento simile su Windows 10 22H2 e alcune versioni di Windows 10 Enterprise LTSC quando VSM è abilitato dopo l'installazione di aggiornamenti, tra cui KB5073724 e KB5078131.
Cos'è VSM e perché è nella storia
VSM (Virtual Secure Mode) utilizza la virtualizzazione hardware per creare una regione isolata del "kernel sicuro", proteggendo risorse sensibili come:
- Credenziali
- Chiavi di crittografia
- token di sicurezza
È alla base di funzionalità quali Credential Guard e Hypervisor-Protected Code Integrity.
Poiché VSM modifica il modo in cui il sistema operativo interagisce con i componenti di basso livello (avvio, isolamento della memoria, hypervisor), i bug nel percorso di aggiornamento possono presentarsi specificamente su macchine in cui queste protezioni sono abilitate.
La soluzione alternativa consigliata da Microsoft
BleepingComputer segnala che Microsoft ha consigliato ai clienti interessati di arrestare manualmente il sistema utilizzando:
arresto /s /t 0
Ciò impone un percorso di comando di arresto diretto e può essere utile finché non verrà fornita una correzione tramite un futuro aggiornamento.
Per le organizzazioni, questa soluzione alternativa può essere pianificata o implementata tramite strumenti di gestione, ma è pur sempre un rimedio temporaneo.
Cosa dovrebbero fare ora i team IT
- Controlla quali flotte hanno Secure Launch o VSM abilitato(potrebbero essere limitati a determinati modelli o immagini aziendali).
- Conferma l'aggiornamento KB installatoe confrontarle con le note di stato della versione di Microsoft.
- Distribuire gli aggiornamenti OOB ove applicabilee convalidare il comportamento di spegnimento/ibernazione.
- Comunicare le istruzioni per l'utente(inclusa la soluzione alternativa della riga di comando) per ridurre il rumore dell'helpdesk.
In conclusione
Il bug di arresto di Windows ci ricorda che funzionalità di sicurezza più avanzate possono introdurre interazioni più complesse con gli aggiornamenti. Se i vostri dispositivi utilizzano Secure Launch o VSM, monitorate attentamente gli avvisi di stato di rilascio di Microsoft e utilizzate la soluzione alternativa del comando di arresto finché non verrà rilasciata la correzione definitiva.
Italiano
English
العربية
Čeština
Dansk
Nederlands
Eesti
Suomi
Français
Deutsch
Ελληνικά
Magyar
日本語
한국어
Latviešu valoda
Lietuvių kalba
Norsk bokmål
Polski
Português
Română
Русский
Slovenčina
Slovenščina
Español
Svenska
Türkçe