Errore TPM‑WMI 1796 dopo KB5058379 in Windows 10: cause e workaround BIOS

Subito dopo l’installazione dei cumulativi KB5058379, KB5060533 e KB5061768 per Windows 10 22H2 molti utenti trovano nel Visualizzatore eventi l’avviso TPM‑WMI – ID 1796 “Secure Boot update failed to update a Secure Boot variable – Access is denied”. Il bug non blocca l’avvio di Windows ma, finché persiste, genera un errore critico ad ogni boot. In questa guida analizziamo le cause, illustriamo un work‑around BIOS già testato e diamo indicazioni pratiche per amministratori e utenti avanzati.

Perché compare l’errore TPM‑WMI 1796 dopo KB5058379

Il cumulativo KB5058379 (e i suoi successori) contiene un aggiornamento dei database Secure Boot Allowed (DB) e Disallowed (DBX). Durante l’installazione Windows tenta di scrivere nuove variabili UEFI nella NVRAM del firmware:

• SecureBoot-Policy – aggiorna la politica di avvio sicuro;
• {d719b2cb‑3d3a‑4596‑a3bc‑de04c45bd9d4} – GUID usato per DB/DBX.

In presenza di alcune estensioni di virtualizzazione e sicurezza VT‑x, VT‑d, SGX, XD o TXT, il firmware di alcuni sistemi rifiuta la scrittura e restituisce “Access is denied”. Windows intercetta l’errore tramite il provider WMI Win32_Tpm e lo registra con ID 1796.

Analisi tecnica dettagliata

Il problema non riguarda il modulo TPM 2.0 in sé: la chiave EK (Endorsement Key) e le PCR (Platform Configuration Registers) restano intatte. Il conflitto nasce a livello di firmware UEFI.

1. Fase di installazione
   • Windows crea i nuovi blob DB/DBX e li mette in coda per l’apply al riavvio.
   • Il servizio SecureBoot-Update segnala un cambiamento pending.
2. Fase di riavvio
   • Il firmware entra in modalità capsule update e tenta di flashare le variabili.
   • Se il BIOS ha Intel VT d Remapping o funzioni SGX abilitate, la chiamata SetVariable() fallisce per conflitto di protezione memoria.
   • Il firmware restituisce EFISECURITYVIOLATION (0x26).
   • Windows registra l’evento 1796 ma completa comunque il boot.

La scomparsa dell’errore dopo la disinstallazione del cumulativo conferma che il driver UEFI non raggiunge più il punto critico.

Impatto sui sistemi Windows 10 22H2

Finora sono stati colpiti soprattutto notebook e desktop con chipset Intel serie 300/400 e UEFI basati su AMI o Insyde. A livello aziendale questo si traduce in:

• Log storm: i sistemi di monitoraggio SIEM segnalano centinaia di “critical boot error”, complicando la triage vera.
• Audit compliance: alcune policy richiedono zero errori di Secure Boot in produzione.
• BitLocker: benché il TPM non venga azzerato, gli amministratori temono falsi positivi che portino alla richiesta di chiavi di ripristino agli utenti finali.

Soluzioni testate finora

Approccio	Esito
Installare patch correttive (KB5061768 OOB)	Inefficace: l’evento 1796 permane
Strumenti Windows (Troubleshooter, sfc /scannow, DISM, TPM.msc –> Clear TPM)	Nessun miglioramento; rischio perdita chiavi BitLocker
Disabilitare/r abilitare Secure Boot	Generalmente non risolve
Disattivare solo VT‑x o VT‑d	Spesso insufficiente
Disinstallare il cumulativo	Sopprime l’errore ma espone a vulnerabilità

Work‑around BIOS passo‑passo

1. Disinstallare da Impostazioni > Windows Update > Cronologia aggiornamenti i pacchetti KB5060533 e KB5058379 (se presente).
2. Riavviare ed entrare nel BIOS/UEFI (F2, Del o tasto dedicato).
3. Disabilitare temporaneamente:
   • Intel Virtualization Technology (VT‑x)
   • Intel VT‑d
   • SGX
   • XD / NX Bit
   Lasciare Secure Boot abilitato; se disponibile, selezionare Load Default Secure Boot Keys.
4. Salvare, uscire e avviare Windows.
5. In Windows Update cercare nuovi aggiornamenti e installare il cumulativo più recente (al momento KB5061768).
6. Riavviare nuovamente, rientrare nel BIOS e riattivare le opzioni disabilitate al punto 3.

L’evento 1796 non ricompare neppure nei riavvii successivi. Se in futuro un nuovo cumulativo r introducesse il problema sarà sufficiente ripetere l’intera sequenza.

Script PowerShell per individuare rapidamente l’evento

In scenari enterprise può essere utile uno script di scansione remoto:

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-TPM-WMI/Operational'
    Id      = 1796
    StartTime = (Get-Date).AddDays(-7)
} | Select-Object TimeCreated, MachineName, Message

Eseguendolo con Invoke-Command su una collection di PC si ottiene la lista dei client da sottoporre al work‑around.

Best practice prima dell’intervento

• Eseguire una immagine di sistema completa o almeno il backup della partizione di sistema.
• Esportare e archiviare le chiavi di ripristino BitLocker.
• Verificare che la console di gestione (Intune, MEMCM) consenta il rollback degli aggiornamenti se qualcosa va storto.
• Documentare le impostazioni originali di BIOS/UEFI in modo da poterle ripristinare velocemente.

Gestione post‑14 ottobre 2025 ed Extended Security Updates

Il ciclo di vita di Windows 10 termina il 14 ottobre 2025. Dopo tale data soltanto i clienti che aderiranno al programma Extended Security Updates (ESU) riceveranno patch critiche. Se l’errore 1796 dovesse ripresentarsi in ambito ESU, la correzione potrebbe richiedere più tempo o non arrivare affatto. Valutare quindi:

• Migrazione anticipata a Windows 11 ove possibile.
• Testing sistematico dei cumulativi ESU in ambiente staging.
• Contratti di supporto OEM/ODM per firmware personalizzati.

Cosa aspettarsi da Microsoft

Al momento non esiste un fix ufficiale nel catalogo. Secondo fonti interne, il team Secure Boot sta replicando il bug con firmware che implementano protezioni estese di memoria DMA durante la fase capsule. Nel frattempo:

1. Inoltrate feedback attraverso l’app Feedback Hub includendo i log %SystemRoot%\Logs\CBS e l’esportazione del canale TPM‑WMI/Operational.
2. Monitorate le Known Issues dei futuri “Patch Tuesday”; se appare la dicitura “Secure Boot variable update fails”, installate immediatamente la patch e verificate.

FAQ veloci

Il TPM deve essere azzerato? (Clear TPM)

No. La procedura “Clear TPM” non influisce sul bug ed espone al rischio di perdita chiavi BitLocker.
Posso ignorare l’evento 1796?

Sì, l’evento non degrada le prestazioni. Tuttavia alcuni strumenti di compliance potrebbero classificare l’errore come vulnerabilità di Secure Boot.
Il problema riguarda Windows 11?

Al momento non sono stati registrati casi su Windows 11 23H2, probabilmente perché i database DB/DBX sono già aggiornati nelle build più recenti o per differenze nella gestione capsule UEFI.

Conclusioni

L’evento TPM‑WMI 1796 dopo l’installazione di KB5058379 e successivi è causato da un conflitto fra l’aggiornamento delle variabili Secure Boot e alcune funzioni di virtualizzazione Intel. Finché Microsoft non rilascerà una patch definitiva, il work‑around che prevede la disattivazione temporanea di VT‑x, VT‑d, SGX e XD nel BIOS resta la soluzione più efficace per eliminare l’errore senza rinunciare agli aggiornamenti di sicurezza.