none
Ma DLL charge msvcr80.dll dans system32 au lieu de winsxs, uniquement en debug RRS feed

  • Question

  • Bonjour,

    J'écris un programme avec VS2005 qui charge dynamiquement une DLL. Cette DLL est compilée sur mon PC avec les outils en ligne de commande de VS2005 (c'est un projet open source, qui utilise autoconf/automake, et à la fin le compilateur et l'éditeur de lien de VS2005.

    En debug je n'arrive pas à charger ma DLL (sur mon PC de dev), dans les traces en debug de VS2005 je vois :

    'testAPI.exe' : Chargé 'S:\testAPI\debug-win32\nsldap32v60.dll', Les symboles ont été chargés.
    'testAPI.exe' : Chargé 'C:\WINDOWS\system32\msvcr80.dll', Aucun symbole n'a été chargé.
    Exception de première chance à 0x7c9766c6 dans testAPI.exe : 0xC0000139: Entry Point Not Found.
    'testAPI.exe' : Déchargé 'S:\TestAPI\debug-win32\nsldap32v60.dll'
    'testAPI.exe' : Déchargé 'C:\WINDOWS\system32\msvcr80.dll'

    Il charge msvcr80.dll dans system32 et ne va pas le chercher dans WinSXS. Or, mon programme TestAPI.exe a bien un manifeste qui lui indique le numéro de version du CRT à utiliser. Je pensais que les DLL chargées par un programme utilisais forcément la même version du CRT que le programme principal. J'ai tenté d'incorporer le manifeste de la DLL généré lors de son build mais ça ne change rien. 

    En release ça fonctionne ! Pourquoi ?

    François

    samedi 30 octobre 2010 08:45

Toutes les réponses

  • Je pensais que les DLL chargées par un programme utilisais forcément la même version du CRT que le programme principal.


    Ce n'est pas le cas. Vous venez même de voir que vous pouvez utiliser une dll utilisant la C-Runtime en Release (msvcr80.dll et non le msvcr80d.dll qui elle est en Debug) dans un programme en Debug.

    Dependency Walker (http://www.dependencywalker.com/) devrait vous donner le nom de ou des dll qui utilisent la C-Runtime en Release. Cela ne pose pas de problème avec des API de Dll en C qui n'échangent pas d'objets ou de pointeur devant être libérés par un module différent de celui qui l'alloue.


    Paul Bacelar, Ex - MVP VC++
    lundi 1 novembre 2010 22:51
    Modérateur
  • Bonjour, merci pour votre réponse et la remarque sur le msvcr80d.dll.

    J'ai lancé le dependency walker sur ma DLL et il m'indique des erreurs et qu'elle dépend de c:\windows\system32\msvcr80.dll. Il y a donc un problème car elle est compilée avec une version plus récente, 8.0.50727.762 j'imagine (d'où les erreurs notifiées par dependency walker), puisque le fichier manifest qui est généré en même temps fait référence à cette version. J'ai essayé de coller ce manifeste à côté de ma DLL, et dependency walker n'affiche plus aucune erreur, et m'indique bien la dépendance dans winsxs sur 8.0.50727.762. Néanmoins, ma DLL n'est toujours pas chargée, et VS2005 m'indique qu'il charge toujours C:\WINDOWS\system32\msvcr80.dll.

    J'ai aussi essayé de recompiler la DLL en définissant ISOLATION_AWARE_ENABLED, mais ça n'a rien changé. Dois-je poursuivre dans cette direction ?

    Merci

    François

    mardi 2 novembre 2010 09:29
  • Désolé pour le délai de ma réponse.

    Vous commencez à vous aventurer dans des contrés que je n'ai pas moi-même exploré. :-\

    Pouvez-vous poster une version minimaliste d'un projet qui reproduit le problème ?

    Si oui, je verrais si le problème persiste avec VS2010 et j'essaierais de voir le problème "in-vivo".


    Paul Bacelar, Ex - MVP VC++
    lundi 8 novembre 2010 12:35
    Modérateur