MENU
  1. Início
  2. Windows
  3. Windows10
  4. Erro “Event 1796 – TPM‑WMI” após KB5058379 no Windows 10: causas e 6 soluções práticas

Erro “Event 1796 – TPM‑WMI” após KB5058379 no Windows 10: causas e 6 soluções práticas

Windows10

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.

Índice

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

  1. Abra o Event Viewer (eventvwr.msc) e navegue até Windows Logs ► System.
  2. Filtre por Event ID 1796 ou TPM‑WMI.
  3. 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

AbordagemResultadoNota
Desinstalar KB5058379, KB5061768 e KB5060533Erro deixa de aparecerPerde 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 sucessoTestado em ASUS Z170 + i7‑6700K; pode exigir repetição pós‑update futuro.
Desactivar apenas VT‑dInconsistenteAlguns chipsets H‑series permanecem afectados.
Limpar/reinicializar TPMRaramente útilRisco de perda de chaves BitLocker; backup primeiro.
Alternar Secure Boot (off → on)TemporárioErro regressa após reinstalar CU.
Ferramentas WU Troubleshooter, sfc, dismNenhum efeitoProblema está no firmware, não nos ficheiros de sistema.

Passo‑a‑passo BIOS tweak (detalhado)

  1. Backup: exporte as chaves BitLocker (manage‑bde –protectors –get C:) e guarde num USB.
  2. No Settings ► Update & Security ► Windows Update ► Update History, clique em Uninstall Updates.
  3. Remova KB5060533 (se presente) e KB5058379; reinicie.
  4. Entre na BIOS (F2/Del) e vá a Advanced ► CPU Configuration (menus variam):
  5. Desactive Intel Virtualization Technology, VT‑d, Software Guard Extension, Execute Disable Bit, TXT.
  6. Mantenha TPM e Secure Boot em Enabled.
  7. Grave as definições e volte ao Windows.
  8. Faça Check for updates; instale a CU de Junho ou posterior.
  9. Verifique o Event Viewer; o 1796 deve desaparecer.
  10. 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

  1. Entenda o risco: se não há requisitos de certificação, o aviso pode ser ignorado até que a Microsoft publique correcção.
  2. Solução rápida: Desinstale a CU e pause updates por 35 dias (não exceder esse período).
  3. Solução intermédia: Siga o BIOS tweak; leva 10–15 minutos e mantém o sistema actualizado.
  4. 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.
  5. Backups: Antes de limpar TPM ou alterar Secure Boot, exporte chaves e faça imagem do sistema (Macrium, Veeam Agent).
  6. 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.

Windows10
Event 1796 KB5058379 Secure Boot TPM Windows 10
Índice