MENU
  1. Inicio
  2. Windows
  3. Windows10
  4. Cómo eliminar el error TPM‑WMI 1796 tras instalar KB5058379 en Windows 10 22H2

Cómo eliminar el error TPM‑WMI 1796 tras instalar KB5058379 en Windows 10 22H2

Windows10

Tras las actualizaciones de mayo 2025 numerosos equipos con Windows 10 22H2 registran en cada arranque el evento TPM‑WMI 1796 “The Secure Boot update failed to update a Secure Boot variable with error Access is denied.”. Aunque no afecta al funcionamiento cotidiano, provoca alertas de BitLocker y confusión en entornos auditados. Esta guía explica por qué ocurre, cómo detenerlo y qué buenas prácticas seguir mientras Microsoft publica una corrección definitiva.

Índice

Contexto y alcance del problema

Los parches acumulativos KB5058379 (Patch Tuesday de mayo 2025) y sus sucesores KB5060533 y KB5061768 incorporan nuevas firmas de Secure Boot. Windows intenta grabarlas en las variables DB/DBX a través del Trusted Platform Module (TPM). En ciertos equipos el firmware UEFI bloquea la operación porque detecta funciones de virtualización —Intel VT‑x/VT‑d, SGX o Execute Disable Bit— que introducen requisitos adicionales de permisos. El sistema traduce ese bloqueo en un Access is denied y lo registra como evento 1796.

Síntomas visibles

  • Evento 1796 en Visor de eventos → Aplicación y servicios → Microsoft → Windows → TPM‑WMI cada vez que arranca o reinicia.
  • Arranque y operación normales en la mayoría de los casos.
  • En algunos equipos surge pantalla de recuperación de BitLocker solicitando la clave de 48 dígitos.
  • Sin pérdida de rendimiento ni errores de aplicaciones.

Diagnóstico rápido

  1. Abra Visor de eventos y filtre por ID 1796. Si solo aparece tras la instalación del CU de mayo 2025 o posterior, está afectado.
  2. Confirme la versión de Windows con winver.exe —debe mostrar 19045.5854 o superior— y la lista de parches instalados con wmic qfe list brief /format:table.
  3. Revise en la UEFI que Secure Boot permanezca activado. Si Secure Boot está desactivado, el problema suele desaparecer, lo que confirma la causa.

Causa técnica detallada

Durante la fase de preparación, el instalador del CU almacena nuevas firmas de arranque en el directorio staging. En el primer reinicio el servicio Secure Boot Policy‑Manager invoca a la extensión WMI del TPM para escribir esas firmas en las variables de firmware. Cuando la lógica de seguridad de la plataforma detecta:

  • Extensiones de virtualización Intel VT‑x/VT‑d habilitadas.
  • Protecciones SGX o XD Bit activas.
  • Una política de arranque medido (Measured Boot) combinada con BitLocker.

…el firmware exige privilegios adicionales (SMM Supervisor Mode). El instalador carece de ellos durante el tramo WinPE del arranque, por lo que el comando SetFirmwareEnvironmentVariable falla con ERRORACCESSDENIED (0x5). Este error se propaga a WMI y finalmente al registro de eventos.

Soluciones comprobadas

A. Desinstalar el parche problemático

Ejecute:

wusa /uninstall /kb:5058379 /quiet /norestart

Tras reiniciar el evento 1796 desaparece. Sin embargo, el equipo queda desprotegido de las vulnerabilidades que el parche corrige y Windows intentará reinstalarlo. Solo recomendable como diagnóstico temporal.

B. Procedimiento “deshabilitar‑actualizar‑habilitar” (solución preferida)

FaseAcciónDetalles
1Desinstalar CUComprende KB5058379, KB5060533 o el que esté instalado. Reiniciar.
2Modificar UEFIMantenga Secure Boot en Enabled, pero ponga en Disabled: VT‑x, VT‑d, SGX, Execute Disable Bit.
Los nombres varían; consulte el manual.
3Reinstalar CUInicie Windows, deje que Windows Update instale de nuevo el CU más reciente. Reiniciar.
4VerificarEspere dos minutos tras el arranque y abra el Visor de eventos. No debe aparecer 1796.
5Restaurar UEFIEntre otra vez en la BIOS y reactive VT‑x, VT‑d, SGX y XD Bit.

Probado con placas ASUS Z series, HP OMEN/ENVY, Lenovo ThinkPad y Dell Latitude. Tras numerosos ciclos de apagado el error no regresa.

C. Intentos frecuentes que no funcionan

  • Limpiar TPM desde tpm.msc: borra claves de BitLocker sin resolver 1796.
  • Alternar Secure Boot Off → On o cambiar a Custom Keys.
  • Ejecutar el solucionador de Windows Update.
  • Actualizar in‑place a Windows 11 23H2: el instalador migra el firmware pero hereda el fallo.
  • Instalar solo el parche fuera de banda KB5061768: arregla el reinicio de LSASS pero no toca Secure Boot DB/DBX.

Recomendaciones prácticas

Evaluar la gravedad real

Event 1796 es informativo; no implica que el TPM esté dañado ni que Secure Boot deje de verificar la cadena de confianza. Si su organización no audita el registro y no usa BitLocker con arranque medido, puede ignorarlo hasta que Microsoft publique una solución.

Proteger la configuración antes de cambios en UEFI

  • Guarde las claves de recuperación de BitLocker (manage‑bde -protectors -get c:).
  • Tome fotografías o anote cada parámetro de la BIOS antes de alterarlo.
  • Si su equipo permite guardar un perfil de configuración UEFI en USB, hágalo.

Monitorizar tras cada Patch Tuesday

  1. El segundo martes de cada mes abra Configuración → Windows Update → Historial.
  2. Si hay nuevo CU, compruebe el visor de eventos después de reiniciar.
  3. Si reaparece el 1796, repita el procedimiento B. Normalmente basta con desactivar VT‑x/VT‑d, instalar y reactivar.

Evitar limpiezas innecesarias de TPM

Borrar el TPM provoca la pérdida de claves almacenadas (BitLocker, certificados EFS, credenciales de inicio de sesión FIDO2). Solo hágalo si dispone de copias y comprende cómo restaurarlas.

Scripts y herramientas auxiliares

PowerShell para detectar equipos afectados en red local


$Computers = Get‑ADComputer -Filter * | Select‑Object -Expand Name
$Report = foreach ($PC in $Computers) {
    try {
        $Evt = Get‑WinEvent -ComputerName $PC -LogName "Microsoft-Windows-TPM-WMI/Operational" -FilterXPath "*[System[(EventID=1796)]]" -MaxEvents 1 -ErrorAction Stop
        if ($Evt) {
            [PSCustomObject]@{
                Hostname = $PC
                TimeStamp = $Evt.TimeCreated
                PatchLevel = (Get‑HotFix -ComputerName $PC | Sort‑Object -Property InstalledOn -Descending | Select‑Object -First 1).HotFixID
            }
        }
    } catch {
        Write‑Verbose "No se pudo consultar $PC"
    }
}
$Report | Export‑Csv .\EquiposCon1796.csv -NoTypeInformation

Preguntas frecuentes

¿Puedo simplemente desactivar Secure Boot?

Sí, elimina el evento pero reduce la seguridad base contra malware de arranque y rompe la garantía de integridad de Windows 10. No recomendable salvo en entornos de laboratorio.

¿Afecta a AMD o a placas con firmware Insyde/Aptio V?

El patrón se observa sobre todo en chipsets Intel 300/400/500 con firmware AMI/Aptio, pero hay reportes aislados en AMD B550. El denominador común es la presencia de extensiones de virtualización y políticas de arranque medido.

¿Cuándo habrá un parche oficial?

Al cierre de junio 2025, Microsoft reconoce el problema en el portal Known Issues, indica que «se investiga» y sugiere “reiniciar el sistema tras la actualización”. No existe todavía hotfix ni fecha comprometida.

Conclusión

El evento 1796 es fruto de un choque entre la lógica de seguridad del firmware y la actualización de firmas Secure Boot incluidas en KB5058379 y acumulativos posteriores. Mientras llega un parche oficial, el método más sólido para mantener los parches sin la alerta consiste en:

  1. Desinstalar temporalmente el CU.
  2. Desactivar VT‑x/VT‑d, SGX y XD Bit.
  3. Reinstalar el CU.
  4. Reactivar las opciones.

Para la mayoría de usuarios domésticos el aviso puede ignorarse sin riesgo aparente; sin embargo, en entornos regulados o con BitLocker en modo medido conviene aplicar la mitigación para conservar un registro limpio y evitar solicitudes de recuperación.

Windows10
Secure Boot Troubleshooting Windows10 Error1796 TPM KB5058379
Índice