Microsoft Update, programme de Mise à Genoux ? ( Une enquête du commissaire Mouline)
Depuis peu de temps, sur cinq machines de test, deux des ordinateurs de CSO France se sont mis à adopter un train de sénateur. Nulle installation de nouveau logiciel, par le plus petit virus, pas même l'ombre d'un de ces sympathiques spywares commerciaux connu des principaux outils de détection -Windows Live One Care y compris, histoire d'en vérifier le bon fonctionnement au passage-. Mais indiscutablement, un SvcHost émettait le désir d'occuper 95 % des ressources CPU. Et c'est sur l'appel d'un autre primo-informatisé - Au secours, mon ordinateur mouline ! - que la rédaction comprit enfin : il était manifeste que « quelque chose » s'était passé de façon générale en particulier. Et réciproquement.
Et lorsqu'un processus devient un peu trop gourmand, même le plus ignare des plumitifs n'a qu'un réflexe : il dégaine Process Explorer, oeuvre de Mark Russinovich. Lequel Process Explorer lui indique une fuite de mémoire provoquée par un certain RtlAllocateHeap. Thread dont le meurtre de sang froid provoque à son tour un assainissement de la situation et un retour à 97% des « processus inactifs ».
Quelques reboot et tâtonnements plus tard et un oeil humide de reconnaissance fixé sur la ligne bleu des PID Russinovichiens, un fait semblait clair : cette fuite de mémoire semblait directement liée à un service particulier, wuauclt, celui là même qui est chargé de la récupération des « rustines » Microsoft, l'indispensable Windows Update. Une désactivation dudit service via la mmc confirmait la chose : plus jamais svchost ne se permettait d'écrouler les ressources CPU.
Après avoir vérifié que les différents problèmes et correctifs contenus dans la « knowledge base » de Microsoft étaient incapables de contourner cet avatar, et ayant estimé qu'il était plus dangereux de désactiver ad vitam aeternam les mécanismes de mise à jour, il ne restait plus qu'à découvrir l'arme du crime. Et les possibilités étaient restreintes : Wuaudt.exe lui-même, les systèmes de mise à jour des serveurs Microsoft Update, et les « anciens » serveurs de mise à jour Windows update. Ne laissons pas planer plus longtemps le suspens : le retour à l'ancienne méthode de mise à niveau -via l'interface web des « settings » de Microsoft Update- résout définitivement la question. Sur les trois machines incriminées, cela va sans dire. Microsoft Update partit tout droit en quarantaine, rejoignant ainsi la longue liste des Troyens Java, des Blaster et des héritiers de Jerusalem B.
Ce qui nous en fait poser une autre, de question : Pour quelle raison Microsoft aurait modifié, ces dernières semaines, les procédures de distributions de rustines ? Sans prévenir les usagers d'un risque marginal, certes, mais réel ? Ce « bug sélectif » * serait-il en rapport avec la sortie de Vista ? Ou serait-ce une pure coïncidence ? Car les coïncidences, c'est là leur véritable nature, sont généralement soit surprenantes, soit fâcheuses, plus rarement heureuses, soit, comme ce semble être le cas ici, une combinaison de tout çà. Et lorsqu'une coïncidence est à la fois surprenante et fâcheuse, ce n'est plus une coïncidence, c'est manifestement un bug.
Comme il semble que ce mois de mars soit placé sous le signe de la paix des déploiements, et qu'aucune rustine ne devrait être publiée en ce prochain « patch Tuesday », voilà qui permettra aux usagers de se plonger calmement dans les arcanes de la gestion des services.
*ndlr : sélectif, car il ne semble reproductible que sur certaines machines, équipées notamment de la suite office -principal vecteur d'adoption de Microsoft Update-. Pour revenir à l'antépénultième édition du moteur de mise à jour, activer d'une action de la souris le menus « modifier les paramètres » situé dans la colonne de gauche de l'écran, puis cocher en bas de page la ligne « Désactiver le logiciel Microsoft Update et utiliser Windows Update uniquement ». Inutile de préciser que le moteur proteste avec l'énergie du désespoir, mais il faut savoir rester ferme avec les machines.
