Je travaille sur une application de console .NET 3.5 en C # qui utilise une DLL non exploitée VC ++. Il a couru sans problème quand j'y ai travaillé il y a quelques semaines, mais je reviens aujourd'hui et je reçois maintenant une badimageformatexception ("une tentative a été faite de charger un programme avec un format incorrect. (Exception de HRESULT: 0x8007000B)).
Mon poste de travail de développement est en cours d'exécution de 64 bits Windows 7, et je travaille juste avec le code non géré, j'ai immédiatement vérifié que l'assemblage .NET et la bibliothèque VC ++ ont tous deux des objectifs X86. Ils l'ont fait.
Juste pour être sûr, j'ai nettoyé et reconstruit la bibliothèque VC ++ et le .NET Assembly, en vain.
aucun système ne fait quelque chose de particulièrement inhabituel. La bibliothèque VC ++ charge un fichier de données binaires et fait un traitement mathématique sur son contenu. L'assembly .NET a le DLLIMPORTS pour la bibliothèque et un code pour la filer. Tout cela a fonctionné il y a quelques semaines.
Alors maintenant, je me demande s'il y a une autre cause de badimageformatException moins courante qu'un conflit x86 / x64 que je pourrais rencontrer.
Merci.
Edit: Je reçois la même erreur, quel que soit le mode X86 ou X64, mais lorsqu'il est défini sur "Toute CPU", l'exécution devient au-delà de ce point, mais l'exécution aborde un appel ultérieur à la bibliothèque VC ++ sans exception. Indépendamment de la question de savoir si cela est lié à ce problème, existe-t-il quelque chose que "tout CPU" fait différemment des X86 et X64, qui pourrait éclairer de la lumière à ce sujet?
5 Réponses :
Vous essayez peut-être de charger un assemblage construit pour CLR 4.0 sur CLR 2.0.
Merci pour la réponse rapide, mais nous n'avons aucune installation Visual Studio 2010 ici, donc pas de CLR 4.0.
Compte tenu de votre utilisation du code natif ici, je pense que le problème le plus probable ici est que vous essayez de charger une DLL natif comme s'il s'agissait d'un assemblage .NET. Ceci est un scénario qui va frayer un Essayez d'exécuter votre application et de la définir pour casser le lancer pour badimageformatException .
BadimageFormatException et voir quelle DLL est chargée. Si c'est un natif, alors c'est le problème.
Lorsque j'obtiens cette erreur, il est toujours causé en chargement d'une DLL 32 bits dans un processus 64 bits.
Définissez le fichier EXE pour compiler à X86 et voir si cela fonctionne.
Comme je l'ai dit dans la question initiale, tout est réglé sur X86.
Vérifiez un conflit de charge .dll!
J'appelle une DLL C ++ / CLI de C #; La bibliothèque C ++ / CLI est une enveloppe autour d'une DLL native tiers.
s'avère que j'ai eu deux dlls avec le même nom, à la fois sur le chemin (libel32.dll).
Pour découvrir la source du problème, j'ai installé les outils de débogage de Windows. :
https://docs.microsoft.com/ EN-US / Windows-Hardware / pilotes / débogueur / débogueur-téléchargement-outils
Ancien lien: http://www.microsoft.com/whdc/ devtools / débogage / default.mspx
exécuter 'gflags' (dans "C: \ Program Files \ Outils de débogage".. "Dossier) Pour activer l'affichage de chargeur "snaps"
IE puis exécutez l'application dans CDB (débogueur de la console) ou windbg et chalut dans la sortie pour savoir quelle DLL a provoqué l'exception. par exemple renommer le "mauvais" libey32.dll a démontré le problème mais n'est qu'une solution temporaire! La même approche de recherche d'erreur pourrait fonctionner pour vous de toute façon.
Merci @kfreezen!
Dans mon cas, désactiver Pour être honnête, je ne sais pas pourquoi c'est la cause du problème. Activer le débogage du code non gagné dans l'onglet de débogage des propriétés du projet d'EXE fait ironiquement l'astuce, si elle est cochée.
Y a-t-il une chance que l'application de course ait accès à une version X64 de la bibliothèque VC ++ et tente de charger celui-ci? Ou, votre application de course peut-elle cibler AnyCPU et non X86? AnyCPU sera chargé en 64 bits si vous êtes sur un environnement 64 bits.
Bonnes questions. Le premier ne semble pas être le cas, j'ai essayé de copier le projet à une autre machine qui n'a jamais eu de copie de la bibliothèque dessus, faisant attention à copier uniquement la version X86 de l'Assemblée. Le même problème est arrivé sur l'autre machine. L'application est définitivement définie sur x86. Sortie de la curiosité, je l'ai défini pour courir dans "Toute CPU". Lorsque je le fais, cela dépasse le premier appel à la bibliothèque VC ++ (où il décède lorsqu'il est défini sur X86 ou X64), mais l'exécution se termine lors d'un appel ultérieur à la bibliothèque.
Exécutez la dépendance Walker X86 sur votre .exe, puis sur votre .dll. J'ai eu ce problème une fois après avoir copié MSVCR120.dll de System32 sur une machine 64 bits. Oy!