Prévention et reprise des crises transparentes
Si une mise à jour du microprogramme échoue, les résultats peuvent être dévastateurs. Au mieux, la mise à jour échoue, mais le système est résilient et récupère sans que l’utilisateur final ne s’en rende compte. Au pire, il est possible qu’une mise à jour du microprogramme ayant échoué entraîne un système inutilisable, obligeant l’utilisateur final à retourner son système au détaillant ou au fabricant pour réparation. Ce dernier cas est ce que nous appelons une crise.
Une crise peut résulter d’un échec de mise à jour du microprogramme ou d’un microprogramme incompatible avec Windows ou d’autres aspects du système. Cette section décrit les fonctionnalités conçues pour prévenir et récupérer les crises résultant de l’échec des mises à jour du microprogramme. Nous nous attendons à ce que la couverture de test des mises à jour du microprogramme par l’auteur du microprogramme empêche la plupart des crises résultant d’un microprogramme incompatible.
Afin de fournir une expérience optimale aux utilisateurs finaux, les exigences suivantes en matière de prévention et de récupération des crises doivent être satisfaites pour le mécanisme de mise à jour du package de pilotes de microprogramme. Ces exigences n’excluent pas d’autres solutions de prévention ou de reprise des crises.
Critères de préinstallation
Lorsque le microprogramme système effectue la mise à jour réelle, une série de vérifications de préinstallation doit être effectuée. Le microprogramme système doit effectuer cette case activée pour s’assurer qu’il y a suffisamment de puissance pour terminer la mise à jour. Il est également recommandé d’effectuer des vérifications pour chacune des mises à jour avant l’application de la mise à jour s’il existe plusieurs mises à jour de microprogramme. La liste des éléments à case activée et à valider est fournie dans le tableau suivant. Toutes les vérifications doivent être effectuées le cas échéant. Il n’y a pas d’ordre spécifique à l’exécution des tests.
| Type de vérification | Description |
|---|---|
| Avancé | Le système doit avoir au moins 25 % de charge de la batterie. L’alimentation captée (alimentation via un câble USB et/ou une alimentation secteur) n’est pas nécessaire. Dans un environnement de test/laboratoire, il est acceptable d’avoir aucune batterie présente, mais d’autoriser les mises à jour du microprogramme tant que l’alimentation est fournie. Toutefois, une distinction doit être faite entre une batterie morte/non en charge et aucune batterie présente. |
| Sécurité | Vérifiez que la charge utile de la capsule de mise à jour est correctement signée. Vérifiez que tous les fichiers EFI basés sur PE dans la charge utile sont correctement signés avec un certificat EFI approprié |
| Intégrité | Effectuez une case activée d’intégrité sur la charge utile de mise à jour du microprogramme. |
| Version | Vérifiez que le microprogramme appliqué ne rétrograde pas le microprogramme actuel installé au-delà de la valeur LowestSupportedFirmwareVersion. |
| Stockage | Les vérifications suivantes sont effectuées comme il convient, en fonction du matériel du système Il y a suffisamment d’espace pour les sauvegardes du microprogramme actuel qui sera remplacé Il y a suffisamment d’espace dans l’appareil pour prendre en charge le nouveau microprogramme. |
Tout échec doit entraîner un code d’erreur d’état de la dernière tentative approprié. Pour plus d’informations, consultez les informations de code d’erreur État de la dernière tentative dans définition de table ESRT et mise à jour du microprogramme status.
Si plusieurs mises à jour sont appliquées et que certaines réussissent les vérifications de préinstallation et que d’autres ne le font pas, le microprogramme de plateforme peut procéder à la mise à jour du microprogramme pour les ressources qui ont réussi les vérifications de préinstallation. Toutefois, toute ressource ayant échoué au case activée de préinstallation ne doit pas être mise à jour.
Critères de post-installation
Une fois le microprogramme (appareil ou système) installé, il doit être vérifié pour vérifier que la nouvelle image de microprogramme mise à jour correspond à ce qui a été prévu. Il s’agit de réduire les risques d’endommagement introduits pendant le processus de mise à jour réel (par exemple, les bits collants dans la ROM flash, le bruit sur un bus pendant la mise à jour, etc.).
Le processus de mise à jour doit vérifier que le microprogramme mis à jour réussit les vérifications d’intégrité. En cas d’échec, il doit récupérer en rétablissant la dernière version correcte connue du microprogramme.
Tout échec doit entraîner un code d’erreur d’état de la dernière tentative approprié. Pour plus d’informations, consultez les informations de code d’erreur État de la dernière tentative dans définition de table ESRT et mise à jour du microprogramme status.
Récupération après des échecs d’installation et de démarrage
Pour empêcher un système d’atteindre un état non démarrable, le mécanisme de mise à jour du microprogramme doit répondre aux exigences suivantes dans les cas où les mises à jour du microprogramme ne parviennent pas à s’installer ou lorsque le système ne parvient pas à démarrer correctement.
Dans les sections suivantes, le terme « committed » est utilisé pour décrire le microprogramme. Une fois que le microprogramme a été « validé », le microprogramme est traité comme entièrement installé et ne sera pas automatiquement restauré par le microprogramme en raison d’un échec de démarrage, etc. Le microprogramme « Non validé » décrit le microprogramme partiellement mis à jour et peut potentiellement être restauré vers une version précédente dans les cas où la mise à jour du microprogramme ne peut pas être terminée ou un échec est détecté par le microprogramme de mise à jour (par exemple, case activée CRC non valides dans la mise à jour). Si le microprogramme est validé est quelque chose que le microprogramme doit suivre en interne et n’est pas capturé dans le cadre de l’ESRT.
Échec de la mise à jour du microprogramme
Si un microprogramme de système ou d’appareil individuel ne peut pas être installé, ou s’il a été installé de manière incorrecte (par exemple, en raison d’un type d’altération ou d’une perte de courant lors de l’installation de la mise à jour), la mise à jour peut être retentée jusqu’à un total de trois (3) tentatives, y compris la première tentative. Si des tentatives supplémentaires sont effectuées par le microprogramme, le système ne doit pas démarrer dans Windows entre les tentatives. Si toutes les tentatives échouent, le microprogramme de mise à jour doit ignorer la mise à jour. Si la mise à jour a été partiellement appliquée, le microprogramme doit revenir à la version précédente. Le microprogramme doit revenir à la version précédente sans aucune interaction de l’utilisateur. L’échec de la mise à jour n’affecte pas les autres mises à jour en attente ; les mises à jour du microprogramme en attente doivent être tentées.
Une fois toutes les mises à jour traitées, UEFI reprend le démarrage de Windows. Le microprogramme UEFI doit vérifier que les mises à jour de microprogramme non validées ont été correctement installées afin d’atténuer les problèmes liés à la perte de courant (UEFI ne doit jamais tenter de démarrer Windows avec un microprogramme partiellement écrit).
Les causes possibles de l’échec de l’installation incluent, mais ne sont pas limitées aux problèmes suivants :
| Cause de l’échec de l’installation | Code d'erreur |
|---|---|
| Ressources insuffisantes | STATUS_INSUFFICIENT_RESOURCES |
| Perte de courant | STATUS_INSUFFICIENT_POWER |
| Défaillance matérielle | STATUS_POWER_STATE_INVALID |
La mise à jour du microprogramme réussit, mais Windows ne parvient pas à démarrer
Le microprogramme UEFI n’est pas responsable de la restauration du microprogramme mis à jour une fois qu’il a été commité. La logique de basculement existante dans Windows redirige l’utilisateur final vers l’environnement de récupération Windows (WinRE) après deux tentatives de démarrage infructueuses. WinRE peut ou non démarrer correctement. L’utilisateur final doit effectuer une étape de récupération manuelle pour récupérer son système, ou devra retourner son appareil au détaillant/fabricant.
Les causes possibles de cette classe d’échec sont notamment les suivantes :
Microprogramme incompatible avec les pilotes de système d’exploitation.
Microprogramme incompatible avec les composants du système d’exploitation.
Si un fournisseur de matériel décide d’implémenter une logique supplémentaire pour déterminer si Windows a démarré correctement, cela est acceptable. Comme mentionné précédemment, la couverture des tests de mise à jour du microprogramme par l’auteur du microprogramme empêche la plupart des crises résultant d’un microprogramme incompatible.
Articles connexes
Création d’un package de pilote de mise à jour
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour