Discussion :

[esteban]

Hello !

Bonne année à tous !

J'ai une application compilée en mode debug, livrée avec les dll qui vont bien (y compris msvcrt etc cie) et sur certains windows elle plante dès le lancement avec un message grotesque du debugger c++ (abort) parfaitement inutile.

Ces machines ont en commun d'avoir une politique de restriction de services importantes : des policies de groupe pour l'une et peu de services démarrés pour l'autre...

Du coup ma question est la suivante : Le debugger c++ de visual studio 10, ou bien une appli en mode debug nécessite-t-elle des services particuliers ou des droits spéciaux pour démarrer.

Il semblerait que le crash ne soit pas du à mon code, il survient très tôt avant même que mon fichier de log ne soit ouvert par mon programme...

Sur d'autres machines Windows non paramétrées (normales) l'appli démarre parfaitement en debug.

Any idea ?

Tristan

[Médinoc]

Que se passe-t-il si tu la lances avec Start Debugging (F5) sur les machines en question?
(je suppose qu'il y a Visual installé sur les machines en question, car légalement tu n'es pas censé distribuer une application compilée de mode Debug, la license de la version Debug de la C Run-Time Library l'interdisant)

[esteban]

Je te remercie pour ta réponse.

Les machines sur lesquelles le test est fait sont des machines sur lesquelles je fais du test (en alpha disons). Je n'ai pas installé visual studio puisque je veux des machines qui ressemblent à des machines cibles.
De là à dire que fait du déploiement...

Du coup je ne peux pas répondre à ta question. Peut-être devrais je faire mon test avec une version release ?

[Médinoc]

Je vois.
Tu peux peut-être essayer:

• En Release pour voir s'il y a une différence de comportement (c'est toujours un indice)
• Avec le Remote Debugger d'installé et s'éxécutant sur une machine cible, pour déboguer depuis ton poste (puisqu'apparemment, tu n'arrives pas à reproduire le bug sur la machine où tu as Visual)

PS: Poste le message d'erreur en question, histoire qu'on soit sûr qu'il est aussi inutile que tu le dis.

[esteban]

Je suis en train de compiler une release.

Voici le message d'erreur en question. Habituellement ce même message indique un pointeur intelligent nul... Mais là je n'ai aucun moyen de le savoir...

[Médinoc]

Ah tu as raison, même pas une assertion qui échoue ou un numéro de ligne...

PS: Est-ce un programme graphique ou console?

[esteban]

C'est un programme en pur C++ utilisant QT pour la partie graphique.

le point d'entrée est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int WINAPI WinMain(HINSTANCE hinstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {

[esteban]

En utilisant la version release j'ai au moins la possibilité de récupérer un dump... je suis pas beaucoup plus avancé, à moins de savoir comment le lire
je vais chercher des posts sur le sujet.

[esteban]

Et si j'ai l'offset : 001120ca... je peux retrouver la ligne qui correspond à l'erreur ?

[Médinoc]

Avec juste l'offset, pas sûr. La Stack Trace serait plus intéressante.

Et donc, tu n'as pas de console, donc rien qui puisse logguer *pourquoi* abort() a été appelée...
Tu peux toujours essayer de le lancer dans un invite de commandes, à tout hasard, mais il y a assez peu d'espoir de ce côté.

[esteban]

Avec juste l'offset, pas sûr. La Stack Trace serait plus intéressante.

C'est bien ce que je me disais mais je n'ai même pas cette possibilité. Windows ne me propose que un sale fichier appcompat.txt... dans lequel je n'ai que la liste des modules ou librairies chargées avec le programme.