MENU
  1. Accueil
  2. Windows
  3. Windows10
  4. Erreur TPM‑WMI 1796 après KB5058379/KB5060533 : causes et correctifs définitifs pour Windows 10 Secure Boot

Erreur TPM‑WMI 1796 après KB5058379/KB5060533 : causes et correctifs définitifs pour Windows 10 Secure Boot

Windows10

Depuis les mises à jour cumulatives KB5058379 puis KB5060533, de nombreux PC Windows 10 22H2 affichent à chaque démarrage l’erreur TPM‑WMI ID 1796 signalant l’échec de la mise à jour d’une variable Secure Boot. Cet article passe en revue les causes, les solutions éprouvées et les bonnes pratiques pour conserver un système sûr et à jour.

Sommaire

Problème rencontré

Après installation de KB5058379 (mai 2025, build 19045.5854) puis de KB5060533 (juin 2025), l’Observateur d’événements consigne systématiquement :

Source : TPM-WMI  
ID : 1796  
The Secure Boot update failed to update a Secure Boot variable with error Access is denied.

Le système démarre et fonctionne, mais la mise à jour de la base de signatures Secure Boot (DB/DBX) n’a pas été appliquée ; la machine pourrait continuer à faire confiance à des binaires révoqués par Microsoft.

Constatations clés

ObservationDétails
Machines touchéesPC HP Omen/Envy, cartes mères ASUS Z170/Z270/Z370, Dell XPS 2018‑2020 et tout PC Windows 10 équipé d’un firmware UEFI + Secure Boot + TPM 2.0.
Symptôme constantL’erreur disparaît dès la désinstallation de la mise à jour fautive et réapparaît instantanément après réinstallation.
Tentatives infructueusesEffacement ou réinitialisation TPM, réinitialisation des clés Secure Boot, exécution de l’utilitaire Windows Update, désactivation/réactivation simple de Secure Boot, Clear TPM via tpm.msc.
Mises à jour connexesLe correctif hors cycle KB5061768 (19 mai 2025) corrige un bug BitLocker/LSASS mais n’a aucun impact sur l’erreur 1796.

Analyse de la cause probable

Les patchs de mai/juin 2025 incorporent une nouvelle tranche de clés Secure Boot, dont la révocation de démarrages EFI obsolètes. Sur certaines cartes mères, l’activation simultanée de plusieurs extensions de virtualisation Intel (VT‑x, VT‑d, SGX, XD, Intel TXT) entraîne un verrouillage supplémentaire des variables NVRAM. Dès qu’un pilote Microsoft tente d’écrire la nouvelle DBX, le firmware répond Access is denied et déclenche l’événement 1796. L’opération est répétée à chaque démarrage, sans jamais aboutir.

Solutions et contournements vérifiés

A. Désinstaller la mise à jour

  1. Ouvrir Paramètres › Windows Update › Historique des mises à jour › Désinstaller une mise à jour.
  2. Sélectionner Microsoft Windows (KB5060533) s’il est présent, cliquer Désinstaller.
  3. Répéter pour Microsoft Windows (KB5058379).

Avantage : suppression immédiate de l’erreur.
Inconvénient : retour en arrière sur les correctifs de sécurité de mai/juin 2025 ; combler le manque par un durcissement réseau (pare‑feu, restriction de ports, désactivation SMBv1, etc.).

B. Réinstallation avec désactivation temporaire des options de virtualisation (solution la plus concluante)

  1. Désinstaller KB5060533 puis KB5058379 comme décrit ci‑dessus.
  2. Redémarrer et appuyer sur la touche adaptée (Esc, Del, F2…) pour entrer dans l’UEFI.
  3. Dans l’onglet Advanced, désactiver (ou passer de Enabled à Disabled) : Intel Virtualization Technology, VT‑d, SGX/Intel Software Guard, Intel TXT, Execute Disable (XD) si proposé. Ne désactivez pas Secure Boot.
  4. Enregistrer, quitter et laisser Windows démarrer.
  5. Lancer Windows Update. Les mises à jour KB5058379/KB5060533 seront automatiquement réinstallées.
  6. Redémarrer ; vérifier dans l’Observateur d’événements que l’ID 1796 n’apparaît plus.
  7. Rentrer de nouveau dans l’UEFI et réactiver un par un les paramètres de virtualisation utilisés (privilégier VT‑x/VT‑d d’abord, laisser SGX/TXT désactivés si inutiles). Redémarrer entre chaque activation pour isoler l’option bloquante, le cas échéant.

Avantage : corrige définitivement l’erreur sans sacrifier les mises à jour de sécurité.
Inconvénient : manipulation UEFI ; nécessite prudence (perte du clavier en mode sans fil, mauvais paramètre de boot, etc.).

C. Attendre un correctif officiel

Microsoft n’a pas encore reconnu publiquement le bogue (Patch Tuesday 08/07/2025). Les ingénieurs conseillent de voter et commenter les rapports existants dans Feedback Hub › Sécurité Windows. Surveillez les notes de KB mensuelles ; le correctif apparaîtra probablement dans une mise à jour de microcode ou de sécurité firmware.

D. Migrer vers Windows 11

Les premiers retours d’utilisateurs ayant franchi le pas vers Windows 11 23H2 (22631.3593) sur les mêmes machines ne signalent pas l’erreur 1796. Le processus d’installation applique de nouvelles clés Secure Boot avant le premier redémarrage, contournant le verrou. Vérifiez la compatibilité matériel (TPM 2.0, Secure Boot prêt, CPU éligible) et prévoyez 25 Go d’espace libre.

Tableau récapitulatif

MéthodeProcédureEfficacité
Désinstallation simpleDésinstaller KB5058379/KB5060533 et bloquer leur retour (Afficher les mises à jour masquées).Immédiate mais expose à de nouveaux CVE.
Réinstallation après décocher VT‑x/VT‑d/SGX/TXTDésinstaller → Désactiver virtualisation dans UEFI → Réinstaller → Réactiver.Succès confirmé sur HP Omen, Envy, ASUS Prime/Z et Dell XPS.
Attente correctifSignalement Feedback Hub, veille patch.Non résolu au 08/07/2025.
Migration Windows 11Mise à niveau ISO ou assistant Microsoft.Pas d’erreur 1796 signalée, mais contraintes CPU/TPM.

Vérifications post‑intervention

  • Journal Système : assurez‑vous qu’aucun nouvel événement 1796 n’est généré dans l’heure suivant la mise à jour.
  • Validation Secure Boot : exécutez en PowerShell (admin) : Confirm-SecureBootUEFI Le résultat doit être True.
  • Puis affichez la politique : Get-SecureBootPolicy | Format-List Les champs PolicyVersion et PolicyPublisherDate doivent indiquer juin 2025.
  • BitLocker : si le disque était chiffré, assurez‑vous que la clé n’a pas été invalidée (exécuter manage-bde -status).

Questions fréquentes (FAQ)

Mon antivirus rapporte-t-il quelque chose ?

Non ; l’erreur concerne l’UEFI. Les antivirus ne surveillent pas la NVRAM.

Puis-je laisser VT‑x activé et ne désactiver que VT‑d ?

Oui. Sur certains BIOS ASUS, seule l’option VT‑d entrave l’écriture de la DBX. Testez chaque paramètre isolément.

Le mode Legacy/CSM résout‑il le problème ?

Non ; Windows 10 installé en mode UEFI nécessite Secure Boot pour bénéficier des validations d’intégrité. Passer en CSM réinstalle le chargeur de démarrage et peut empêcher les futures mises à jour de sécurité.

Existe‑t‑il une commande pour appliquer manuellement la nouvelle DBX ?

Techniquement : sbupdate.exe --apply (outil interne Microsoft) mais il n’est pas distribué au public. Utilisez plutôt la méthode B.

Bonnes pratiques avant toute manipulation UEFI/TPM

  1. Sauvegarde complète (image système + fichiers critiques). Les modifications firmware sont toujours potentiellement destructrices.
  2. Clés de récupération BitLocker : imprimez‑les ou sauvegardez‑les hors‑ligne.
  3. Alimentation fiable : exécutez les changements UEFI sur secteur, jamais sur batterie faible.
  4. Mise à jour BIOS : si un firmware plus récent est disponible, appliquez‑le avant de réinstaller KB5058379/KB5060533.

Points à retenir

  • L’événement TPM‑WMI 1796 indique l’échec d’une mise à jour essentielle de Secure Boot, pas un simple avertissement anodin.
  • La méthode « désinstaller → désactiver virtualisation → réinstaller → réactiver » est, à ce jour, la parade la plus fiable.
  • Si vous choisissez de bloquer les patches, renforcez votre posture de sécurité : règles de pare‑feu strictes, application immédiate des définitions Defender, limitation des macros Office.
  • Continuez à signaler le bogue dans Feedback Hub pour accélérer la sortie d’un correctif cumulatif.

Pour aller plus loin

Surveillez chaque Patch Tuesday ; Microsoft incorpore fréquemment des mises à jour de microcode et des ajustements Secure Boot sans l’indiquer explicitement dans les notes de version. Après chaque mise à jour de qualité, prenez l’habitude de :

  • Lancer sfc /scannow et Dism /Online /Cleanup-Image /RestoreHealth.
  • Exporter les journaux critiques (wevtutil qe System /q:"Event[EventData[@Name='Id'] and EventData='1796']" /f:text /c:5) pour conserver un historique.
  • Vérifier que l’horloge matérielle est exacte ; un écart de plusieurs minutes peut bloquer la signature de certaines variables EFI.

En appliquant ces recommandations, vous assurez la continuité des correctifs de sécurité tout en éliminant l’alerte 1796 qui encombre vos journaux.

Windows10
UEFI Windows10 TPM Secure Boot KB5058379 KB5060533
Sommaire