none
Probleme chargement mfc90.dll, msvcr90.dll RRS feed

  • Question

  • Bonjour,

     

    je compile un gros projet avec Visual Studio 2008. Tout se passe bien jusqu'à l'exécution de mes programmes. 

    Mon projet contient de nombreuses dll, chargées par différents programmes. Lorsque le programme charge les dll msvcr90.dll, mfc90.dll, celles-ci sont bien trouvées dans le répertoire c:\Windows\WinSxS.

    Lorsqu'un programme ne charge pas les dll msvcr90.dll et mfc90.dll, celui crash en m'indiquant qu'il ne trouve pas ces dll.

    J'ai donc vérifié à l'aide de l'outil depends quelles dll étaient chargées par mes propres dll. Il se trouve que mes dll sont incapables de trouver les dll dans le répertoire c:\windows\WinSxS.

    Je ne vois pas d'ou peut venir mon problème. Les manifest semblent corrects, puisqu'ils sont identiques entre un programme qui charge les dll mfc90.dll et msvcr90.dll et les dll qu i n'arrivent pas à les charger.

    Merci de vos réponses.

    mercredi 18 août 2010 11:45

Réponses

  • Dependency Walker est un outil d'analyse statique donc facile d'emploi mais ne permet de vérifier qu'une hypothèse (dll manquante).

    Process Monitor est un outil de tracking sur un process en exécution donc verbeux et plus difficile d'emploi mais il donne des fait et avec aucune hypothèse. Process Monitor vous donnera de manière non-équivoque, le nom de le dll cherchée ainsi que tous les répertoire dans laquelle cherche votre OS. Ainsi que le motif de l'échec comme droit d'accès ou absence.

    Quand je suis dans le brouillard, j'ai l'habitude de collecter des faits avant d'émettre des hypothèses.

    mt.exe n'est pas obligatoire mais faire un manifeste à la main est loin d'être une sinécure. Avec des faits, vous pourrez voir si les paramètres passés à mt.exe et le manifeste généré sont correcte ou non, si c'est un problème de droit, d'installation des dll, ou de copie etc...


    Paul Bacelar, Ex - MVP VC++
    • Marqué comme réponse Alex Petrescu lundi 6 septembre 2010 08:06
    mardi 31 août 2010 14:53
    Modérateur

Toutes les réponses

  • Vous utilisez peut-être malheureusement, plusieurs versions de ces dlls (directement ou indirectement via des librairies tierces).

    Utilisez un outil comme Process Monitor (http://www.microsoft.com/france/technet/sysinternals/ProcessesAndThreads/processmonitor.mspx) pour voir les requêtes de l'OS sur le système de fichier et ainsi savoir précisément le nom et le chemin de la dll manquante.


    Paul Bacelar, Ex - MVP VC++
    dimanche 29 août 2010 21:04
    Modérateur
  • Merci de votre réponse.

    Mes investigations avec Dependency Walker m'ont confirmé le fait que les versions des dll c-runtime utilisées sont les mêmes.

    La compilation est lancée via des lignes de commande, et non pas depuis l'interface de Visual Studio, et j'ai remarqué que dans ce dernier, l'utilitaire mt.exe était utilisé à la fin du processus de compilation.

    Est-il obligatoire pour la création du manifest? Ce qui est assez étonnant, c'est que les applications créées avec le même processus de compilation soient OK.

    lundi 30 août 2010 11:18
  • Dependency Walker est un outil d'analyse statique donc facile d'emploi mais ne permet de vérifier qu'une hypothèse (dll manquante).

    Process Monitor est un outil de tracking sur un process en exécution donc verbeux et plus difficile d'emploi mais il donne des fait et avec aucune hypothèse. Process Monitor vous donnera de manière non-équivoque, le nom de le dll cherchée ainsi que tous les répertoire dans laquelle cherche votre OS. Ainsi que le motif de l'échec comme droit d'accès ou absence.

    Quand je suis dans le brouillard, j'ai l'habitude de collecter des faits avant d'émettre des hypothèses.

    mt.exe n'est pas obligatoire mais faire un manifeste à la main est loin d'être une sinécure. Avec des faits, vous pourrez voir si les paramètres passés à mt.exe et le manifeste généré sont correcte ou non, si c'est un problème de droit, d'installation des dll, ou de copie etc...


    Paul Bacelar, Ex - MVP VC++
    • Marqué comme réponse Alex Petrescu lundi 6 septembre 2010 08:06
    mardi 31 août 2010 14:53
    Modérateur
  • Bonjour,

     

    Fat52, je vous prie de nous tenir au courant si les investigations avec l’outil proposé par M. Bacelar vous apportent plusieurs informations et si vous avez encore besoin d’assistance.

     

    Cordialement,

    Alex

    ________________

    Publiez un article sur une de ces technologies : Visual Basic, C#, C++, .NET, ASP.NET, SQL Server, Silverlight, SharePoint 2010, SharePoint 2007

    Astuces pour Visual Studio 2010

    XNA – Développement jeux vidéo

    Didacticiels et astuces : VB.NET, C#, ASP.NET, .NET Framework, Silverlight, Workflow Foundation, WPF

    Café des usages

    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

     

     

    mercredi 1 septembre 2010 09:56
  • La solution de Paul ne me convient pas.

    Je ne peux pas utiliser un outil de tracing en exécution d'une application qui ne se lance pas... donc encore moins sur une dll...

     

    Je vais essayer de réexpliquer mon problème : 

    - une application, compilée en ligne de commande avec Visual Studio 2008, génère un manifest, et arrive à correctement charger les dll c-runtime depuis le répertoire C:\Windows\WinSxs

    - une dll, compilée aussi en ligne de commande avec Visual Studio 2008, génère un manifest, identique à celui de l'application citée ci-dessus, ne trouve pas les dll c-runtime dans le répertoire c:\Windows\WinSxs

    Si mon application charge les dll c-runtime nécessaires à ma dll, l'exécution se passe bien. Si elle ne charge pas toutes les dll c-runtime nécessaires à ma dll, mon application ne se lance pas (message d'erreur : dll manquante). 

     

    Pourquoi ma dll ne trouve t-elle pas d'elle même les dll c-runtime? alors que les option de compilation sont équivalentes entre une application et une dll.

     

    Merci de votre réponse.

    lundi 6 septembre 2010 12:54
  • C'est justement l'intérêt d'un outil de tracking, car il est lancé AVANT votre application et donne le problème EXACTE. (Telle dll chargé après telle autre ne trouve pas telle autre.)

    Avez-vous au moins essayé avant de dire que ce n'est pas intéressant.

    Ne commencez pas par chercher une explication, commencez car récolter des faits.


    Paul Bacelar, Ex - MVP VC++
    lundi 6 septembre 2010 16:41
    Modérateur
  • Je crois qu'on n'est pas DU TOUT sur la même longueur d'onde.... Je ne vois pas pourquoi les informations dependency walker ne suffit pas à justifier mon problème... les informations données par ce dernier sur une application sont correctes, les dll c-runtime sont bien trouvées... les informations données sur une dll ne trouvent pas les dll c-runtime.... je vois pas ce que je peux obtenir de plus comme informations.... 

     

    mardi 7 septembre 2010 07:38
  • Dependency Walker est un outil qui fait une analyse statique, avec les droits de l'utilisateur qui lance l'outil, dans un répertoire de travail qui ne correspond pas à celui de l'exécution, etc...

    C'est peut-être inadapté mais ayez au moins la politesse d'essayer.

    Merci


    Paul Bacelar, Ex - MVP VC++
    mardi 7 septembre 2010 09:33
    Modérateur
  • J'avais déjà essayé de l'utiliser mais ce ne fut pas convaincant, et aspiré par d'autres taches, je n'avais pu creuser plus.

    Donc suite à un nouvel essai de process monitor... eh bien je ne sais comment interpréter les résultats... ni lesquels... si vous pouviez éclairer un peu plus ma lanterne sur le sujet

    Pour ajouter aux informations concernant le sujet, si je place les dll c-runtime directement dans le répertoire ou se trouve mes dll, l'éxecution de mon programme se passe bien.

    vendredi 10 septembre 2010 14:01
  • - Lancer Process Monitor, configurez le pour qu'il récupère les requêtes sur le système de fichier si ce n'est pas le cas par défaut.

    - Lancer le tracking.

    - Lancer votre application qui plante.

    - Attendre le plantage

    - Arrêter le tracking

    -Utilisez les options de filtrage pour n'avoir que les requêtes de votre processus et sur les dll qui vous posent problème.

    Vous aurez ainsi les demandes d'accès aux fichiers des dll fait par le loader de Windows dans l'ordre chronologique.

     

    Regarder les remarques sur de l'article suivant : http://msdn.microsoft.com/en-us/library/ms235342(v=VS.90).aspx

    Et postez nous les manifestes qui sont important en fonction des remarques que donne cet article.

     


    Paul Bacelar, Ex - MVP VC++
    vendredi 10 septembre 2010 16:20
    Modérateur