Module LoadLibrary introuvable - DLL Hell After Office 2007 Installer

Question

Malheureusement, cela va être une question assez ouverte, mais je suis à bout de nerfs et je pensais que je voudrais demander conseil.

Il s'agit d'une application Visual C++ MFC utilisant Visual Studio 2008 SP1. Un collègue et moi avions Office 2007 installé et nous avons tous les deux eu des problèmes de chargement DLL étranges avec notre application depuis. Plus précisément, LoadLibrary ne parvient pas à charger l'une de nos DLL (la première qu'il charge) et renvoie le code d'erreur 126 (module introuvable). Ce qui est vraiment étrange, c'est que si je lance l'exécutable depuis l'explorateur Windows, ça fonctionne très bien.

Je pris les mesures habituelles pour diagnostiquer les problèmes:

1. Vérifiez que le fichier existe et que le répertoire de travail courant a été braqué sur lui.
2. Exécutez le programme de surveillance des dépendances et vérifiez que les dépendances se chargent correctement. Ils sont tous en train de charger, sauf ceux this question qui disent ok.
3. Expérimentez avec le chargement de DLL différentes au même emplacement dans le code. Certaines des simples DLL «stub» réussissent, mais la plupart d'entre elles échouent.
4. Expérimentez avec le chargement des DLL qui échouent à partir d'applications de test distinctes - dans une application de console vide et une application MFC barebone, toutes les DLL se chargent bien!
5. Essayez de charger les DLL avec LoadLibraryEx et l'indicateur LOAD_LIBRARY_AS_DATAFILE, ce qui réussit mais ne nous amène pas très loin, sauf pour signaler qu'il s'agit probablement d'un problème de dépendance.

Je ne sais vraiment pas quoi faire d'autre à ce stade. Comme je l'ai dit, Office 2007 est un point commun dans notre problème mais je ne sais pas quel genre de problèmes il pourrait créer. Je ne sais vraiment pas quelles sont les étapes à suivre. Des idées? Edit: Je suis assez sûr que le répertoire de travail actuel n'est pas dans le chemin de la DLL pour une raison quelconque. Il semble que les DLL qui échouent sont celles qui ont besoin d'autres DLL. Si j'active la sortie de débogage Loader Snaps, le répertoire de travail en cours ne semble pas se trouver dans le chemin de chargement de la DLL. Une idée de ce qui pourrait causer cela? Edit2: La compilation en cours a déchargé l'exécutable dans un répertoire autre que le répertoire de travail. Pour une raison quelconque, lorsque j'ai essayé de charger une DLL qui a ensuite essayé de charger une autre DLL, le répertoire de travail en cours n'est plus recherché. En mettant l'exécutable dans le répertoire avec toutes les DLL que j'essaye de charger, les problèmes disparaissent. Sur la base de tout cela, et de la sortie par les accrochages du chargeur, je suis sûr à 98% que c'est un bogue bizarre de Visual Studio et je vais simplement devoir le contourner.

Answer 1

Office 2007 active SafeDllSearchMode dans le Registre.

http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx

Avec SafeDllSearchMode, le répertoire actuel n'est recherché plus. Pour le désactiver, ils prétendent que vous pouvez aller dans regedit et définir HKLM/System/CurrentControlSet/Control/SessionManager/SafeDllSearchMode à 0, mais cela n'a pas fonctionné pour moi. L'appel de SetDllDirectory au répertoire actuel DID fonctionne pour moi, bien que cela ne fonctionne que si vous ciblez XP SP1 +.

La raison pour laquelle cela a causé des problèmes dans mon application spécifique est que lorsque nous exécutons l'exécutable à partir du débogueur, nous gardons l'exécutable dans un répertoire différent du répertoire actuel avec tous les autres fichiers de construction. Lorsque nous exécutons en dehors de Visual Studio, nous copions d'abord l'exécutable dans le répertoire avec toutes les autres DLL. Le répertoire dans lequel l'exécutable d'origine est appelé est TOUJOURS dans le chemin de recherche, donc si vous conservez votre exécutable et vos DLL ensemble, vous ne rencontrerez jamais ce problème.

Néanmoins, il est assez déroutant pour Microsoft de changer le chemin de recherche dll sous nous comme ça.

Answer 2

La DLL qui échoue a MSVCRT80 dans les dépendances? Si oui, la raison la plus probable est qu'Office 2007 a remplacé MSVCR80.dll