le hotpatch KB5084897 demande un redémarrage

Bonjour FrancK,

Il est tout à fait compréhensible d'être surpris par une demande de redémarrage pour un hotpatch, car l'avantage principal de cette fonctionnalité est précisément de fournir des mises à jour de sécurité directement en mémoire sans exiger le redémarrage du système. Cependant, rencontrer cette requête pendant le processus est un comportement connu et prévu par le système sous certaines conditions spécifiques. La raison la plus fréquente est que votre poste de travail avait très probablement déjà un redémarrage en attente issu d'une installation précédente, comme une mise à jour d'antivirus, un nouveau pilote ou une autre mise à jour cumulative, ce qui oblige Windows Update à consolider l'ensemble du processus en un seul redémarrage global.

De plus, le mécanisme de hotpatching repose strictement sur un prérequis technique appelé la « baseline » (base de référence). Microsoft déploie une mise à jour cumulative servant de baseline environ tous les trois mois, et les hotpatches mensuels qui suivent sont conçus exclusivement pour s'injecter par-dessus cette base exacte. Si votre machine n'a pas reçu cette mise à jour de base ou se trouve légèrement désynchronisée par rapport au calendrier de déploiement de votre organisation, l'agent Windows Update détecte intelligemment cet écart. Pour garantir la stabilité et la sécurité du système, il va automatiquement basculer sur une méthode d'installation traditionnelle qui nécessite un redémarrage.

Enfin, il faut savoir que Windows intègre un mécanisme de sécurité de secours (fallback) dédié au hotpatching. Si le système d'exploitation rencontre le moindre conflit inattendu, un processus verrouillé ou une restriction de sécurité empêchant l'injection propre du code en mémoire, il annulera l'opération en direct pour privilégier une installation standard nécessitant un redémarrage. Il n'y a donc aucune erreur ou dysfonctionnement sur votre appareil. Il vous suffit d'effectuer ce redémarrage pour finaliser l'installation en cours, et votre système reprendra naturellement son cycle de hotpatching transparent lors des prochaines mises à jour.

J'espère que cette réponse vous a apporté des informations utiles. Si c'est le cas, n'hésitez pas à cliquer sur « Accepter la réponse ». Si vous avez des questions, n'hésitez pas à laisser un commentaire.

Tracy

Bonjour FrancK,

Merci pour ces captures d'écran très détaillées et pour votre suivi rigoureux. Votre analyse est tout à fait pertinente et vous avez mis le doigt sur une subtilité technique de l'orchestrateur Windows Update qui mérite d'être clarifiée.

Concernant l'affichage dans l'interface, votre frustration est totalement justifiée car l'interface utilisateur de Windows Update manque effectivement de granularité dans ce cas précis. Lorsque vous installez une mise à jour de pilote profond (comme votre extension Intel) ou certains modules Defender, Windows inscrit immédiatement un marqueur de redémarrage en attente (Reboot Pending) dans le registre système. Lorsque l'agent Windows Update initie ensuite le téléchargement du hotpatch KB5084897, il détecte ce marqueur de blocage. Pour éviter d'inonder l'utilisateur de multiples notifications de redémarrage, l'interface graphique consolide l'affichage et l'associe systématiquement au package du système d'exploitation le plus récent ou le plus visible dans la liste d'attente. C'est la raison pour laquelle Windows Update vous indique visuellement que c'est le hotpatch qui exige le redémarrage, masquant ainsi l'installation tierce qui est la véritable cause du verrouillage initial du noyau.

Votre excellente observation concernant le numéro de build, qui reste figé à la version 26100.7982 au lieu de passer à la 26100.7984, est d'ailleurs la preuve technique absolue que le mécanisme de sécurité (fallback) a fait son travail. Puisque le noyau Windows savait qu'il était dans un état transitoire en attente du rechargement de votre pilote Intel, le sous-système de hotpatching a strictement refusé d'injecter le code de la mise à jour OOB directement en mémoire vive, car modifier la mémoire d'un noyau en attente de redémarrage est un risque majeur d'écran bleu (BSOD). Par conséquent, l'injection à chaud a été intentionnellement avortée. Le système a simplement basculé sur une procédure classique en préparant les fichiers dans le magasin de composants (WinSxS). Le numéro de build ne s'actualisera en .7984 qu'au moment du redémarrage, lors de la phase de configuration hors ligne (avant l'écran de connexion), où le pilote et le hotpatch seront appliqués simultanément et proprement.

J'espère que cette explication vous a apporté des informations utiles sur la logique interne de ces mécanismes. Si vous avez d'autres questions, n'hésitez pas à laisser un commentaire.

Tracy.