Mon appli vc++2010 ne démarre pas

Bonsoir,

j'ai développé une application, que j'ai compilé en release sur un Visual C++ 2010 Express. J'ai joint à mon zip les dll de QT, et les différentes dépendances qui vont bien (des dll liées à mon projet)... Pourtant en essayant de lancer mon appli sur un autre PC pour tester je n'ai aucune erreur et rien ne se passe.
Je devrais au moins avoir un fichier de log (premières lignes de mon programmes) qui pourrait m'indiquer que mon appli a démarré. Nada !
J'ai essayé ensuite d'installer le vc_redist et ca n'a rien changé...
Je n'ai aucune info, aucun log, que dalle pour m'aider à me sortir de cette m!!!!...
Est-ce que quelqu'un a une idée ?

Mon appli utilise : QT (en shared), pcap (en shared), pion et différentes libs (en static). Je l'ai compilée sur un WinXP et je la teste sur un WinXP.
J'ai compilé les libs et l'appli avec l'option /MT (pour les devs et les tests, je passerai ensuite en /MD). Logiquement je ne devrais pas avoir de problème de libs redistribuables.

Ai-je oublié quelque chose de fondamental ?

Salutations
Tristan

Regarde si tu trouves des infos dans event-viewer (win+r / eventvwr)

Si tu as un problème de dépendances, normalement tu as un message t'avertissant que l'appli ne peut se lancer. D'habitude j'utilise depends.exe, mais c'est quand on m'avertit qu'il y a un problème de dépendance.

Essaye quelque chose de plus brutal à l'initialisation de ton programme genre une MessageBox.

Salut

merci pour ta réponse, malheureusement il n'y a rien qui concerne mon application dans les journaux (sécu, système et app).
Seulement un message disant que mon application ne trouvait pas la dll de Qt, mais je m'étais trompé de lib. Depuis je l'ai corrigée et je n'ai pas d'autre erreur dans les journaux et pas plus de message sur mon app...

Cependant j'ai pu observer une chose :
Si j'ouvre le gestionnaire des taches et que je lance mon appli, je la vois apparaitre dans les processus pendant 1 seconde et puis se fermer.

Ca m'indique simplement qu'elle s'ouvre... et qu'elle crashe probablement mais j'ignore la raison... Impossible à déterminer sans une log convenable... Peut-être y a-t-il un moyen de paramétrer le gestionnaire de logs de windows ?

La dernière fois que j'ai vu ce comportement, c'était à cause d'un antivirus. Peut être faut-til desactiver toute protection au runtime et voir si il y a un impact.

Si ce n'est pas ça et qu'il n'y a aucune trace (prompt ou autre), il y a peu de chance pour qu'elle "crash". Vérifie plutot que les conditions de sortie ne sont pas immédiatement validées, ou que tu n'appelle pas std::exit() ou autres dans le genre dans le code.

L'autre alternative, c'est que ton executable ne contiens pas ce que tu penses qu'il devrait contenir.
Vérifie déjà ça.

Si c'est bon, alors vérifie qu'il n'y a pas une condition qui survient sans que tu le veuilles.

En effet ça peut être l'antivirus; sinon je mettrais l'application en OllyDbg pour voir où est le problème. Mais il faut connaitre un peu d'asm

Bon alors je suis un peu confus... le crash venait d'un bug dans mon programme... Ce qui m'étonne le plus c'est qu'aucun message d'erreur ne se soit affiché, même pas dans la sortie standard... Quoi qu'il en soit j'ai pu m'en sortir ! Désolé de vous avoir dérangé pour rien ! :oops:

Tu peux être plus précis au niveau du bug qui causait le crash stp? C'est une information très utile pour tout le monde.

t'es vache, tu m'obliges à me ridiculiser en public... tellement mon erreur est stupide ;)

Mon problème venait du fait que j'ai ajouté il y a quelques jours une fonctionnalité à ma classe de logging perso. Cette fonctionnalité consistait à logger aussi dans un fichier texte.
D'un autre côté dans mon code original le processus de démarrage se déroulait ainsi :
1 - Initialisation des variables
2 - Messages de log
3 - Vérification de l'environnement (répertoire de data de l'appli etc...)
4 - Le reste...

Sur mon environnement de dev tout fonctionnait après l'ajout du logging texte car l'environnement existait, et en particulier le répertoire dans lequel je voulais stocker la log.

Mais sur mon environnement de test, le répertoire n'existait pas puisque mon programme sortait tout juste du setup. Il a suffit que j'intervertisse les étapes 2 et 3 pour résoudre mon problème.

Ce qui me trouble quand même c'est que tout soit resté parfaitement muet et que ca ait crashé l'appli. Normalement ca n'aurait pas du crasher l'appli, le problème d'accès aux fichier... M'enfin the show must go on alors je n'irai pas plus loins dans mes questionnements.

Tristan

Aucune erreur n'est stupide...si on en apprends quelque chose au passage ;)


Sinon, c'est bizarre qu'il n'y ait aucune trace quand on tente d'écrire un fichier dans un dossier qui n'existe pas. Je vais essayer chez moi voir ce que ça fait, parcequ'il me semble qu'il y a bien une tache.

Citation:

---

Envoyé par esteban

t'es vache, tu m'obliges à me ridiculiser en public... tellement mon erreur est stupide ;)

Mon problème venait du fait que j'ai ajouté il y a quelques jours une fonctionnalité à ma classe de logging perso. Cette fonctionnalité consistait à logger aussi dans un fichier texte.
D'un autre côté dans mon code original le processus de démarrage se déroulait ainsi :
1 - Initialisation des variables
2 - Messages de log
3 - Vérification de l'environnement (répertoire de data de l'appli etc...)
4 - Le reste...

Sur mon environnement de dev tout fonctionnait après l'ajout du logging texte car l'environnement existait, et en particulier le répertoire dans lequel je voulais stocker la log.

Mais sur mon environnement de test, le répertoire n'existait pas puisque mon programme sortait tout juste du setup. Il a suffit que j'intervertisse les étapes 2 et 3 pour résoudre mon problème.

Ce qui me trouble quand même c'est que tout soit resté parfaitement muet et que ca ait crashé l'appli. Normalement ca n'aurait pas du crasher l'appli, le problème d'accès aux fichier... M'enfin the show must go on alors je n'irai pas plus loins dans mes questionnements.

Tristan

---

Tu es sûr que tu n'as pas mis un truc du style "if (error) return X ?"

Parce que ça sent plutôt la sortie non prévue par le programmeur, mais prévue par le programme. Dans son infinie sagesse, Windows récupère l'ensemble des exceptions non gérées par le programme, et affiche une boite de dialogue. Donc en cas de sortie complètement imprévue, Windows fait quelque chose.

Par contre, en cas de sortie tout ce qu'il y a de plus légitime, Windows ne va pas te dire que le programme ne fait pas ce que tu veux faire :)