Dépannage de BadImageFormatException


107

J'ai un service Windows écrit en C # à l'aide de Visual Studio 2010 et ciblant le .NET Framework complet 4. Lorsque je cours à partir d'un débogage, le service s'exécute comme prévu. Cependant, lorsque je l'exécute à partir d'une version Release, j'obtiens une System.BadImageFormatException (détails ci-dessous). J'ai cherché une solution sur Internet, mais jusqu'à présent, tout ce que j'ai trouvé ne m'a pas aidé à trouver une solution.

Le problème existe sur les systèmes Windows 7 64 bits (dev) et Windows XP SP3 32 bits (cible).

Voici ce que j'ai essayé jusqu'à présent:

  • Les paramètres de construction vérifiés tels que Platform Target sont tous les mêmes (x86).
  • Utilisé peverify avec l'option / verbose pour s'assurer que les binaires d'assembly étaient valides.
  • Utilise fuslogvw pour rechercher tout problème de chargement.
  • Utilisé CheckAsm pour rechercher des fichiers ou des assemblages manquants.

Tous ces contrôles n'ont rien changé. J'ai inclus le texte intégral des informations d'exception ci-dessous, avec certains des noms modifiés pour protéger les secrets de mes chefs d'entreprise.

System.BadImageFormatException n'a pas été gérée
  Message = Impossible de charger le fichier ou l'assembly 'XxxDevices, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null' ou l'une de ses dépendances. Une tentative a été faite pour charger un programme avec un format incorrect.
  Source = XxxDevicesService
  FileName = XxxDevices, Version = 1.0.0.0, Culture = neutre, PublicKeyToken = null
  FusionLog = Gestionnaire d'assemblage chargé depuis: C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ clr.dll
Exécution sous l'exécutable c: \ Dev \ TeamE \ bin \ Release \ XxxDevicesService.vshost.exe
--- Un journal d'erreurs détaillé suit. 

=== Informations sur l'état de pré-liaison ===
LOG: Utilisateur = XXX
JOURNAL: DisplayName = XxxDevices, Version = 1.0.0.0, Culture = neutre, PublicKeyToken = null
 (Entièrement spécifié)
LOG: Appbase = fichier: /// c: / Dev / TeamE / bin / Release /
JOURNAL: Chemin privé initial = NULL
Appel de l'assembly: XxxDevicesService, Version = 1.0.0.0, Culture = neutre, PublicKeyToken = null.
===
LOG: Cette liaison démarre dans le contexte de chargement par défaut.
LOG: Utilisation du fichier de configuration de l'application: c: \ TeamE \ bin \ Release \ XxxDevicesService.vshost.exe.Config
LOG: Utilisation du fichier de configuration d'hôte: 
LOG: Utilisation du fichier de configuration de la machine à partir de C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ config \ machine.config.
LOG: la stratégie n'est pas appliquée à la référence pour le moment (liaison d'assembly privée, personnalisée, partielle ou basée sur l'emplacement).
LOG: tentative de téléchargement du nouveau fichier URL: /// c: /TeamE/bin/Release/XxxDevices.DLL.
ERR: échec de la configuration de l'assemblage (hr = 0x8007000b). Le sondage est terminé.

  Trace de la pile:
       à XxxDevicesService.Program.Main (String [] args)
       à System.AppDomain._nExecuteAssembly (assembly RuntimeAssembly, String [] args)
       à Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly ()
       à System.Threading.ExecutionContext.Run (ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
       à System.Threading.ExecutionContext.Run (ExecutionContext executionContext, rappel de ContextCallback, état de l'objet)
       à System.Threading.ThreadHelper.ThreadStart ()
  InnerException: 
c#  .net  exception 

mixez-vous du tout code natif / .net?
Keith Nicholas

1
Vous êtes sur la bonne voie que cette exception est associée à des différences de bits x86 / x64. Je suppose que ce n'est pas une application Web, non? De quel type d'assemblage s'agit-il également XxxDevicesService? Est-il compilé pour une plate-forme spécifique (par exemple 32 bits)? Si tel est le cas, vous devez compiler votre plate-forme en 32 bits.
Reddog

Réponses:


121

Les paramètres de construction vérifiés tels que Platform Target sont tous les mêmes (x86).

Ce n'est pas ce que dit le journal des plantages:

Gestionnaire d'assemblage chargé à partir de: C: \ Windows \ Microsoft.NET \ Framework64

Notez le 64 dans le nom, c'est la maison de la version 64 bits du framework. Définissez le paramètre de plate-forme cible sur votre projet EXE , pas sur votre projet de bibliothèque de classes. Le projet EXE XxxDevicesService détermine le bitness du processus.


6
Et pendant que vous vérifiez le projet EXE, vérifiez à la fois Debug et Release. : /
chris

44

Après avoir arrêté de me cogner la tête sur le bureau en pensant à toute la semaine que j'ai passée à résoudre ce problème, je partage ce qui a fonctionné pour moi. J'ai Win7 64 bits, client Oracle 32 bits, et mon projet MVC 5 est configuré pour fonctionner sur la plate-forme x86 en raison du bitness Oracle. J'ai continué à recevoir les mêmes erreurs:

Impossible de charger le fichier ou l'assembly 'Oracle.DataAccess' ou l'une de ses dépendances. Une tentative a été faite pour charger un programme avec un format incorrect.

J'ai rechargé les packages NuGet, j'ai utilisé des copies des DLL qui fonctionnaient pour d'autres dans différentes applications, j'ai défini la base de code dans l'assemblage dépendant pour qu'elle pointe vers le dossier bin de mon projet, j'ai essayé CopyLocal comme vrai ou faux, j'ai tout essayé . Finalement, j'en avais assez d'autre, je voulais vérifier mon code, et en tant que nouvel entrepreneur, je n'avais pas installé de subversion. En cherchant un moyen de le connecter à VS, j'ai trébuché sur la réponse. Ce que j'ai trouvé a fonctionné était de décocher l'option «Utiliser la version 64 bits d'IIS Express pour les sites Web et les projets» sous la section Projets et solutions => Projets Web sous le menu Outils => Options.


3
Quel sauveur de vie !! Je vous remercie. Pour moi, j'ai dû vérifier cela, car mon projet est effectivement x64. Merci encore!!!
viper

Après toute l'aide que j'ai reçue ici, je suis très heureux d'avoir pu en verser une partie!
Joseph Morgan

3
Pour ceux qui utilisent IIS local, assurez-vous que «Activer les applications 32 bits» de votre pool d'applications (sous Paramètres avancés) est défini sur True .
Eric Eskildsen

Un addenum à @ commentaire de EricEskildsen ci - dessus au sujet de « permettre aux applications 32 bits » dans le pool d'applications, même si vous ne voulez pas le faire dans l'environnement direct, appuyer sur ce commutateur peut fournir des indices supplémentaires pour savoir si vous êtes face à un 32 Problème -bit / 64-bit ou autre chose.
un CVn

Boom! C'était ça.
itslittlejohn

21

Ce que j'ai trouvé a fonctionné était de vérifier l'option «Utiliser la version 64 bits d'IIS Express pour les sites Web et les projets» sous la section Projets et solutions => Projets Web sous le menu Outils => Options.


tu es le sauveur. +1
Amit Kumar

J'ai réinstallé VS et résolvais ce problème (merci - cette solution a fonctionné). La morale de l'histoire pour moi est que si je sais que je n'avais pas changé de code pour commencer, je devrais peut-être regarder d'abord la configuration de VS.
taylorswiftfan

La case à cocher @Lucy 'Utiliser la version 64 bits d'IIS Express pour les sites et projets Web' est désactivée
k_kumar

S'il vous plaît dites à Lucy
k_kumar

12

Cela peut généralement se produire lorsque vous avez modifié le cadre cible de .csproj et que vous l'avez rétabli à ce que vous aviez commencé.

Assurez-vous que 1 si supportedRuntime version = "un runtime différent de la cible du projet cs" sous la balise de démarrage dans app.config.

Assurez-vous que 2 Cela signifie également vérifier d'autres fichiers générés automatiquement ou d'autres dans le dossier de propriétés peut-être pour voir s'il n'y a plus d'incohérence d'exécution entre ces fichiers et celui qui est défini dans le fichier .csproj.

Celles-ci pourraient vous faire gagner beaucoup de temps avant de commencer à essayer différentes choses avec les propriétés du projet pour surmonter l'erreur.


Je suis tombé sur un problème similaire et votre réponse était la solution pour la mienne. Mon app.config avait un runtime pris en charge différent.
Krisztián Kis

9

J'ai eu le même problème même si j'ai Windows 7 64 bits et que je chargeais une DLL 64 bits b / c dans les propriétés du projet | Build J'ai fait cocher "Préférer 32 bits". (Je ne sais pas pourquoi c'est défini par défaut). Une fois que j'ai décoché ça, tout s'est bien passé


1
Pareil ici. Cela a fait l'affaire. Référencé un assembly 64 bits et la configuration de construction active a été définie sur N'importe quel processeur, mais à cause de ce paramètre «Préférer 32 bits», on suppose que 32 bits a été utilisé pour exécuter l'application et a causé les problèmes.
Bernoulli IT

J'ai choisi n'importe quel processeur au lieu de x86 en mode débogage et a fonctionné comme un charme.
Cardi DeMonaco Jr

7

Vous pouvez également obtenir cette exception lorsque votre application cible .NET Framework 4.5 (par exemple) et que vous disposez du fichier app.config suivant:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v2.0.50727" />
    <supportedRuntime version="v4.0" />
  </startup>
</configuration>

Lorsque vous essayez de lancer le débogage de l'application, vous obtiendrez l'exception BadImageFormatException.

La suppression de la ligne déclarant la version v2.0 effacera l'erreur.

J'ai eu ce problème récemment lorsque j'ai essayé de changer la plate-forme cible d'un ancien projet .NET 2.0 vers .NET 4.5.


6

Contexte

Nous avons commencé à l'obtenir aujourd'hui lorsque nous avons fait passer notre service WCF d'AnyCPU à x64 sur un serveur Windows 2012 R2 exécutant IIS 6.2.

Nous avons d'abord vérifié 10 fois le seul assembly référencé, pour nous assurer qu'il ne s'agissait pas réellement d'une dll x86. Ensuite, nous avons vérifié le pool d'applications plusieurs fois pour nous assurer qu'il n'activait pas les applications 32 bits.

Sur un coup de tête, j'ai essayé de basculer le réglage. Il s'avère que les pools d'applications dans IIS étaient définis par défaut sur une valeur Activer les applications 32 bits de False, mais IIS l'ignorait sur notre serveur pour une raison quelconque et exécutait toujours notre service en mode x86.

Solution

  • Sélectionnez le pool d'applications.
  • Choisissez Set du pool d' applications par défaut ... ou Paramètres avancés ... .
  • Définissez Activer les applications 32 bits sur Vrai.
  • Cliquez sur OK .
  • Choisissez Set du pool d' applications par défaut ... ou Paramètres avancés ... à nouveau.
  • Redéfinissez Activer les applications 32 bits sur False.
  • Cliquez sur OK .

4

J'ai résolu ce problème en modifiant l'application Web pour utiliser un autre «pool d'applications».


4

Pour tous ceux qui peuvent arriver ici plus tard ... Rien n'a fonctionné pour moi. Toutes mes assemblées allaient bien. J'avais une configuration d'application dans l'un de mes projets Visual Studio qui n'aurait pas dû être là. Assurez-vous donc que votre fichier de configuration d'application est nécessaire.

J'ai supprimé la configuration d'application supplémentaire et cela a fonctionné.


J'ai corrigé ça pour moi. Mon App.config définissait mon application .NET 4.5.1 sur 2.0 CLR!
Jared Thirsk

4

Target build x64 Target Server Hosting IIS 64 Bit

Si la version de l'application cible le système d'exploitation 64 bits, sur le serveur 64 bits hébergeant l'IIS, définissez l'application enable 32 bits sur le pool d'applications exécutant le site Web / l'application Web sur false.

entrez la description de l'image ici


2

Déterminez le pool d'applications utilisé par l'application et définissez la propriété de en définissant Activer les applications 32 bits sur True. Cela peut être fait via les paramètres avancés du pool d'applications.


2

Lors de la création d'applications pour une plate-forme 32 bits ou 64 bits (mon expérience est avec Visual Studio 2010), ne comptez pas sur le Gestionnaire de configuration pour définir la plate-forme correcte pour l'exécutable. Même si le CM a sélectionné x86 pour l'application, vérifiez les propriétés du projet (onglet Construire): il peut toujours indiquer "N'importe quel CPU". Et si vous exécutez un exécutable "Any CPU" sur une plate-forme 64 bits, il fonctionnera en mode 64 bits et refusera de charger vos DLL d'accompagnement qui ont été construites pour la plate-forme x86.


1

Supprimez votre dépendance à System.Runtime dans votre Web.Config, cela a fonctionné pour moi:

<dependentAssembly>
        <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.10.0" newVersion="4.0.10.0" />
</dependentAssembly>

Pour moi, c'était le System.Net.Http. Merci pour cela.
Snickbrack

1

Pour .NET Core , il existe un bogue Visual Studio 2017 qui peut entraîner l'affichage de la page de génération des propriétés du projet la cible de plateforme incorrecte. Une fois que vous découvrez que le problème est, les solutions de contournement sont assez simples. Vous pouvez changer la cible en une autre valeur, puis la modifier à nouveau.

Vous pouvez également ajouter un identificateur d'exécution au .csproj. Si vous avez besoin que votre .exe s'exécute en tant que x86 afin qu'il puisse charger une DLL native x86, ajoutez cet élément dans un PropertyGroup:

<RuntimeIdentifier>win-x86</RuntimeIdentifier>

Un bon endroit pour placer ceci est juste après l' élément TargetFrameworkou TargetFrameworks.


1

Je suis surpris que personne d'autre n'ait mentionné cela, donc je partage au cas où aucune des solutions ci-dessus n'aiderait (mon cas).

Ce qui se passait, c'est qu'une instance de VBCSCompiler.exe était en quelque sorte bloquée et ne libérait en fait pas les descripteurs de fichier pour permettre aux nouvelles instances d'écrire correctement les nouveaux fichiers et provoquait le problème. Cela est devenu évident lorsque j'ai essayé de supprimer le dossier «bin» et que je me plaignais qu'un autre processus utilisait des fichiers là-dedans.

VS fermé, gestionnaire de tâches ouvert, a regardé et terminé toutes les instances de VBCSCompiler et supprimé le dossier "bin" pour revenir là où j'étais.

Référence: https://developercommunity.visualstudio.com/content/problem/117596/vbcscompilerexe-process-stays-runing-after-exiting.html


Ma solution était également de supprimer tous les répertoires bin et debug.
gabnaim le

0

Pour tous ceux qui peuvent arriver ici plus tard ...
Pour la solution Desktop, j'ai eu une BadImageFormatExceptionexception.
Toutes les options de construction du projet étaient correctes (toutes x86). Mais le projet StartUp de la solution a été changé en un autre projet (projet de bibliothèque de classes).

Changer le projet StartUp en l'original (projet d'application .exe) était une solution dans mon cas


0

Lorsque j'ai rencontré ce problème, les éléments suivants l'ont résolu pour moi:

J'appelais une dll OpenCV à partir d'un autre exe, ma dll ne contenait pas les dll opencv déjà nécessaires comme highgui, features2d, etc. disponibles dans le dossier de mon fichier exe. J'ai copié tout cela dans le répertoire de mon projet exe et cela a soudainement fonctionné.


0

Cette erreur «Impossible de charger le fichier ou l'assembly 'exemple' ou l'une de ses dépendances. Une tentative de chargement d'un programme avec un format incorrect» est généralement due à une configuration incorrecte du pool d'applications.

  1. Assurez-vous que l'AppPool sur lequel votre site s'exécute actuellement a «Activer les applications 32 bits» défini sur False.
  2. Assurez-vous que vous utilisez la bonne version pour votre plate-forme.
  3. Si vous obtenez cette erreur sur un site Web, assurez-vous que votre pool d'applications est configuré pour s'exécuter dans le mode correct (les sites 3.0 doivent s'exécuter en mode 64 bits)
  4. Vous devez également vous assurer que la référence à cet assembly dans Visual Studio pointe vers le fichier correct dans le dossier packages.
  5. Assurez-vous que la version correcte de la DLL est installée dans le GAC pour les sites 2.0.
  6. Cela peut également être dû à la promotion des WSODLib avec le projet Web.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.