Pb compilation : "is not a valid executable file"

Bonjour,

J'ai récemment ouvert un sujet qui commençait par un autre problème, et marqué comme résolu...mais pas tout à fait. Reprenons.

J'étais sur un poste NT avec VC6.
j'installe VC6 sur un autre poste (XP) et je lui applique le Service Pack 6 (j'ai cru un moment que ça avait résolu le problème)
Tous mes projets et sources sont sur un lecteur réseau.

Je compile et j' exécute sans problème en debug et release sur mon poste NT.
Je compile et j'exécute sans problème en release sur mon poste XP, mais en debug, l'exécutable généré provoque cette erreur ... is not a valid executable file.

Il s'agit vraiment de l'exécutable produit car si je le compile sur le poste NT et que je l'exécute en debug depuis le poste XP, ça fonctionne....***


***enfin presque car quand Visual atteint le point d'arrêt, il m'ouvre une fenêtre "Find Symbols" avec "Please enter the path for nafxcwd.pdb" en m'écrivant par défaut e:\8168\vc98\mfc\mfc\lib dont je ne sais pas d'où ça vient étant donné que dans les paramètres de Visual j'ai bien C:\Program Files\Microsoft Visual Studio\VC98\MFC\INCLUDE mais bon, en faisant cancel ça veut bien continuer quand-même...

Mais d'où peut venir ce problème dans l'exe de debug?!
Indice : l'exe sous XP fait 1129 ko alors que sous NT il fait 1113 ko

Ca n'inspire personne on dirait...ça ne m'étonne pas, la MSDN de Microsoft n'est pas inspirée non plus...

vérifies les paths dans le parametrage général de vc6.0: tools\options\directories.

Citation:

---

Envoyé par farscape

vérifies les paths dans le parametrage général de vc6.0: tools\options\directories.

---

Non, il n'y a pas de problème là-dessus a priori; j'ai remis le même genre de configuration que sur l'autre poste. Toutes les librairies y sont (d'ailleurs comment ça pourrait compiler, et s'exécuter en release s'il manquait quelque chose?)

pas forcement nafxcwd.pdb c'est utile au mode debug uniquement..

Tu as raison mais ce fichier est bien présent à la fois sur mon poste et dans le Directories :
C:\Program Files\Microsoft Visual Studio\VC98\MFC\LIB

donc ça doit être autre chose

tu devrais faire une recherche sur le path:
e:\8168\vc98\mfc\mfc\lib
il doit bien être quelque part .
vérifies tes variables d'environnement sur ton poste.

Citation:

---

Envoyé par farscape

tu devrais faire une recherche sur le path:
e:\8168\vc98\mfc\mfc\lib
il doit bien être quelque part .

---

Je peux t'assurer que je n'ai aucun lecteur de lettre "E", d'ailleurs quand je vais dans l'explorateur et que je tape e:, ça ne trouve logiquement rien

Citation:

---

Envoyé par farscape

vérifies tes variables d'environnement sur ton poste.

---

Ah, idée intéressante, mais que dois-je chercher?
En rapport avec Visual, je ne vois que la variable VS80COMNTOOLS positionnée à C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\
(mais je ne l'avais pas sur mon poste NT cette variable, ce qui ne l'empêchait pas de fonctionner), pas de e: non plus sur ce poste d'ailleurs

alors dans ta base de registre ...

Citation:

---

alors dans ta base de registre ...

---

Peux-tu spécifier ce qu'il faut que je fasse exactement et ce qu'on cherche?
je me trompe peut-être mais cette histoire de E:\ peut être une fausse piste (ça, c'est jsute quand j'exécute l'exécutable créé par le poste NT sous le Visual du poste XP) : le principal problème est pourquoi le Visual du poste XP fabrique mal l'exécutable de debug

Toujours là?

Citation:

---

Envoyé par stof

Peux-tu spécifier ce qu'il faut que je fasse exactement et ce qu'on cherche?
je me trompe peut-être mais cette histoire de E:\ peut être une fausse piste (ça, c'est jsute quand j'exécute l'exécutable créé par le poste NT sous le Visual du poste XP) : le principal problème est pourquoi le Visual du poste XP fabrique mal l'exécutable de debug

---

heu rassures moi.
tu es en train d'exécuter un programme en debug sur un autre poste que celui qui l'a généré ?
si c'est le cas il ne faut pas s'attendre a avoir des bizarreries sur la recherche d'un fichier binaire surtout sur deux postes avec des os différents.
on distribue un programme en release pas en debug.
si c'est pour debuger il y a d'autres options comme activer la génération des informations de debug de mappage etc pour la version release.
dr watson faisant ensuite le reste.

Bonjour,

Allez, faut que je trouve cette semaine.

Bon alors oui, j'ai ESSAYE de compiler sur le poste NT et d'exécuter l'exe de debug produit sous le Visual du poste XP pour voir si c'est l'exécution qui lui posait problème, c'est tout.
ca a confirmé que c'est la génération de l'exe de debug qui fonctionnait mal sous le Visual du poste XP.

Maintenant que faut-il faire exactement dans la direction

Citation:

---

activer la génération des informations de debug de mappage etc pour la version release.
dr watson faisant ensuite le reste

---

L'option "generate browse info" est déjà cochée.

Merci.

Mais là, je crois que c'est la Debug Info qu'on te conseille d'activer même en Release.

Citation:

---

Mais là, je crois que c'est la Debug Info qu'on te conseille d'activer même en Release

---

"generate debug info" était coché en debug, pas en release.
Je l'ai rajouté en release, que dois-je faire ensuite (la situation est la même, ça s'exécute en release, pas en debug)

Il semblerait que tu n'aies pas compris que C'EST NORMAL que ça ne puisse pas s'exécuter en Debug sur un autre poste...

On ne s'est pas compris je crois :

Oubliez l'histoire de compiler sur un poste et exécuter sur un autre (c'était juste un test) :
le problème, c'est que l'exécutable de debug produit sous mon poste XP ne s'exécute pas (toujours sous le même Visual sous XP toujours qui a servi à le générer)

(cf relire le premier post pour comprendre ma demande)

farscape, Medinoc, êtes-vous parti ou en panne d'inspiration?

Suis-je seul au monde à avoir ce problème (si j'en crois google)?

Bonjour,

la seule raison pour avoir ce message ("is not a valid executable file.") est que :

- On tente d'exécuter autre chose qu'un exécutable
- Si c'est bien un exécutable : le PE est corrompu.

Attention : .exe ne signifie pas exécutable !

Comme c'est le rôle de l'éditeur de lien (linker) de produire le PE (Portable executable), j'irais voir du coté des options du linker si il n'y pas quelque chose qui cloche.

Ca peut être un simple flag qui aurait été changé par inattention, ou une simple option a priori anodine. (il suffit par exemple d'avoir mis le flag "driver" et le linker produit un fichier avec l'extension .exe qui n'est absolument pas exécutable).

Au pire, si après avoir visité toutes les options, tu ne trouves rien qui cloche, créé un nouveau projet et met y (copier/coller) tes fichier sources (le mieux est que le fichiers sources ne contiennent aucun pragma destiné au linker).

Relance alors un "Build", le fait d'avoir à nouveau les options "par défaut" peut remédier au problème.

Citation:

---

Ca peut être un simple flag qui aurait été changé par inattention, ou une simple option a priori anodine

---

Je reprécise que le projet identique fonctionne sur l'autre poste (Wondows NT), y compris en debug. Donc toutes les options sont identiques

Citation:

---

Au pire, si après avoir visité toutes les options, tu ne trouves rien qui cloche, créé un nouveau projet et met y (copier/coller) tes fichier sources (le mieux est que le fichiers sources ne contiennent aucun pragma destiné au linker).
Relance alors un "Build", le fait d'avoir à nouveau les options "par défaut" peut remédier au problème.

---

Je viens de recréer un nouveau projet mais j'arrive encore moins à le faire compiler, faut que je continue à regarder option par option ce qui diffère de l'autre.

je suis vraiment mal parti là... :cry:

Bonjour,

Je n'ai toujours pas résolu le problème : j'ai recréé un autre projet, ajouté les fichiers sources et recompilé (pour que ça link, il a fallu juste changer les "object / library modules" comme le projet de base) mais toujours pareil :

"is not a valid executable file"

je ne comprends pas que tu perdes autant de temps sur ce sujet.
si comme nous l'avons diagnostiqué:
le même projet fonctionne sur un autre poste.
c'est que ça vient du poste.
si après vérification des différents chemins de vc6
si après passage du sp6 de vc ,c'est toujours pareil.
la seule solution viable comme je te l'ai dis c'est de desinstaller vc sur ce poste.
avec une vérification au préalable du disque dur de la machine (chkdsk)
et de refaire l'installation complète :
vc6 + sp6 + éventuellement le dernier sdk pour vc6.
en dehors de ça je ne vois pas ce que l'on peut faire de plus.

au vu du nombre d'heures perdus sur ce sujet je ne pense pas que ce soit difficile (avec des bons arguments aux responsables de ta boite) de justifier cette procédure...

Bonjour,

OK farscape. je vais faire la demande juste après avoir essayé la dernière chose que je n'ai pas comprise : qu'est-ce que tu entends par installation du dernier SDK? J'ai pas trouvé de lien de téléchargement.

Merci.

vc6 date 1998 ,en l'état actuel il n'est pas possible d'accèder à certaines api32 apparues après, sauf en faisant des getProcaddress sur les modules concernés.
le sdk résout ce probléme en fournissant des bibliothèques a jour.
le dernier SDK Valide pour vc6 date de février 2003.
si tu as des personnes consciencieuses dans ta boite ils devraient l'avoir stocké car il n'est plus disponible directement sur MSDN par le canal habituel
je donne le dernier lien trouvé dans ce post:
http://www.developpez.net/forums/sho...4862#post64862

SDK installé; par contre je ne sais pas si c'est ce qu'il faut faire, mais j'ai remplacé dans les chemins des include et des lib tous les chemins de type C:\Program Files\Microsoft Visual Studio\VC98 par des chemins de type
C:\Program Files\Microsoft SDK

Au début j'ai pas tout mis (include et include\mfc par exemple pour les .h).
Il ne trouve pas float.h, stdlib.h et d'autres alors je regarde où il y en a :
C:\Program Files\Microsoft SDK\src\crt --> reste plein d'erreurs (
C:\Program Files\Microsoft SDK\include\Win64\crt --> fatal error C1189: #error : ERROR: Use of C runtime library internal header file (de toutes façons ça doit pas être ça car je ne suis pas en 64 bits)

Un exemple, j'avais C:\Program Files\Microsoft Visual Studio\VC98\ATL mais ici, le seul dossier ATL est dans C:\Program Files\Microsoft SDK\include\Win64

Je comprend pas trop...

il ne faut rien remplacer...
mais rajouter en première position dans la recherche include :
C:\PROGRAM FILES\MICROSOFT PLATFORM SDK\INCLUDE (chez moi) ;

pour les libs:
C:\PROGRAM FILES\MICROSOFT SDK\LIB
pour les sources:
C:\PROGRAM FILES\MICROSOFT SDK\INCLUDE
C:\PROGRAM FILES\MICROSOFT SDK\SRC\CRT

OK; bon, et bien c'est rajouté mais ça ne change rien
Il n'y a plus qu'à voir côté installation de Visual...

(mais je me demande quand-même si ça change quelque chose vu qu'il va commencer par chercher les fichiers dans les répertoires où il cherchait avant (C:\Program Files\Microsoft Visual Studio\VC98).
Dans le doute, j'ai mis ces nouvelles lignes en premier mais bon, même résultat.

Et pour finir, j'ai essayé sur le poste d'un collègue (qui a exactement la même installation de Visual puisque c'est fait de manière standard par l'entreprise pour tout le monde) : idem; il ne s'agit donc pas de mon poste.

Ca paraît sans issue (il n'ont qu'un déploiement de Visual et il n'y a pas de raison qu'ils le changent...)

si vous n'arrivez pas a compiler /linker un banal projet bidon en mode debug.
posez vous des questions....
autre point essayer de générer un projet en local sur le disque et non sur le reseau pour voir...

Citation:

---

autre point essayer de générer un projet en local sur le disque et non sur le reseau pour voir...

---

Ah, ah...mais tu sais que je revenais pour dire comment mon problème était résolu?

C'est exactement ça, c'est cette gestion de conf. de m... (ClearCase) qui donnait cette erreur pour une raison inconnue (fonctionne sous NT mais pas XP).

Tout est rentré dans l'ordre quand j'ai envoyé mes exécutables en local effectivement!!!!!!!!

THE END
Un grand merci pour vos messages d'aide.

note : que avec vc200x ce n'est même pas la peine d'essayer de travailler en réseau ce n'est pas supporté et ça ne fonctionne pas.
il faut travailler avec une copie local du projet obtenue avec sourcesafe par exemple.