Remarque
- Date de publication d’origine : 19 mars 2026
- ID de la Base de connaissances : 5085046
Contenu de cet article
- Présentation
- Fonctionnement de la maintenance d’un certificat de démarrage sécurisé
- Par où commencer pour résoudre les problèmes
- Tâche planifiée Secure-Boot-Update
- Pourquoi une tâche planifiée est utilisée ?
- Masque de bits du Registre AvailableUpdates
- Intégration avec le micrologiciel OEM
- Scénarios d’échec courants et résolutions
- Référence et internes
- AvailableUpdates bits utilisés pour la maintenance de certificat
- Progression attendue (AvailableUpdates)
- Procédures de correction
- Activation du démarrage sécurisé dans le microprogramme
- Tâche planifiée de démarrage sécurisé désactivée ou supprimée
Présentation
Cette page aide les administrateurs et les professionnels de l’assistance 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 la configuration du démarrage sécurisé.
Les instructions expliquent comment vérifier la maintenance et la configuration de Windows, examiner les valeurs de Registre et les journaux d’é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é à la planification de nouveaux déploiements. Ce document sera mis à jour à mesure que de nouveaux scénarios de dépannage et directives seront identifiés.
Fonctionnement de la maintenance du certificat de démarrage sécurisé
La maintenance du certificat 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 de confiance critiques tout en préservant la possibilité de démarrer à chaque étape.
Le processus est piloté par une tâche planifiée par Windows, une séquence d’actions de mise à jour basée sur le registre, ainsi qu’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 une fois les étapes préalables requises réussies.
Par où commencer pour résoudre les problèmes
Lorsqu’un appareil ne semble pas faire les progrès attendus lors de 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 relèvent de 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 la plateforme ou du fabricant d’ordinateurs 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 investigation plus approfondie.
Confirmer l’éligibilité à la maintenance et à la plateforme Windows
- Vérifiez que l’appareil répond aux exigences de base pour recevoir les mises à jour du 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, corrigez-la avant de poursuivre la procédure de dépannage.
Vérifier le status de la tâche Secure-Boot-Update
- Vérifiez que le mécanisme Windows responsable de l’application des mises à jour du 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 a été 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 n’est pas 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
Examinez l’état de maintenance du démarrage sécurisé de l’appareil dans le Registre :- Examinez UEFICA2023Status, UEFICA2023Error et UEFICA2023ErrorEvent.
- Examinez AvailableUpdates et comparez-le à la progression attendue (voir Référence et internes).
Ensemble, ces valeurs indiquent si la maintenance progresse normalement, si une opération est à nouveau tentée ou si elle est bloquée à une étape spécifique.
Mettre en corrélation l’état du Registre avec les événements de démarrage sécurisé
Examinez 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 avance, réessaie 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 du certificat 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 enregistrée dans le chemin d’accès suivant :
Remarque
\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 du 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 du 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 Windows et le microprogramme UEFI, y compris l’écriture de variables UEFI qui stockent les clés et les certificats de démarrage sécurisé. Une tâche planifiée permet à Windows d’essayer ces mises à jour lorsque le système est dans un état où des variables du microprogramme peuvent être modifiées.
La planification périodique de 12 heures offre des possibilités supplémentaires de réessayer des mises à jour si une tentative précédente a échoué ou si le périphérique est resté sous tension sans redémarrage. Cette conception permet de progresser sans intervention manuelle.
Masque de bits du Registre AvailableUpdates
La tâche de mise à jour de démarrage sécurisé est pilotée par la valeur de registre AvailableUpdates . Cette valeur est un masque de bits 32 bits situé dans :
Remarque
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Chaque bit de la valeur représente une action spécifique de mise à jour du démarrage sécurisé. Le processus de mise à jour commence lorsque AvailableUpdates est défini sur une valeur non nulle, 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 des tâches en attente et les traite dans un ordre défini.
Mises à jour séquentielles, journalisation et comportement de la nouvelle version d’évaluation
Les mises à jour du certificat de démarrage sécurisé sont appliquées dans un ordre fixe. Chaque action de mise à jour est conçue pour être sûre de réessayer et se termine indépendamment. La tâche de mise à jour de démarrage sécurisé ne passe pas à l’étape suivante tant que l’action en cours n’a pas réussi et que le bit correspondant n’est pas effacé de AvailableUpdates.
Chaque opération utilise des interfaces UEFI standard pour mettre à jour les 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 pourquoi 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 tentée à nouveau lors de la prochaine exécution de la tâche. Ce comportement de nouvelle version d’évaluation permet aux appareils de récupérer automatiquement des conditions temporaires, telles que l’absence de prise en charge du microprogramme ou des mises à jour OEM retardées.
Les administrateurs peuvent suivre la progression en corrélant 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 l’étape active, terminée ou bloquée.
Cette combinaison indique si l’appareil progresse normalement, réessaie une opération ou est bloqué.
Intégration avec le micrologiciel OEM
Les mises à jour du certificat de démarrage sécurisé dépendent du comportement correct et de la prise en charge dans le microprogramme UEFI d’un appareil. Alors que Windows orchestre le processus de mise à jour, le microprogramme est chargé d’appliquer la stratégie de démarrage sécurisé et de gérer les bases de données de démarrage sécurisé.
Les OEM fournissent deux éléments essentiels 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 du 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 collabore avec les fabricants OEM pour identifier les problèmes de microprogramme et rendre disponibles les mises à jour corrigées. Lorsque la résolution des problèmes indique une limitation ou un défaut du microprogramme, les administrateurs devront peut-être 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 avec succès.
Scénarios d’échec courants et résolutions
Les mises à jour du 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 conditions préalables 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 rétablir un fonctionnement normal. Les scénarios sont classés des cas les plus couramment rencontrés aux cas ayant un impact sur le démarrage.
Les mises à jour de démarrage sécurisé ne s’appliquent pas (pas de progression)
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 commencé. Par conséquent, les valeurs de registre et les journaux des événements de démarrage sécurisé 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é, de sorte qu’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 de démarrage sécurisé n’est présente, telle que UEFICA2023Status.
- Les événements de démarrage sécurisé attendus (par exemple, 1043, 1044, 1045, 1799, 1801) ne sont pas présents dans le journal des événements système.
- L’appareil continue d’utiliser d’anciens certificats de démarrage sécurisé et des composants de démarrage.
Pourquoi cela se produit-il
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 respecte pas les conditions préalables de maintenance Windows, telles que l’exécution d’une version Windows prise en charge ou l’installation de mises à jour requises.
Procédure suivante à suivre
- 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.
- Assurez-vous 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 de la 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é.
L’appareil démarre dans la récupération BitLocker après la mise à jour 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 transitoire ou persistant, selon la cause sous-jacente.
Scénario 1 : Récupération BitLocker unique après la mise à jour du démarrage sécurisé
Action
L’appareil entre en mode récupération BitLocker au premier démarrage après la mise à jour du démarrage sécurisé, mais démarre normalement au redémarrage suivant.
Pourquoi cela se produit-il
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 resceller BitLocker. Ce problème entraîne une incompatibilité temporaire des valeurs de démarrage mesurées et déclenche la récupération. Au démarrage suivant, le microprogramme signale correctement les valeurs mises à jour, BitLocker se referme correctement et le problème ne se reproduit pas.
Comment le reconnaître
- La récupération BitLocker ne se produit qu’une seule fois.
- Après avoir entré la clé de récupération, les démarrages suivants n’invitent pas à la récupération.
- Aucune commande de démarrage en cours ou implication PXE n’est présente.
Procédure suivante à suivre
- 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
Action
L’appareil entre en mode récupération BitLocker à chaque démarrage.
Pourquoi cela se produit-il
L’appareil est configuré pour tenter d’abord le démarrage PXE (réseau). La tentative de démarrage PXE échoue, puis le microprogramme revient au gestionnaire de démarrage Windows sur disque.
Il en résulte que deux autorisations de signature différentes sont mesurées au cours d’un même cycle de démarrage :
- Le chemin d’accès de démarrage PXE est signé par l’autorité de certification Microsoft UEFI 2011.
- Le gestionnaire de démarrage Windows sur disque est signé par l’autorité de certification UEFI Windows 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 pour la refermeture. Par conséquent, BitLocker entre en mode récupération à chaque démarrage.
Comment le reconnaître
- La récupération BitLocker est déclenchée à chaque redémarrage.
- La saisie de la clé de récupération permet à Windows de démarrer, mais l’invite revient 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.
Procédure suivante à suivre
- Configurez l’ordre de démarrage du microprogramme de sorte que le gestionnaire de démarrage Windows sur disque soit prioritaire.
- Désactivez le démarrage PXE s’il n’est pas nécessaire.
- Si PXE est nécessaire, assurez-vous que l’infrastructure PXE utilise un chargeur de démarrage Windows signé pour 2023.
Échec du démarrage de l’appareil après la réinitialisation du démarrage sécurisé
Que s’est-il passé
Il s’agit d’un changement au niveau du microprogramme plutôt que d’un problème Windows. La mise à jour du démarrage sécurisé a été effectuée avec succès, 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 du microprogramme ou du BIOS indiquant une violation de démarrage sécurisé.
- L’échec se produit après la réinitialisation des paramètres de démarrage sécurisé aux paramètres par défaut du microprogramme.
- La désactivation du démarrage sécurisé peut entraîner le redémarrage de l’appareil.
Pourquoi cela se produit-il
La réinitialisation du démarrage sécurisé aux paramètres par défaut du microprogramme efface les bases de données du démarrage sécurisé stockées dans le microprogramme. Sur les appareils qui sont déjà passés au gestionnaire de démarrage signé par Windows UEFI CA 2023, cette réinitialisation supprime les certificats nécessaires pour approuver ce gestionnaire de démarrage.
Par conséquent, le microprogramme ne reconnaît plus le gestionnaire de démarrage Windows installé comme fiable et bloque le processus de démarrage.
Ce scénario n’est pas causé par la mise à jour du démarrage sécurisé elle-même, mais par une action ultérieure du microprogramme qui supprime les ancres de confiance mises à jour.
Procédure suivante à suivre
- Utilisez l’utilitaire de récupération de démarrage sécurisé pour restaurer le certificat requis afin que l’appareil puisse démarrer à nouveau.
- Après la récupération, vérifiez que le dernier microprogramme disponible est installé sur l’appareil auprès du fabricant de l’appareil.
- Évitez de rétablir le démarrage sécurisé par défaut du microprogramme, sauf si le microprogramme OEM inclut des paramètres par défaut du démarrage sécurisé mis à 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 laissez l’utilitaire de récupération s’exécuter. L’utilitaire ajoute l’autorité de certification UEFI 2023 de Windows à la base de données.
Une fois le certificat restauré et le système redémarré, Windows devrait démarrer normalement.
Important : Ce processus ne réappliquera qu’un seul 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 permet d’éviter que le problème de réinitialisation du démarrage sécurisé ne se reproduise, car de nombreux fabricants OEM ont publié des correctifs de microprogramme pour ce problème spécifique.
L’appareil ne démarre pas après la mise à jour du démarrage sécurisé en raison du remplacement de la base de données par le microprogramme
Que s’est-il passé
Après l’application de la mise à jour du certificat de démarrage sécurisé et le redémarrage, l’appareil ne parvient pas à démarrer et n’atteint pas Windows.
Comment le reconnaître
- L’appareil échoue immédiatement après le redémarrage requis par la mise à jour du 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 autoriser le démarrage de l’appareil.
Pourquoi cela se produit-il
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 signatures autorisées par le démarrage sécurisé existante. Certaines implémentations de microprogramme écrasent 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 lui fait plus confiance.
- 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 corrompue plutôt que proprement remplacée, ce qui conduit au même résultat. Ce comportement a été observé sur des implémentations de microprogrammes spécifiques et n’est pas attendu sur les microprogrammes conformes.
Procédure suivante à suivre
- Entrez dans 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 obtenir 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 instructions spécifiques du fabricant d’ordinateurs OEM.
Mise à jour du démarrage sécurisé bloquée en raison d’un KEK signé par l’OEM manquant
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 la 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 progresse pas vers un état terminé.
- Le journal des événements système enregistre à plusieurs reprises l’ID d’événement 1803, indiquant que la mise à jour KEK n’a pas pu être appliquée.
- L’appareil continue de réessayer la mise à jour sans avancer.
Pourquoi cela se produit-il
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 au fabricant d’ordinateurs OEM.
Pour que la mise à jour réussisse, le fabricant de l’appareil doit fournir à Microsoft une clé KEK signée PK pour cette plate-forme spécifique. Cette clé KEK signée par le fabricant d’ordinateurs est incluse dans les mises à jour de Windows et permet à Windows de mettre à jour la variable KEK du microprogramme.
Si le fabricant OEM n’a pas fourni de clé KEK signée PK pour l’appareil, Windows ne peut pas terminer la mise à jour de la clé KEK. Dans cet état :
- Les mises à jour du 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ù le fabricant OEM ne fournit plus de mises à jour de microprogramme ou de clé. Il n’existe aucune voie de récupération manuelle prise en charge pour cette condition.
Événements de mise à jour du certificat de démarrage sécurisé et indicateurs d’échec
Lorsque les mises à jour du certificat de démarrage sécurisé ne s’appliquent pas, 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) ne peut pas être effectuée en toute sécurité en raison du microprogramme, de l’état de la plateforme ou de conditions 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 à faciliter 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 du démarrage sécurisé et des variables DBX (KB5016061).
Échec de la mise à jour KEK (les mises à jour de base de données réussissent, KEK échoue)
Un appareil peut mettre à jour avec succès des certificats dans la base de données de démarrage sécurisé, mais échouer lors de la mise à jour KEK. Dans ce cas, 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 de 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 un échec du microprogramme lors de la tentative de mise à jour d’une variable de démarrage sécurisé.
- La version 1803 indique que la mise à jour KEK ne peut pas être autorisée, car une charge utile KEK requise signée par PK OEM n’est pas disponible pour la plate-forme.
Étapes suivantes
- Pour la version 1795, case activée les mises à jour du microprogramme OEM et validez la prise en charge du microprogramme pour les mises à jour des variables de démarrage sécurisé.
- Pour la version 1803, vérifiez si le fabricant OEM a fourni à Microsoft la clé KEK signée PK requise pour le modèle d’appareil.
Échec de mise à jour de KEK sur les ordinateurs virtuels invités hébergés sur Hyper-V
Sur les machines virtuelles Hyper-V, les mises à jour du certificat de démarrage sécurisé nécessitent l’installation des mises à jour Windows de mars 2026 sur l’hôte Hyper-V et sur le système d’exploitation invité.
Les échecs de mise à jour sont signalés à partir de l’invité, mais l’événement indique où la correction est nécessaire :
- L’événement 1795 (par exemple, « Le média est protégé en écriture ») signalé dans l’invité indique que la mise à jour de mars 2026 ne figure pas sur l’hôte Hyper-V et doit être mis à jour.
- L’événement 1803 signalé dans l’invité indique que la machine virtuelle invitée elle-même ne dispose pas de la mise à jour de mars 2026 et doit être mise à jour.
Référence et internes
Cette section contient des informations de référence avancées destinées au dépannage et au support. Il n’est pas destiné à la planification du déploiement. Il développe 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 l’interprétation des journaux d’état et des événements du Registre.
Remarque (déploiements gérés par le service informatique) : lors de la configuration via une stratégie de groupe ou Microsoft Intune, deux paramètres similaires ne doivent pas être confondus. La valeur AvailableUpdatesPolicy représente l’état de la stratégie configurée. Pendant ce temps, AvailableUpdates reflète l’état du travail en cours d’exécution de suppression de bits. Les deux peuvent conduire au même résultat, mais ils se comportent différemment car la politique s’applique à nouveau au fil du temps.
AvailableUpdates bits utilisés pour la maintenance de certificat
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 Ordre reflète l’ordre dans lequel la tâche Secure-Boot-Update traite chaque bit.
| Commande | Paramètre de bit | Utilisation |
|---|---|---|
| 1 | 0x0040 | Ce bit indique la tâche planifiée pour 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 case activée d’abord 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 l’autorité de certification Microsoft UEFI 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 de 2011 est présent. |
| Modificateur (indicateur de comportement) | 0x4000 | Ce bit modifie le comportement des bits 0x0800 et 0x1000 de sorte que l’autorité de certification UEFI Microsoft 2023 et l’option Microsoft ROM UEFI CA 2023 ne sont appliquées que si la base de données contient déjà l’autorité de certification UEFI 2011 de Microsoft Corporation. Pour s’assurer que le profil de sécurité de l’appareil reste le même, ce bit applique uniquement ces nouveaux certificats si l’appareil fait confiance au certificat Microsoft Corporation UEFI CA 2011. Tous les appareils Windows ne font pas confiance à 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. La clé primaire est gérée par le fabricant d’ordinateurs OEM. Les OEM signent la clé Microsoft KEK avec leur clé primaire et la remettent à 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 l’autorité de certification UEFI Windows 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 une fois tous les autres bits traités.
- 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é primaire signée KEK manquante, la tâche planifiée appliquera toujours la mise à jour du gestionnaire de démarrage indiquée par le bit 0x0100.
Progression attendue (AvailableUpdates)
Lorsqu’une opération se termine avec succès, Windows efface le bit associé de AvailableUpdates. Si une opération échoue, Windows enregistre un événement et réessaie 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 du démarrage sécurisé est terminée.
| Étape | Bit traité | Mises à jour disponibles | Description | Événement de réussite consigné | 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 | L’autorité de certification UEFI Windows 2023 est ajoutée à la base de données de démarrage sécurisé. | 1036 | 1032, 1795, 1796, 1802 |
| 2 | 0x0800 | 0x5904 → 0x5104 | Ajoutez l’option Microsoft ROM UEFI CA 2023 à la base de données si l’appareil a précédemment approuvé l’autorité de certification UEFI Microsoft 2011. | 1044 | 1032, 1795, 1796, 1802 |
| 3 | 0x1000 | 0x5104 → 0x4104 | L’autorité de certification UEFI Microsoft 2023 est ajoutée à la base de données si l’appareil a précédemment approuvé l’autorité de certification UEFI Microsoft 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 du microprogramme ou de la plate-forme.
- L’événement 1803 indique un KEK signé par PK OEM manquant.
Procédures de correction
Cette section fournit des procédures pas à pas pour résoudre des problèmes de démarrage sécurisé spécifiques. Chaque procédure est définie sur une condition bien définie et ne doit être suivie qu’après que le diagnostic initial ait confirmé 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 dérouler en toute sécurité. N’appliquez pas ces procédures de manière large 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 nécessaire pour que Windows applique les mises à jour du 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 progressera pas.
Détails de la tâche
| Nom de tâche | secure-boot-update |
|---|---|
| Chemin 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 | Activé |
Comment vérifier le status de la case activée
Exécuter à 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 |
|---|---|
| Prêt | 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 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 :
Remarque
.\Enable-SecureBootUpdateTask.ps1 -Quiet
Conseils d’exécution
- Si Access refusé s’affiche, réexécutez PowerShell en tant qu’administrateur.
- Si le script ne s’exécute pas en raison de la stratégie d’exécution, utilisez un contournement de l’étendue du processus :
Remarque
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass