Discussion :

[Lawyer666]

Bonjour à tous,

nous avons un projet initialement développé sous Visual 2005 qui est un wrapper C++/.Net : il permet de construire une DLL exportant des fonctions C et qui derrière appelle les fonction d'une DLL .Net (basé sur le framework 2.0). Tout fonctionnait bien.

Nous avons passé le projet sous Visual 2010. Et le programme qui appelle cette DLL wrapper plante directement à l'initialisation, avant même de rentrer dans le main, avec comme seul message d'erreur :

0xc0000005 Application failed to initialize properly

Ca plante uniquement en release, pas en debug.

J'ai remarqué que dans les propriétés du projet, dans Configuration Properties->Linker->Optimization, si je passe l'option References à No (/OPT:NOREF), il n'y a plus de plantage...

Je me demande donc ce que cela peut bien cacher, puisque si j'ai bien compris, cette option du linker permet de ne pas inclure dans le binaire les références des fonctions (de la dll .net dans mon cas) qui ne sont pas utilisées. Ce qui devrait donc ne rien changer au comportement du programme.

Je ne vois pas comment diagnostiquer ce problème étant donné que le programme plante avant même de rentrer dans le main et qu'aucun message d'erreur explicite n'est remonté.

Toute aide est donc la bienvenue ! Merci

[Neitsa]

Bonjour,

Je me demande donc ce que cela peut bien cacher, puisque si j'ai bien compris, cette option du linker permet de ne pas inclure dans le binaire les références des fonctions (de la dll .net dans mon cas) qui ne sont pas utilisées. Ce qui devrait donc ne rien changer au comportement du programme.

En fait c'est l'inverse. /OPT:NOREF garde toutes les fonctions et données même celles qui ne sont pas référencées.

Par défaut le mode DEBUG est à /OPT:NOREF, sûrement pour cela que ça ne crash pas en debug mais en release.

cf. /OPT:NOREF sur MSDN: http://msdn.microsoft.com/en-us/libr...VS.100%29.aspx

Je ne vois pas comment diagnostiquer ce problème étant donné que le programme plante avant même de rentrer dans le main et qu'aucun message d'erreur explicite n'est remonté.

Toute aide est donc la bienvenue ! Merci

Pour les problèmes d’initialisation de DLLs (ce qui semble être le cas, puisque ça crash avant le main() de l'executable), le mieux est d'utiliser "Gflags" des debugging tools.

* Démarre Gflags, puis onglet "image file"
* Tape le nom de l'exécutable, avec extension, mais sans chemin (ex: toto.exe) dans la boite prévue à cet effet.
* Appui sur la touche "tabulation" du clavier.
* Coche la checkbox "Show Loader Snaps".
* Bouton "apply", puis bouton "ok".

"Show Loader Snaps" permet de passer, en quelque sorte, le loader de Windows en mode "debug". Ca sort un paquet d'info sur le chargement de l'exécutable et des ses DLLs.

Pour voir le résultat, utilise un debuggeur, n'importe lequel (Windbg, VS, ntsd, OllyDbg, etc.) et charge ton programme avec. La fenêtre d'output devrait contenir les "loader snaps" avant le crash.

Une fois que tu as l'output, il faut voir ligne par ligne où ça coince. Certains messages d'erreur sont normaux (e.g. problèmes de "hints" dans l'import table), d'autres probablement pas. L'output est assez "hardcore" puisque ça traite de message bas niveau du système.

Si tu as un problème à diagnostiquer l'output, copie/colle le résultat dans un message ou attache un fichier texte contenant l'output de ta session de debug.

Une fois fini, n'oublie pas de revenir dans "Gflags" et de décocher "Show Loader Snaps" (+ "Apply" + "ok") pour ton programme.

Si les loader snaps ne donnent rien j'ai d'autres propositions, mais plus complexes.

Bon courage!

[Lawyer666]

Merci beaucoup pour ta réponse, je n'ai malheureusement pas eu le temps de tester ta procédure, je pense faire ça en début de semaine prochaine.
Et si jamais ça marche je passerai le statut en résolu

Par contre, je pense que le fait que ça fonctionne en DEBUG n'a rien à voir avec l'option, car qu'elle soit à REF ou NOREF, il n'y a jamais aucun plantage en debug. J'imagine que cela est dû à la gestion de la mémoire qui est différente en DEBUG...