Guide de résolution des problèmes de démarrage sécurisé
S’applique à
Date de publication d’origine : 19 mars 2026
ID de la base de connaissances : 5085046
Dans cet article
Vue d'ensemble
Cette page guide les administrateurs et les professionnels du support technique dans le diagnostic et la résolution des problèmes liés au démarrage sécurisé sur les appareils Windows. Les rubriques incluent les échecs de mise à jour du certificat de démarrage sécurisé, les états de démarrage sécurisé incorrects, les invites de récupération BitLocker inattendues et les échecs de démarrage suite à des modifications de configuration du démarrage sécurisé.
Les conseils expliquent comment vérifier la maintenance et la configuration de Windows, passer en revue les valeurs de Registre et les journaux des événements pertinents, et identifier quand les limitations du microprogramme ou de la plateforme nécessitent une mise à jour OEM. Ce contenu est destiné au diagnostic des problèmes sur les appareils existants. Il n’est pas destiné à planifier de nouveaux déploiements. Ce document sera mis à jour à mesure que de nouveaux scénarios de résolution des problèmes et des conseils seront identifiés.
Fonctionnement de la maintenance des certificats de démarrage sécurisé
La maintenance des certificats de démarrage sécurisé sur Windows est un processus coordonné entre le système d’exploitation et le microprogramme UEFI d’un appareil. L’objectif est de mettre à jour les ancres d’approbation critiques tout en préservant la possibilité de démarrer à chaque étape.
Le processus est piloté par une tâche planifiée Windows, une séquence basée sur le Registre d’actions de mise à jour et un comportement intégré de journalisation et de nouvelle tentative. Ensemble, ces composants garantissent que les certificats de démarrage sécurisé et le gestionnaire de démarrage Windows sont mis à jour de manière contrôlée et ordonnée, et uniquement après la réussite des étapes préalables.
Par où commencer lors de la résolution des problèmes
Lorsqu’un appareil ne semble pas progresser dans l’application des mises à jour de certificat de démarrage sécurisé, commencez par identifier la catégorie du problème. La plupart des problèmes se situent dans l’un des quatre domaines suivants : l’état de maintenance de Windows, le mécanisme de mise à jour du démarrage sécurisé, le comportement du microprogramme ou une limitation de plateforme ou d’OEM.
Commencez par les vérifications ci-dessous, dans l’ordre. Dans de nombreux cas, ces étapes sont suffisantes pour expliquer le comportement observé et déterminer les actions suivantes sans examen approfondi.
-
Confirmer l’éligibilité de la plateforme et de la maintenance Windows
-
Vérifiez que l’appareil répond aux exigences de base pour recevoir les mises à jour de certificat de démarrage sécurisé :
-
L’appareil exécute une version prise en charge de Windows.
-
Les dernières mises à jour de sécurité Windows requises sont installées.
-
Le démarrage sécurisé est activé dans le microprogramme UEFI.
-
Si l’une de ces conditions n’est pas remplie, traitez-les avant de poursuivre la résolution des problèmes.
-
-
Vérifier la tâche Secure-Boot-Update status
-
Vérifiez que le mécanisme Windows responsable de l’application des mises à jour de certificat de démarrage sécurisé est présent et fonctionne :
-
La tâche planifiée Secure-Boot-Update existe.
-
La tâche est activée et s’exécute en tant que système local.
-
La tâche s’est exécutée au moins une fois depuis l’installation de la dernière mise à jour de sécurité Windows.
-
Si la tâche est désactivée, supprimée ou en cours d’exécution, les mises à jour du certificat de démarrage sécurisé ne peuvent pas être appliquées. La résolution des problèmes doit se concentrer sur la restauration de la tâche avant d’examiner d’autres causes.
-
-
Vérifier la progression attendue dans les paramètres du Registre
Passez en revue l’état de maintenance du démarrage sécurisé de l’appareil dans le Registre :
-
Examinez UEFICA2023Status, UEFICA2023Error et UEFICA2023ErrorEvent.
-
Examinez AvailableUpdates et comparez-la à la progression attendue (voir Référence et internes).
Ensemble, ces valeurs indiquent si la maintenance progresse normalement, effectue une nouvelle tentative d’opération ou est bloquée à une étape spécifique.
-
-
Mettre en corrélation l’état du Registre avec les événements de démarrage sécurisé
Passez en revue les événements liés au démarrage sécurisé dans le journal des événements système et mettez-les en corrélation avec l’état du Registre. Les données d’événement confirment généralement si l’appareil progresse, effectue une nouvelle tentative en raison d’une condition temporaire ou est bloqué par un problème de microprogramme ou de plateforme.
Ensemble, le registre et les journaux des événements indiquent généralement si le comportement est attendu, temporaire ou nécessite une action corrective.
Tâche planifiée Secure-Boot-Update
La maintenance des certificats de démarrage sécurisé est implémentée via une tâche planifiée Windows nommée Secure-Boot-Update. La tâche est inscrite au chemin d’accès suivant :
\Microsoft\Windows\PI\Secure-Boot-Update
La tâche s’exécute en tant que système local. Par défaut, il s’exécute au démarrage du système et toutes les 12 heures par la suite. Chaque fois qu’il s’exécute, il vérifie si les actions de mise à jour de démarrage sécurisé sont en attente et tente de les appliquer dans l’ordre.
Si cette tâche est désactivée ou manquante, les mises à jour de certificat de démarrage sécurisé ne peuvent pas être appliquées. La tâche Secure-Boot-Update doit rester activée pour que la maintenance du démarrage sécurisé fonctionne.
Pourquoi une tâche planifiée est utilisée
Les mises à jour des certificats de démarrage sécurisé nécessitent une coordination entre le microprogramme Windows et UEFI, notamment l’écriture de variables UEFI qui stockent des clés et des certificats de démarrage sécurisé. Une tâche planifiée permet à Windows de tenter ces mises à jour lorsque le système est dans un état où les variables de microprogramme peuvent être modifiées.
La planification périodique de 12 heures offre des opportunités supplémentaires de nouvelles tentatives de mise à jour si une tentative précédente a échoué ou si l’appareil est resté sous tension sans redémarrage. Cette conception permet de garantir la progression sans nécessiter d’intervention manuelle.
Masque de bits de Registre AvailableUpdates
La tâche Secure-Boot-Update est pilotée par la valeur de Registre AvailableUpdates . Cette valeur est un masque de bits 32 bits situé à l’emplacement suivant :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Chaque bit dans la valeur représente une action de mise à jour de démarrage sécurisé spécifique. Le processus de mise à jour commence lorsque AvailableUpdates est défini sur une valeur différente de zéro, soit automatiquement par Windows, soit explicitement par un administrateur. Par exemple, une valeur telle que 0x5944 indique que plusieurs actions de mise à jour sont en attente.
Lorsque la tâche Secure-Boot-Update s’exécute, elle interprète les bits définis comme du travail en attente et les traite dans un ordre défini.
Mises à jour séquentielles, journalisation et comportement de retrial
Les mises à jour de certificat de démarrage sécurisé sont appliquées dans un ordre fixe. Chaque action de mise à jour est conçue pour être sécurisée pour effectuer une nouvelle tentative et se termine indépendamment. La tâche Secure-Boot-Update n’avance pas à l’étape suivante tant que l’action actuelle n’a pas réussi et que son bit correspondant est effacé de AvailableUpdates.
Chaque opération utilise des interfaces UEFI standard pour mettre à jour des variables de démarrage sécurisé telles que la base de données et la clé kek, ou pour installer le gestionnaire de démarrage Windows mis à jour. Windows enregistre le résultat de chaque étape dans le journal des événements système. Les événements de réussite confirment la progression, tandis que les événements d’échec indiquent la raison pour laquelle une action n’a pas pu être effectuée.
Si une étape de mise à jour échoue, la tâche arrête le traitement, enregistre l’erreur et laisse le bit associé défini. L’opération est retentée lors de la prochaine exécution de la tâche. Ce comportement de nouveau test permet aux appareils de récupérer automatiquement à partir de conditions temporaires, telles que la prise en charge du microprogramme manquante ou les mises à jour OEM retardées.
Les administrateurs peuvent suivre la progression en mettant en corrélation l’état du Registre avec les entrées du journal des événements. Les valeurs de Registre telles que UEFICA2023Status, UEFICA2023Error et UEFICA2023ErrorEvent, ainsi que le masque de bits AvailableUpdates , indiquent quelle étape est active, terminée ou bloquée.
Cette combinaison indique si l’appareil progresse normalement, effectue une nouvelle tentative d’opération ou est bloqué.
Intégration au microprogramme OEM
Les mises à jour des certificats de démarrage sécurisé dépendent du comportement et de la prise en charge corrects dans le microprogramme UEFI d’un appareil. Bien que Windows orchestre le processus de mise à jour, le microprogramme est responsable de l’application de la stratégie de démarrage sécurisé et de la maintenance des bases de données de démarrage sécurisé.
Les oem fournissent deux éléments critiques qui permettent la maintenance des certificats de démarrage sécurisé :
-
Clés d’échange de clés (KEK) signées par clé de plateforme qui autorisent l’installation de nouveaux certificats de démarrage sécurisé.
-
Implémentations de microprogramme qui conservent, ajoutent et valident correctement les bases de données de démarrage sécurisé pendant les mises à jour.
Si le microprogramme ne prend pas entièrement en charge ces comportements, les mises à jour de démarrage sécurisé peuvent se bloquer, réessayer indéfiniment ou entraîner des échecs de démarrage. Dans ce cas, Windows ne peut pas terminer la mise à jour sans modifier le microprogramme.
Microsoft travaille avec les fabricants OEM pour identifier les problèmes de microprogramme et mettre à disposition des mises à jour corrigées. Lorsque la résolution des problèmes indique une limitation ou un défaut de microprogramme, les administrateurs peuvent avoir besoin d’installer la dernière mise à jour du microprogramme UEFI fournie par le fabricant de l’appareil pour que les mises à jour du certificat de démarrage sécurisé puissent se terminer correctement.
Scénarios d’échec courants et résolutions
Les mises à jour de démarrage sécurisé sont appliquées par la tâche planifiée Secure-Boot-Update en fonction de l’état du Registre AvailableUpdates .
Dans des conditions normales, ces étapes se produisent automatiquement et enregistrent les événements de réussite à la fin de chaque étape. Dans certains cas, le comportement du microprogramme, la configuration de la plateforme ou les prérequis de maintenance peuvent empêcher la progression ou entraîner un comportement de démarrage inattendu.
Les sections ci-dessous décrivent les scénarios d’échec les plus courants, comment les reconnaître, pourquoi ils se produisent et les étapes suivantes appropriées pour restaurer un fonctionnement normal. Les scénarios sont classés des cas les plus fréquemment rencontrés à des cas de démarrage plus graves.
Lorsque les mises à jour de démarrage sécurisé n’affichent aucune progression, cela signifie généralement que le processus de mise à jour n’a jamais démarré. Par conséquent, les valeurs de Registre de démarrage sécurisé et les journaux d’événements attendus sont manquants, car le mécanisme de mise à jour n’a jamais été déclenché.
Que s'est-il passé
Le processus de mise à jour du démarrage sécurisé n’a pas démarré. Par conséquent, aucun certificat de démarrage sécurisé ou gestionnaire de démarrage mis à jour n’a été appliqué à l’appareil.
Comment le reconnaître
-
Aucune valeur de Registre de maintenance du démarrage sécurisé n’est présente, comme UEFICA2023Status.
-
Les événements de démarrage sécurisé attendus (par exemple, 1043, 1044, 1045, 1799, 1801) sont manquants dans le journal des événements système.
-
L’appareil continue d’utiliser des certificats de démarrage sécurisé et des composants de démarrage plus anciens.
Pourquoi cela se produit
Ce scénario se produit généralement lorsqu’une ou plusieurs des conditions suivantes sont remplies :
-
La tâche planifiée Secure-Boot-Update est désactivée ou manquante.
-
Le démarrage sécurisé est désactivé dans le microprogramme UEFI.
-
L’appareil ne répond pas aux conditions préalables de maintenance de Windows, telles que l’exécution d’une version de Windows prise en charge ou l’installation des mises à jour requises.
Que faire ensuite
-
Vérifiez que l’appareil répond aux exigences de maintenance et d’éligibilité de la plateforme Windows.
-
Vérifiez que le démarrage sécurisé est activé dans le microprogramme.
-
Vérifiez que la tâche planifiée SecureBootUpdate existe et est activée.
Si la tâche planifiée est désactivée ou manquante, suivez les instructions fournies dans Tâche planifiée de démarrage sécurisé désactivée ou supprimée pour la restaurer. Une fois la tâche restaurée, redémarrez l’appareil ou exécutez la tâche manuellement pour lancer la maintenance du démarrage sécurisé.
Dans certains cas, les mises à jour liées au démarrage sécurisé peuvent entraîner l’entrée d’un appareil dans la récupération BitLocker. Le comportement peut être temporaire ou persistant, en fonction de la cause sous-jacente.
Scénario 1 : Récupération BitLocker unique après la mise à jour du démarrage sécurisé
Que se passe-t-il ?
L’appareil entre dans la récupération BitLocker lors du premier démarrage après la mise à jour du démarrage sécurisé, mais démarre normalement lors des redémarrages suivants.
Pourquoi cela se produit
Lors du premier démarrage après la mise à jour, le microprogramme ne signale pas encore les valeurs de démarrage sécurisé mises à jour lorsque Windows tente de resserréger BitLocker. Cela provoque une incompatibilité temporaire dans les valeurs de démarrage mesurées et déclenche la récupération. Au prochain démarrage, le microprogramme signale les valeurs mises à jour correctement, BitLocker est correctement réinitélé et le problème ne se reproduit pas.
Comment le reconnaître
-
La récupération BitLocker se produit une seule fois.
-
Après avoir entré la clé de récupération, les démarrages suivants n’invitent pas la récupération.
-
Il n’y a pas d’ordre de démarrage ou d’intervention PXE en cours.
Que faire ensuite
-
Entrez la clé de récupération BitLocker pour reprendre Windows.
-
Recherchez les mises à jour du microprogramme.
Scénario 2 : Récupération BitLocker répétée en raison de la configuration du premier démarrage PXE
Que se passe-t-il ?
L’appareil entre dans la récupération BitLocker à chaque démarrage.
Pourquoi cela se produit
L’appareil est configuré pour tenter d’abord un démarrage PXE (réseau). La tentative de démarrage PXE échoue et le microprogramme revient ensuite au gestionnaire de démarrage Windows sur disque.
Cela entraîne la mesure de deux autorités de signature différentes au cours d’un même cycle de démarrage :
-
Le chemin de démarrage PXE est signé par Microsoft UEFI CA 2011.
-
Le gestionnaire de démarrage Windows sur disque est signé par Windows UEFI CA 2023.
Étant donné que BitLocker observe différentes chaînes d’approbation de démarrage sécurisé au démarrage, il ne peut pas établir un ensemble stable de mesures TPM sur laquelle se resserer. Par conséquent, BitLocker entre dans la récupération à chaque démarrage.
Comment le reconnaître
-
La récupération BitLocker est déclenchée à chaque redémarrage.
-
L’entrée de la clé de récupération permet à Windows de démarrer, mais l’invite retourne au démarrage suivant.
-
Le démarrage PXE ou réseau est configuré avant le disque local dans l’ordre de démarrage du microprogramme.
Que faire ensuite
-
Configurez l’ordre de démarrage du microprogramme pour que le gestionnaire de démarrage Windows sur disque soit en premier.
-
Désactivez le démarrage PXE s’il n’est pas nécessaire.
-
Si PXE est requis, vérifiez que l’infrastructure PXE utilise un chargeur de démarrage Windows signé 2023.
Que s'est-il passé
Cela reflète une modification au niveau du microprogramme plutôt qu’un problème Windows. La mise à jour du démarrage sécurisé s’est terminée correctement, mais après un redémarrage ultérieur, l’appareil ne démarre plus dans Windows.
Comment le reconnaître
-
L’appareil ne parvient pas à démarrer Windows et peut afficher un message de microprogramme ou bios indiquant une violation du démarrage sécurisé.
-
L’échec se produit une fois que les paramètres de démarrage sécurisé sont réinitialisés aux valeurs par défaut du microprogramme.
-
La désactivation du démarrage sécurisé peut permettre à l’appareil de démarrer à nouveau.
Pourquoi cela se produit
La réinitialisation du démarrage sécurisé aux valeurs par défaut du microprogramme efface les bases de données de démarrage sécurisé stockées dans le microprogramme. Sur les appareils qui ont déjà effectué la transition vers le gestionnaire de démarrage signé windows UEFI CA 2023, cette réinitialisation supprime les certificats requis pour approuver ce gestionnaire de démarrage.
Par conséquent, le microprogramme ne reconnaît plus le gestionnaire de démarrage Windows installé comme approuvé et bloque le processus de démarrage.
Ce scénario n’est pas dû à la mise à jour du démarrage sécurisé elle-même, mais à une action de microprogramme suivante qui supprime les ancres d’approbation mises à jour.
Que faire ensuite
-
Utilisez l’utilitaire de récupération de démarrage sécurisé pour restaurer le certificat requis afin que l’appareil puisse redémarrer.
-
Après la récupération, vérifiez que le dernier microprogramme disponible est installé auprès du fabricant de l’appareil.
-
Évitez de réinitialiser le démarrage sécurisé aux valeurs par défaut du microprogramme, sauf si le microprogramme OEM inclut des valeurs par défaut de démarrage sécurisé mises à jour qui approuvent les certificats 2023.
Utilitaire de récupération de démarrage sécurisé
Pour récupérer le système :
-
Sur un deuxième PC Windows sur lequel la mise à jour Windows de juillet 2024 ou plus récente est installée, copiez SecureBootRecovery.efi à partir de C :\Windows\Boot\EFI\.
-
Placez le fichier sur un lecteur USB au format FAT32 sous \EFI\BOOT\ et renommez-le bootx64.efi.
-
Démarrez l’appareil affecté à partir du lecteur USB et autorisez l’utilitaire de récupération à s’exécuter. L’utilitaire ajoute windows UEFI CA 2023 à la base de données.
Une fois le certificat restauré et le système redémarré, Windows doit démarrer normalement.
Important : Ce processus réapplique uniquement l’un des nouveaux certificats. Une fois l’appareil récupéré, vérifiez que les certificats les plus récents sont réappliqués et envisagez de mettre à jour le BIOS/UEFI du système vers la version la plus récente disponible. Cela peut aider à éviter une récurrence du problème de réinitialisation de démarrage sécurisé, car de nombreux fabricants OEM ont publié des correctifs de microprogramme pour ce problème spécifique.
Que s'est-il passé
Après avoir appliqué la mise à jour et le redémarrage du certificat de démarrage sécurisé, l’appareil ne démarre pas et n’atteint pas Windows.
Comment le reconnaître
-
L’appareil échoue immédiatement après le redémarrage requis par la mise à jour de démarrage sécurisé.
-
Une erreur de microprogramme ou de démarrage sécurisé peut s’afficher, ou le système peut s’arrêter avant le chargement de Windows.
-
La désactivation du démarrage sécurisé peut permettre à l’appareil de démarrer.
Pourquoi cela se produit
Ce problème peut être dû à un défaut dans l’implémentation du microprogramme UEFI de l’appareil.
Lorsque Windows applique des mises à jour de certificat de démarrage sécurisé, le microprogramme est censé ajouter de nouveaux certificats à la base de données de signature autorisée (DB) de démarrage sécurisé existante. Certaines implémentations de microprogramme remplacent incorrectement la base de données au lieu de l’ajouter.
Lorsque cela se produit,
-
Les certificats précédemment approuvés, y compris le certificat de chargeur de démarrage Microsoft 2011, sont supprimés.
-
Si le système utilise toujours un gestionnaire de démarrage signé avec le certificat 2011 à ce stade, le microprogramme ne l’approuve plus.
-
Le microprogramme rejette le gestionnaire de démarrage et bloque le processus de démarrage.
Dans certains cas, la base de données peut également être endommagée au lieu d’être remplacée proprement, ce qui aboutit au même résultat. Ce comportement a été observé sur des implémentations de microprogramme spécifiques et n’est pas attendu sur un microprogramme conforme.
Que faire ensuite
-
Entrez les menus de configuration du microprogramme et essayez de réinitialiser les paramètres de démarrage sécurisé.
-
Si l’appareil démarre après la réinitialisation, case activée le site de support du fabricant de l’appareil pour une mise à jour du microprogramme qui corrige la gestion de la base de données de démarrage sécurisé.
-
Si une mise à jour du microprogramme est disponible, installez-la avant de réactiver le démarrage sécurisé et de réappliquer les mises à jour du certificat de démarrage sécurisé.
Si la réinitialisation du démarrage sécurisé ne restaure pas la fonctionnalité de démarrage, une récupération supplémentaire nécessite probablement des conseils spécifiques à l’OEM.
Que s'est-il passé
La mise à jour du certificat de démarrage sécurisé n’est pas terminée et reste bloquée à l’étape de mise à jour de clé d’échange de clés (KEK).
Comment le reconnaître
-
La valeur de Registre AvailableUpdates reste définie avec le bit KEK (0x0004) et n’est pas effacée.
-
UEFICA2023Status ne passe pas à un état terminé.
-
Le journal des événements système enregistre à plusieurs reprises l’ID d’événement 1803, indiquant que la mise à jour de la clé KEK n’a pas pu être appliquée.
-
L’appareil continue à réessayer la mise à jour sans avancer la progression.
Pourquoi cela se produit
La mise à jour de la clé KEK de démarrage sécurisé nécessite l’autorisation de la clé de plateforme (PK) de l’appareil, qui appartient à l’OEM.
Pour que la mise à jour réussisse, le fabricant de l’appareil doit fournir à Microsoft une clé KEK signée par PK pour cette plateforme spécifique. Cette clé KEK signée OEM est incluse dans les mises à jour Windows et permet à Windows de mettre à jour la variable KEK du microprogramme.
Si l’OEM n’a pas fourni de clé KEK signée par PK pour l’appareil, Windows ne peut pas terminer la mise à jour de la clé KEK. Dans cet état :
-
Les mises à jour de démarrage sécurisé sont bloquées par conception.
-
Windows ne peut pas contourner l’autorisation manquante.
-
L’appareil peut rester définitivement incapable d’effectuer la maintenance du certificat de démarrage sécurisé.
Cela peut se produire sur des appareils plus anciens ou non pris en charge où l’OEM ne fournit plus de mises à jour de microprogramme ou de clé. Il n’existe aucun chemin de récupération manuelle pris en charge pour cette condition.
Lorsque les mises à jour du certificat de démarrage sécurisé ne parviennent pas à s’appliquer, Windows enregistre les événements de diagnostic qui expliquent pourquoi la progression a été bloquée. Ces événements sont écrits lors de la mise à jour de la base de données de signature de démarrage sécurisé (DB) ou de la clé d’échange de clés (KEK) en raison de conditions de microprogramme, d’état de plateforme ou de configuration. Les scénarios de cette section font référence à ces événements pour identifier les modèles de défaillance courants et déterminer la correction appropriée. Cette section est destinée à prendre en charge le diagnostic et l’interprétation des problèmes décrits précédemment, et non à introduire de nouveaux scénarios d’échec.
Pour obtenir la liste complète des ID d’événement, des descriptions et des exemples d’entrées, consultez Événements de mise à jour de la base de données de démarrage sécurisé et des variables DBX (KB5016061).
Échec de mise à jour kek (les mises à jour de base de données réussissent, ce n’est pas le cas)
Un appareil peut mettre à jour les certificats dans la base de données de démarrage sécurisé, mais échouer pendant la mise à jour de la clé KEK. Lorsque cela se produit, le processus de mise à jour du démarrage sécurisé ne peut pas être terminé.
Symptômes
-
Les événements de certificat de base de données indiquent la progression, mais l’étape kek n’est pas terminée.
-
AvailableUpdates reste défini sur 0x4004 et le bit 0x0004 n’est pas effacé après plusieurs exécutions de tâches.
-
L’événement 1795 ou 1803 peut être présent.
Interprétation
-
1795 indique généralement une défaillance du microprogramme lors de la tentative de mise à jour d’une variable de démarrage sécurisé.
-
1803 indique que la mise à jour de kek ne peut pas être autorisée, car une charge utile DE KEK signée PAR OEM n’est pas disponible pour la plateforme.
Prochaines étapes
-
Pour la version 1795, case activée pour les mises à jour du microprogramme OEM et valider la prise en charge du microprogramme pour les mises à jour des variables de démarrage sécurisé.
-
Pour la version 1803, vérifiez si l’OEM a fourni à Microsoft la clé KEK signée par PK requise pour le modèle d’appareil.
Échec de mise à jour kek sur les machines virtuelles invitées hébergées sur Hyper-V
Sur les machines virtuelles Hyper-V, les mises à jour de certificat de démarrage sécurisé nécessitent l’installation des mises à jour Windows de mars 2026 sur l’hôte Hyper-V et le système d’exploitation invité.
Les échecs de mise à jour sont signalés à partir de l’invité, mais l’événement indique où une correction est nécessaire :
-
L’événement 1795 (par exemple, « Le média est protégé en écriture ») signalé dans l’invité indique que l’hôte Hyper-V ne dispose pas de la mise à jour de mars 2026 et doit être mis à jour.
-
L’événement 1803 signalé dans l’invité indique que la machine virtuelle invitée elle-même manque la mise à jour de mars 2026 et doit être mise à jour.
Informations de référence et internes
Cette section contient des informations de référence avancées destinées à la résolution des problèmes et au support. Il n’est pas destiné à la planification du déploiement. Il s’étend sur les mécanismes de maintenance du démarrage sécurisé résumés précédemment et fournit des informations de référence détaillées pour interpréter l’état du Registre et les journaux des événements.
Remarque (déploiements gérés par l’informatique) : lorsqu’ils sont configurés via stratégie de groupe ou Microsoft Intune, deux paramètres similaires ne doivent pas être confondus. La valeur AvailableUpdatesPolicy représente l’état de stratégie configuré. Pendant ce temps, AvailableUpdates reflète l’état de travail en cours de suppression de bits. Les deux peuvent conduire au même résultat, mais ils se comportent différemment, car la stratégie s’applique à nouveau au fil du temps.
AvailableUpdates bits utilisés pour la maintenance des certificats
Les bits ci-dessous sont utilisés pour les actions de certificat et de gestionnaire de démarrage décrites dans ce document. La colonne Order reflète la séquence dans laquelle la tâche Secure-Boot-Update traite chaque bit.
|
Order |
Paramètre de bits |
Utilisation |
|---|---|---|
|
1 |
0x0040 |
Ce bit indique à la tâche planifiée d’ajouter le certificat Windows UEFI CA 2023 à la base de données de démarrage sécurisé. Cela permet à Windows d’approuver les gestionnaires de démarrage signés par ce certificat. |
|
2 |
0x0800 |
Ce bit indique à la tâche planifiée d’appliquer l’option Microsoft ROM UEFI CA 2023 à la base de données. Comportement conditionnel : lorsque l’indicateur 0x4000 est défini, la tâche planifiée commence par case activée la base de données pour le certificat MICROSOFT Corporation UEFI CA 2011. Il applique le certificat MICROSOFT Option ROM UEFI CA 2023uniquement si le certificat 2011 est présent. |
|
3 |
0x1000 |
Ce bit indique à la tâche planifiée d’appliquer Microsoft UEFI CA 2023 à la base de données. Comportement conditionnel : lorsque l’indicateur 0x4000 est défini, la tâche planifiée case activée d’abord la base de données pour le certificat MICROSOFT Corporation UEFI CA 2011. Il applique le certificat Microsoft UEFI CA 2023uniquement si le certificat 2011 est présent. |
|
Modificateur (indicateur de comportement) |
0x4000 |
Ce bit modifie le comportement des bits 0x0800 et 0x1000 afin que microsoft UEFI CA 2023 et Microsoft Option ROM UEFI CA 2023 soient appliqués uniquement si la base de données contient déjà microsoft Corporation UEFI CA 2011. Pour vous assurer que le profil de sécurité de l’appareil reste le même, ce bit applique uniquement ces nouveaux certificats si l’appareil approuve le certificat Microsoft Corporation UEFI CA 2011. Tous les appareils Windows n’approuvent pas ce certificat. |
|
4 |
0x0004 |
Ce bit indique à la tâche planifiée de rechercher une clé d’échange de clés signée par la clé de plateforme (PK) de l’appareil. Le PK est géré par l’OEM. Les fabricants OEM signent la clé kek Microsoft avec leur PK et la livrent à Microsoft où elle est incluse dans les mises à jour cumulatives mensuelles. |
|
5 |
0x0100 |
Ce bit indique à la tâche planifiée d’appliquer le gestionnaire de démarrage, signé par Windows UEFI CA 2023, à la partition de démarrage. Cela remplacera le gestionnaire de démarrage signé Microsoft Windows Production PCA 2011. |
Remarques :
-
Le bit 0x4000 reste défini après le traitement de tous les autres bits.
-
Chaque bit est traité par la tâche planifiée Secure-Boot-Update dans l’ordre indiqué ci-dessus.
-
Si le bit 0x0004 ne peut pas être traité en raison d’une clé kek signée PK manquante, la tâche planifiée applique toujours la mise à jour du gestionnaire de démarrage indiquée par bit 0x0100.
Progression attendue (AvailableUpdates)
Lorsqu’une opération se termine correctement, Windows efface le bit associé de AvailableUpdates. En cas d’échec d’une opération, Windows enregistre un événement et effectue une nouvelle tentative lorsque la tâche s’exécute à nouveau.
Le tableau ci-dessous montre la progression attendue des valeurs AvailableUpdates à mesure que chaque action de mise à jour de démarrage sécurisé se termine.
|
l’étape |
Bit traité |
Mises à jour disponibles |
Description |
Journal de l’événement de réussite |
Codes d’événement d’erreur possibles |
|---|---|---|---|---|---|
|
Démarrer |
0x5944 |
État initial avant le début de la maintenance du certificat de démarrage sécurisé. |
- |
- |
|
|
1 |
0x0040 |
0x5944 → 0x5904 |
Windows UEFI CA 2023 est ajouté à la base de données de démarrage sécurisé. |
1036 |
1032, 1795, 1796, 1802 |
|
2 |
0x0800 |
0x5904 → 0x5104 |
Ajoutez Microsoft Option ROM UEFI CA 2023 à la base de données si l’appareil a précédemment approuvé Microsoft UEFI CA 2011. |
1044 |
1032, 1795, 1796, 1802 |
|
3 |
0x1000 |
0x5104 → 0x4104 |
Microsoft UEFI CA 2023 est ajouté à la base de données si l’appareil a précédemment approuvé Microsoft UEFI CA 2011. |
1045 |
1032, 1795, 1796, 1802 |
|
4 |
0x0004 |
0x4104 → 0x4100 |
La nouvelle clé Microsoft KEK 2K CA 2023 signée par la clé de plateforme OEM est appliquée. |
1043 |
1032, 1795, 1796, 1802, 1803 |
|
5 |
0x0100 |
0x4100 → 0x4000 |
Le gestionnaire de démarrage signé par Windows UEFI CA 2023 est installé. |
1799 |
1797 |
Remarques
-
Une fois l’opération associée à un bit terminée avec succès, ce bit est effacé de AvailableUpdates.
-
Si l’une de ces opérations échoue, un événement est journalisé et l’opération est retentée lors de la prochaine exécution de la tâche planifiée.
-
Le bit 0x4000 est un modificateur et n’est pas effacé. Une valeur AvailableUpdates finale de 0x4000 indique la réussite de toutes les actions de mise à jour applicables.
-
Les événements 1032, 1795, 1796, 1802 indiquent généralement des limitations de microprogramme ou de plateforme.
-
L’événement 1803 indique la clé KEK PK signée par OEM manquante.
Procédures de correction
Cette section fournit des procédures pas à pas pour corriger des problèmes de démarrage sécurisé spécifiques. Chaque procédure est limitée à une condition bien définie et est destinée à être suivie uniquement après que le diagnostic initial confirme que le problème s’applique. Utilisez ces procédures pour restaurer le comportement de démarrage sécurisé attendu et permettre aux mises à jour de certificat de se poursuivre en toute sécurité. N’appliquez pas ces procédures de manière générale ou préventive.
Activation du démarrage sécurisé dans le microprogramme
Si le démarrage sécurisé est désactivé dans le microprogramme d’un appareil, consultez Windows 11 et Démarrage sécurisé pour plus d’informations sur l’activation du démarrage sécurisé.
Tâche planifiée de démarrage sécurisé désactivée ou supprimée
La tâche planifiée Secure-Boot-Update est requise pour que Windows applique les mises à jour de certificat de démarrage sécurisé. Si la tâche est désactivée ou manquante, la maintenance du certificat de démarrage sécurisé ne progresse pas.
Détails de la tâche
|
Nom de la tâche |
Secure-Boot-Update |
|
Chemin d’accès de la tâche |
\Microsoft\Windows\PI\ |
|
Chemin d’accès complet |
\Microsoft\Windows\PI\Secure-Boot-Update |
|
S’exécute en tant que |
SYSTEM (Système local) |
|
Déclencheurs |
Au démarrage et toutes les 12 heures |
|
État requis |
Enabled |
Guide pratique pour case activée status de tâches
Exécutez à partir d’une invite PowerShell avec élévation de privilèges : schtasks.exe /Query /TN « \Microsoft\Windows\PI\Secure-Boot-Update » /FO LIST /V
Recherchez le champ État :
|
État |
Signification |
|---|---|
|
Ready |
La tâche existe et est activée. |
|
Disabled |
La tâche existe, mais doit être activée. |
|
Erreur / Introuvable |
La tâche est manquante et doit être recréée. |
Comment activer ou recréer la tâche
Si le champ status pour Secure-Boot-Update est Désactivé, Erreur ou Introuvable, utilisez l’exemple de script pour activer la tâche : Exemple de Enable-SecureBootUpdateTask.ps1
Remarque : Il s’agit d’un exemple de script qui n’est pas pris en charge par Microsoft. Les administrateurs doivent l’examiner et l’adapter à leur environnement.
Exemple :
.\Enable-SecureBootUpdateTask.ps1 - Silencieux
Conseils d’exécution
-
Si accès refusé s’affiche, réexécutez PowerShell en tant qu’administrateur.
-
Si le script ne s’exécute pas en raison d’une stratégie d’exécution, utilisez un contournement de l’étendue du processus :
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Besoin d’aide ?
Vous voulez plus d’options ?
Explorez les avantages de l’abonnement, parcourez les cours de formation, découvrez comment sécuriser votre appareil, etc.
Les communautés vous permettent de poser des questions et d'y répondre, de donner vos commentaires et de bénéficier de l'avis d'experts aux connaissances approfondies.
