Discussion :

[Etienne Paquette]

Bonjour à tous, j'ai un problème assez particulier...

C'est une application développée à la base avec VS C++ (MFC) 2005 qui fonctionne très bien...

Je viens de migrer cette application vers VS 2010. Encore là, aucun problème. L'application tourne très bien sur ma machine de développement en mode release et debug et sur d'autres machines où VS 2010 est installé.. Mais petit problème lorsque j'essaie de rouler l'application sur une machine où VS 2010 n'est pas installé. L'application s'ouvre et se ferme sans message d'erreur autre que: l'application a planté et doit se fermer.

Bref je suis allé voir dans event viewer de la machine et voici le message d'erreur obtenu:

Faulting application PRIM.exe, version 1.0.0.1, faulting module msvcr100.dll, version 10.0.30319.415, fault address 0x0008cb95.

Pas trop bavard comme message d'erreur sinon que l'utilisation d'une classe MFC a fait planter mon application.

Je vous explique un peu l'architecture de mon Application:

J'ai une librairie qui contient mes classes qui ajoutent des fonctionnalités aux classes MFC
ex: CMyDialog dérive de CDialog, CEditNumber dérive de CEdit etc...
Tout ce module est compilé et produit une librairie que j'utilise dans mes autres modules.

Ensuite j'ai 8 DLL (MFC Extension) qui divisent mon application en différents Modules métier (Ces dll font appel bien entendu à la librairie précédente).

Puis j'ai mon exe qui gère la structure de l'application et qui appelle les classes contenues dans mes DLL.

J'ai mis des traceurs pour tenter de voir où le code arrêtait et il s'arrête sur le premier appel d'une fonction MFC (DoModal) provenant d'un objet d'une de mes DLL qui dérive de ma classe CMyDialog. Tous les appels aux classes MFC provenant du Exe fonctionnent très bien. c'est seulement lorsque j'appelle les classe MFC via mes DLL que ça plante et comme je le disais seulement si VS2010 n'est pas présent sur la machine.


Quelqu'un à rencontré ce genre de problème?

Merci pour votre aide

Etienne

[ram-0000]

Est ce que sur la machine où cela plante, tu as installé les redistribuables VS 2010.

Ce qui me fait pense à cela, c'est qu'avant, tu était en 2005 et que je suppose que cela fonctionnait. Maintenant, tu as migré d'environnement de développement vers VS 2010. Ton programme fonctionne sur ta machine de développement, ce qui est normal car ces redistribuables VS 2010 sont implicitement installés sur une machine de dev VS 2010.

Le binaire généré a changé de dépendances, avant il utilisait les redistribuables 2005, maintenant, c'est les redistribuables VS 2010 qu'il utilise et qu'il faut installer.

Tu trouveras le setup de ces redistribuables sur ta machine de dev (il faut rechercher un fichier qui s'appelle redit) ou bien sur le site Microsoft.

[bacelar]

Pour être sûr que c'est bien un problème de "Dll Hell" comme le suppute ram-000, j'installerais les outils de debugging Windows sur l'une machine où cela plante.
http://msdn.microsoft.com/en-us/wind...dware/gg463009

Cela permet d'avoir un fichier .dmp lors du plantage et de faire une autopsie du problème avec WinDbg ou VS.

P.S.: N'oubliez pas de générer les .pdb.

[Etienne Paquette]

Merci pour vos réponses...

en réponse à ta question ram-0000. Oui les packages de redistribution on été installé j'ai déjà tout vérifié de ce coté.

Bacelar je vais essayé ta suggestion à l'instant..

Mais voici quelques update concernant mon problème peut être que ce va vous aidé à m'aider

Tout d'abord le plantage que j'observait à la base sur les machine qui n'avait pas VS 2010 d'installé s'est avéré une mauvaise piste.

Je développais avec VS2005 sur un Vista pro 32bits... j'ai changé de machine et du même coup je me suis dis pkoi pas upgradé le compilateur en même temps.

Je suis maintenant rendu sur VS2010 sous Seven Pro 64bits. mes machines de test sont:
mon ancien pc vista 32 bit (sans VS 2010) et ça plante.
un serveur 2003 32 bit (sans vs 2010) et ça plante.
un pc WinXP 32 bit (sans VS2010) et ça plante.
et un PC Win7 64bit (sans VS2010) et ça plante.

Donc les 2 seule PC où ça ne plantais pas était le miens et celui de mon collègue tous deux en win7 64bit avec VS 2010 d'où ma conclusion erroné
que ça ne plantais pas seulement si VS2010 était installé.

Cependant je me suis rendu compte que le plantage sur la machine Win7 64bits ne donnait pas la même erreur que sur le machine 32bits.

alors j'ai maintenant tout les machine en 64 bits fonctionne correctement suite à l'application de cette solution:
http://support.microsoft.com/kb/976038
ce correctif est compris dans le sp1 de win7 (ce qui n'était pas installé sur ma machine de test mais qui était installé sur les pc de développement).


Donc le problème est toujours présent sur mes poste en 32bits.

mais voilà j'ai poussé plus loin ma recherche j'ai installé VS2010 sur mon PC Vista 32 bits. j'ai tout copier mes sources sur le PC et compilé le tout.

Puis miracle tout fonctionne.

Donc en résumé si je compile avec un windows 32bits mon application fonctionne partout. Si je compile avec un windows 64bits ça ne fonctionne que sur des poste en 64bits.

Désolé de vous avoir lancer sur de mauvaise piste au début maintenant que le probème se précise si vous avez des suggestions pour que je puisse utilisé uniquement mon PC de développement car c'est vraiment chiant d'avoir à tout compiler sur mon ancien PC.

Encore merci pour votre aide.

[bacelar]

Creusez le problème avec les outils de debugging Windows.

Il est clair que votre projet à aussi de gros problème de dépendance vis à vis de la machine de build, et ça c'est pas bien.

Vous devez pouvoir générer n'importe quelle version de votre exécutable (32bits/64 bits, ASCII/UNICODE, pour XP ou pour vista) sur n'importe quelle machine. C'est de la cross-compilation.

Il existe un certain nombre de constantes de compilation qui permettent de spécifier la plateforme cible.

[Etienne Paquette]

Merci pour la suggestion j'ai télécharger et installé WinDbg tel que suggérer je vais creusé d'avantage le problème avec cet outil et vous revenir avec d'avantage de détail.

Concernant la dépendance à la machine de build si c'est le cas. Cela à été fait bien malgré moi car j'ai toujours développé sur une machine 32 bits et je n'ai jamais eu de problème sur les postes de production (32 et 64 bits).

c'est seulement depuis mon nouveau PC de développement en 64bits que les problèmes sur les machines 32bits ne fonctionne pas bien.

J'ai vérifier tout les paramètres des mes différents module et tout semble correct.

Ce qui est drôle c'est que les appels à la librairie MFC via l'exécutable ne font pas planter. c'est lorsque mon exe appel une Classe d'une de mes DLL qui elle appel la librairie MFC que ça plante et ça plante vraiment lors de l'appel d'une fonction MFC qui interviens au niveau graphique Ex: je déclare une CDialog c'est ok .. j'initialise certaine variable dans le de dialog c'est ok .. j'appel DoModal.. ça plante.

Bref j'apprivoise le nouvel outil de debbugin et je vous reviens avec des détails. Merci encore.