Le message nomme un fichier précis, alors le réflexe paraît logique : chercher ce fichier, le télécharger, le déposer au bon endroit. C'est la manoeuvre qui transforme une panne bénigne en problème durable, et elle mérite qu'on explique pourquoi.
Une bibliothèque n'existe pas toute seule
Une DLL est livrée avec un ensemble : un runtime, un pilote, une application. Les fichiers de cet ensemble sont compilés ensemble et se répondent par des versions internes précises. Déposer un exemplaire venu d'ailleurs peut faire disparaître le message d'origine tout en créant un décalage de version qui ressortira plus tard, dans un autre logiciel, sous une forme que plus personne ne reliera au geste initial. Le symptôme se déplace, il ne se règle pas.
Le risque qui n'est pas théorique
Les sites qui proposent des bibliothèques à l'unité constituent l'un des vecteurs de logiciels malveillants les mieux documentés. Le fichier attendu porte le bon nom, s'installe sans rien demander, et rien ne distingue à l'oeil une copie saine d'une copie modifiée. Personne ne vérifie la signature d'un fichier de quelques centaines de kilo-octets récupéré dans l'urgence, et c'est exactement sur ce moment que ces sites comptent.
La confusion des deux dossiers
Elle mérite d'être connue parce qu'elle est contre-intuitive. Sur un Windows 64 bits, le dossier System32 contient les bibliothèques 64 bits, et c'est SysWOW64 qui contient les 32 bits. Les noms disent l'inverse de ce qu'ils font, héritage d'une compatibilité ancienne. Déposer une bibliothèque 32 bits dans System32 ne produit donc pas une erreur claire mais un refus de chargement, souvent interprété comme un fichier corrompu, ce qui relance la recherche d'un nouvel exemplaire et le cycle recommence, comme le montre le cas de Regsvr32.
Ce qui répare réellement
Identifier le paquet auquel la bibliothèque appartient, puis réinstaller ce paquet depuis sa source officielle. Un nom commençant par msvcp ou vcruntime renvoie aux redistribuables Visual C++, à installer dans les deux architectures ; un nom en d3dx ou xinput renvoie au runtime DirectX pour utilisateur final ; un nom en api-ms-win-crt relève des composants système, donc des mises à jour de Windows. Quand le fichier appartient au système lui-même, deux commandes suffisent le plus souvent : celle qui répare l'image du système, puis celle qui vérifie les fichiers protégés. L'ordre compte, la seconde s'appuyant sur la première pour retrouver une source saine.
Le point de départ, toujours le même
Lire le nom exact du fichier et l'application qui le réclame. C'est cette paire qui désigne le paquet à réinstaller, et c'est la seule information dont on ait réellement besoin, comme le rappelle notre présentation des fichiers DLL.
