Microsoft a terminé son enquête concernant les crashs apparus après le Patch Tuesday d’août. KB5121003 n’est finalement pas responsable, mais Windows va quand même neutraliser automatiquement le pilote problématique.
Vraiment sans provoc mais pour ma culture perso, si un pilote commence à planter après une mise à jour, comment on explique techniquement que c’est le pilote qui est en cause?
C’est parce que windows avait lui même été mal codé et que le pilote s’est greffée à cette erreur, qui du coup une fois corrigée/optimisé sous entend que c’est bien le pilote et pas windows qui est en erreur?
Windows, comme la plupart des systèmes modernes, est composé d’un espace utilisateur, où fonctionnent les applications, et d’un espace noyau, où fonctionne le système lui-même. Dans cet espace noyau, on trouve principalement du code Microsoft, mais également du code écrit par les fournisseurs de matériel, notamment les pilotes. Autant l’espace utilisateur est cloisonné afin qu’une erreur dans une application ne provoque généralement pas le plantage du système, autant le code exécuté dans l’espace noyau dispose d’un accès beaucoup plus direct aux ressources, notamment à la mémoire. C’est pourquoi une erreur à ce niveau peut entrainer un plantage complet du système.
Ensuite pour répondre plus précisement à ta question @Howely, on peut avoir par exemple des conditions temporelles (race condition en Anglais) qui expliqueraient le plantage du pilote suite au correctif de Microsoft: si deux processus s’éxécutent en parallèle et que dorénavant celui de Microsoft se termine plus rapidement, on peut avoir un pilote fournisseur qui n’est pas encore initialisé correctement et planterait. Il peut y avoir une infinité de raison, mais dans le cas de l’article la robustesse du code est remise en question côté fournisseurs.
Je me disais qu’il manquait un bout à ta réponse 
merci pour les 2 posts.
Mais tu vois dans ton exemple « si deux processus s’éxécutent en parallèle et que dorénavant celui de Microsoft se termine plus rapidement » c’est certes le pilote qui est en cause mais la finalité reste tout de même le patch qui a changé quelque chose, rendant la comptabilité non compatible si j’ose dire. Ca serait donc un problème de communication avant tout. Sauf si le fournisseur a trainé pour mettre à jour pré patch évidemment.
Je suppose que les fournisseurs ont des contrats d’interfaces à respecter, des modèles de conception à appliquer, pour être conforme à ce qu’attend Microsoft. Si ce n’est pas fait correctement on peut aboutir à ce genre d’incidents chez l’utilisateur final, car il y a tellement de jeux différents, de matériels plus ou moins récents et performants…
Oui, ça peut être le changement fait par Microsoft qui est le déclencheur du crash, sans pour autant que Microsoft ne soit responsable du crash.
Si on reprend l’exemple d’azureal, un crash provoqué par un changement de temps d’exécution du code de Microsoft, la cause réelle, c’est que le code qui crash n’a pas été fait correctement, et partait du principe que la partie Microsoft prenait toujours au moins un certain temps, alors qu’aucune spécification ne disait nulle part que ce temps était un minimum.
Si on veut faire une bonne vieille analogie automobile, imagine que chaque matin tu passes devant la sortie de garage de ton voisin à 8h pile, et que lui il partait chaque matin à 7h59 sans jamais s’arrêter, parce qu’il n’y avait jamais personne qui passait devant chez lui à cette heure. Si un matin tu es en avance de 1 minute et qu’il te rendre dedans, c’est bien ton avance qui a « provoqué » l’accident, mais c’est bien lui qui est responsable, parce qu’il avait pris la mauvaise habitude de sortir directement sans s’arrêter, considérant que personne ne passait à cette heure là, alors qu’aucune règle explicite ne le garantissait.