Resumo: Depois de instalar a actualização cumulativa KB5058379 (Windows 10 22H2, build 19045.5854) — e, em alguns cenários, as posteriores KB5061768 e KB5060533 — muitos utilizadores depararam‑se, em Event Viewer ► System, com o Event 1796 – TPM‑WMI:
The Secure Boot update failed to update a Secure Boot variable – Access is denied.
O aviso surge a cada arranque, mesmo em máquinas com TPM 2.0 e Secure Boot activos; é benigno na maioria dos casos, mas indica que a base de dados de certificados (DB/DBX) não foi escrita com sucesso, deixando a componente de arranque potencialmente desprotegida.
Por que o Event 1796 aparece?
Os pacotes de Junho 2025 trazem um conjunto de novos certificados de revogação UEFI destinados a bloquear gestores de arranque comprometidos. No entanto, a escrita dessas variáveis é feita no armazenamento NVRAM do firmware — um espaço que pode ser bloqueado por:
- Definições de virtualização/segurança (Intel VT‑x/VT‑d, SGX, XD‑bit, TXT, AMD‑V, SVM).
- Configurações de Secure Device em BIOS de fabricantes como ASUS, MSI e Gigabyte, que impedem alterações não autorizadas ao Secure Boot.
- Falhas de integração entre chipset, firmware e o driver TPM‑WMI introduzido na CU.
Impacto real
Para utilizadores domésticos, o erro é sobretudo “visual”. O Windows arranca, o BitLocker continua a funcionar e nenhum crash é provocado. Ainda assim, em ambientes regulados (PCI‑DSS, ISO 27001, serviços financeiros), a não actualização das listas DB/DBX pode violar requisitos de conformidade.
Como diagnosticar
- Abra o Event Viewer (eventvwr.msc) e navegue até Windows Logs ► System.
- Filtre por Event ID 1796 ou TPM‑WMI.
- Clique duas vezes no evento para confirmar se a origem é “The Secure Boot update failed …”.
Opcionalmente, verifique se o banco de chaves foi ou não actualizado:
Confirm-SecureBootUEFI
Get-SecureBootPolicy | Format-List Path, LastModified, Version
Se as datas de LastModified
não coincidirem com o lançamento da CU, a actualização falhou.
Causas técnicas em detalhe
1. Match entre Hashes Quando a Microsoft emite um novo certificado de revogação, o módulo Secure Boot Variable Update Engine compara o hash da chave antiga contra o da versão distribuída. Se a operação falhar no estágio “SetVariable()”, o Windows gera o 1796.
2. Bloqueio de Região TPM Sistemas que activam Platform Trust Technology (PTT) ou fTPM sob determinadas políticas de BIOS podem marcar a área como “Runtime‑locked” logo após POST, indisponibilizando a escrita pelo driver.
3. Concorrência de Drivers Alguns antivírus empresariais injectam filtros no stack de inicialização (SecDog, Kaspersky EDR, etc.) e prendem o handle do TPM, devolvendo “Access Denied”.
Soluções e workarounds
Abordagem | Resultado | Nota |
---|---|---|
Desinstalar KB5058379, KB5061768 e KB5060533 | Erro deixa de aparecer | Perde actualizações de segurança; não recomendado por mais de 30 dias. |
BIOS tweak completo 1. Desinstalar CU 2. Desactivar VT‑x, VT‑d, SGX, XD‑bit, TXT (manter Secure Boot) 3. Reinstalar CU 4. Re‑activar opções | Alto sucesso | Testado em ASUS Z170 + i7‑6700K; pode exigir repetição pós‑update futuro. |
Desactivar apenas VT‑d | Inconsistente | Alguns chipsets H‑series permanecem afectados. |
Limpar/reinicializar TPM | Raramente útil | Risco de perda de chaves BitLocker; backup primeiro. |
Alternar Secure Boot (off → on) | Temporário | Erro regressa após reinstalar CU. |
Ferramentas WU Troubleshooter, sfc, dism | Nenhum efeito | Problema está no firmware, não nos ficheiros de sistema. |
Passo‑a‑passo BIOS tweak (detalhado)
- Backup: exporte as chaves BitLocker (manage‑bde –protectors –get C:) e guarde num USB.
- No Settings ► Update & Security ► Windows Update ► Update History, clique em Uninstall Updates.
- Remova KB5060533 (se presente) e KB5058379; reinicie.
- Entre na BIOS (F2/Del) e vá a Advanced ► CPU Configuration (menus variam):
- Desactive Intel Virtualization Technology, VT‑d, Software Guard Extension, Execute Disable Bit, TXT.
- Mantenha TPM e Secure Boot em Enabled.
- Grave as definições e volte ao Windows.
- Faça Check for updates; instale a CU de Junho ou posterior.
- Verifique o Event Viewer; o 1796 deve desaparecer.
- Volte à BIOS e re‑active gradualmente as opções desligadas, testando a cada reinício.
Boas práticas antes de mexer no firmware
- Actualizar primeiro a BIOS/UEFI para a versão mais recente do fabricante.
- Manter cópia de segurança da partição EFI System (ESP) (bcdedit /export C:\EFI‑backup.bcd).
- Documentar cada valor alterado (foto do telemóvel ou captura via ASUS EZ Flash, MSI Click BIOS, etc.).
- Executar uma verificação S.M.A.R.T. antes de operações prolongadas, para evitar downtime inesperado.
Perspectiva oficial Microsoft (Julho 2025)
Até à data, não existe KB correctiva que elimine definitivamente o Event 1796. Engenheiros no canal @WindowsUpdate do GitHub confirmaram que:
- O “Access Denied” é gerado pelo firmware, não pelo Windows.
- A incidência afecta sobretudo chipsets Intel 100–300 Series e AMD A320/B350 anteriores a 2019.
- Um fix está em “investigação” mas sem ETA.
Moderadores nos fóruns sugerem abrir Feedback Hub ► Security and Privacy ► Secure Boot com logs anexos (PowerShell: Get-WinEvent -FilterHashtable @{LogName='System'; ID=1796} | Export‑Csv C:\tpm1796.csv
).
Recomendações práticas para utilizadores lusófonos
- Entenda o risco: se não há requisitos de certificação, o aviso pode ser ignorado até que a Microsoft publique correcção.
- Solução rápida: Desinstale a CU e pause updates por 35 dias (não exceder esse período).
- Solução intermédia: Siga o BIOS tweak; leva 10–15 minutos e mantém o sistema actualizado.
- Ambientes críticos: Considere migrar para Windows 11 (build 22631+) — não afectado até ao momento — ou aderir ao programa Extended Security Updates (pago) pós‑EOL.
- Backups: Antes de limpar TPM ou alterar Secure Boot, exporte chaves e faça imagem do sistema (Macrium, Veeam Agent).
- Monitorize: Nos Patch Tuesday seguintes, confirme se o erro regressa; se sim, repita o procedimento.
FAQ (Perguntas frequentes)
O Event 1796 danifica o arranque?
Não. Caso o Secure Boot não consiga actualizar DB/DBX, o sistema usa a versão anterior das chaves e continua a arrancar.
Limpar o TPM faz diferença?
Em 90 % dos testes publicados nos fóruns, não. O problema reside em variáveis da UEFI, não no TPM NVStorage.
Posso simplesmente ignorar o alerta?
Sim, se o computador for pessoal e não existir exigência de auditoria. Para empresas, recomenda‑se ao menos registar a excepção.
O Windows 11 é imune?
Até ao Patch Tuesday de Junho 2025, não há relatos do Event 1796 no Windows 11. Todavia, a Microsoft pode portar o mesmo código para builds futuras; mantenha‑se atento.
Conclusão
O Event 1796 após a instalação da KB5058379 (e sucessoras) tornou‑se um dos erros mais comentados em comunidades de administradores de sistemas lusófonos em 2025. Embora não quebre o funcionamento do PC, revela uma lacuna na cadeia de confiança do Secure Boot. A solução mais eficaz — desligar temporariamente as extensões de virtualização na BIOS e reinstalar a CU — é relativamente simples, desde que o utilizador adote boas práticas de backup. Até que a Microsoft forneça um patch definitivo, cabe a cada um balancear segurança, tempo de manutenção e conformidade regulatória.