Dépannage de BadImageFormatException
J'ai un service Windows écrit en C # à l'aide de Visual Studio 2010 et ciblant l'intégralité du .NET Framework 4. Lorsque je lance à partir d'une construction Debug, le service s'exécute comme prévu. Cependant, lorsque je l'exécute à partir d'une version Release, j'obtiens une exception 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 identiques (x86).
- Utilisez peverify avec l'option/verbose pour vous assurer que les fichiers binaires de l'assembly étaient valides.
- Utilise fuslogvw pour rechercher tout problème de chargement.
- Utilisez CheckAsm pour rechercher des fichiers ou des regroupements manquants.
Toutes ces vérifications n'ont rien changé. J'ai inclus le texte intégral des informations sur les exceptions ci-dessous, avec certains noms modifiés pour protéger les secrets de mes maîtres.
System.BadImageFormatException n'était pas gérée Message = Impossible de charger le fichier ou l'assembly 'XxxDevices, Version = 1.0.0.0, Culture = neutre, PublicKeyToken = null' ou l'une de ses dépendances. Vous avez tenté de charger un programme avec un format incorrect . Source = XxxDevicesService NomFichier = XxxDevices, Version = 1.0.0.0, Culture = neutre, PublicKeyToken = null FusionLog = Gestionnaire d'assemblage chargé à partir de: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll S'exécutant sous le fichier exécutable c:\Dev\TeamE\bin\Release\XxxDevicesService.vshost.exe --- Un journal d'erreur détaillé suit. === Informations d'état avant la liaison === LOG: Utilisateur = XXX LOG: Nom d'affichage = XxxDevices, Version = 1.0.0.0, Culture = neutre, PublicKeyToken = null (Complètement spécifié) LOG: Appbase = fichier: /// c: /Dev/TeamE/bin/Release/ LOG: Initial PrivatePath = NULL Assembly d'appel: XxxDevicesService, Version = 1.0.0.0 , Culture = neutre, PublicKeyToken = null . === LOG: cette liaison commence dans le contexte de chargement par défaut . LOG: à l'aide du fichier de configuration de l'application: c:\TeamE\bin\Release\XxxDevicesService.vshost. .exe.Config LOG: Utilisation du fichier de configuration de l'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: Stratégie non appliquée à la référence pour le moment (liaison Assembly privée, personnalisée, partielle ou basée sur un emplacement) . LOG: tentative de téléchargement du nouveau fichier URL: /// c:/TeamE/bin/Release/XxxDevices. DLL . ERR: Impossible de terminer la configuration de l’assemblage (hr = 0x8007000b). Le sondage est terminé . Trace de la pile: sur XxxDevicesService.Program.Main (String [] args) sur System.AppDomain._nExecuteAssembly (RuntimeAssembly Assembly, String [] args) à Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly () sur System.Threading.ExecutionContext.Run (ExecutionContext executionContext, rappel ContextCallback, état de l'objet, Boolean ignoreSyncCtx) sur System.Threading.ExecutionContext.Run (ExecutionContext executionContext, rappel ContextCallback, état de l'objet) sur System.Threading.ThreadHelper.ThreadStart () InnerException:
Les paramètres de construction vérifiés, tels que Platform Target, sont tous identiques (x86).
Ce n'est pas ce que dit le journal des incidents:
Gestionnaire d'assemblage chargé à partir de: C:\Windows\Microsoft.NET\Framework64
Notez le 64 dans le nom, qui est la base de la version 64 bits du framework. Définissez le paramètre de plate-forme cible sur votre projetEXE, et non sur votre projet de bibliothèque de classes. Le projet EXE XxxDevicesService détermine la qualité de bits du processus.
Ce que j’ai trouvé efficace a été de cocher la case "Utiliser la version 64 bits de IIS Express pour les sites et projets Web" dans la section Projets et solutions => Projets Web du menu Outils => Options.
Cela peut généralement se produire lorsque vous avez modifié le cadre cible de .csproj et que vous l'avez rétabli avec ce que vous avez commencé.
Assurez-vous que 1 si supportedRuntime version = "une exécution différente de la cible du projet cs" sous la balise de démarrage dans app.config.
Assurez-vous également que cela signifie également qu'il faut vérifier les autres fichiers générés automatiquement ou dans un autre dossier de propriétés pour voir s'il n'y a plus d'incompatibilité d'exécution entre ces fichiers et ceux définis 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.
J'ai eu le même problème même si j'ai Windows 7 64 bits et que je chargeais un binaire DLL 64 bits dans Propriétés du projet | J'ai opté pour la version "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é
Vous pouvez également obtenir cette exception lorsque votre application cible .NET Framework 4.5 (par exemple) et que vous avez le fichier app.config suivant:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727" />
<supportedRuntime version="v4.0" />
</startup>
</configuration>
En essayant de lancer le débogage de l'application, vous obtiendrez la BadImageFormatException.
Supprimer 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 à .NET 4.5.
Contexte
Nous avons commencé à l'obtenir aujourd'hui en passant de AnyCPU à x64 sur un serveur Windows 2012 R2 exécutant IIS 6.2.
Nous avons d’abord vérifié le seul assemblage référencé 10 fois, afin de nous assurer qu’il ne s’agissait pas réellement d’une DLL x86. Nous avons ensuite vérifié le pool d'applications à plusieurs reprises pour nous assurer qu'il n'activait pas les applications 32 bits.
Sur un coup de tête, j'ai essayé de changer le réglage. Il s'avère que les pools d'applications dans IIS étaient par défaut sur une valeur Activer les applications 32 bits de False, mais IIS l'ignorait pour une raison quelconque et toujours couru notre service en mode x86.
Solution
- Sélectionnez le pool d'applications.
- Choisissez Définir les paramètres par défaut du pool d'applications ... ou Paramètres avancés ....
- Modifiez Activer les applications 32 bits en True.
- Cliquez sur OK.
- Choisissez Définir les paramètres par défaut du pool d'applications ... ou Paramètres avancés ... à nouveau.
- Remplacez Activez les applications 32 bits par False.
- Cliquez sur OK.
Pour tous ceux qui peuvent arriver ici plus tard ... Rien ne fonctionnait pour moi. Toutes mes assemblées étaient 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 supplémentaire de l'application et cela a fonctionné.
J'ai résolu ce problème en modifiant l'application Web afin qu'elle utilise un "pool d'applications" différent.
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.
Lors de la création d'applications pour une plate-forme 32 bits ou 64 bits (mon expérience concerne Visual Studio 2010), ne vous fiez pas à Configuration Manager pour définir la plate-forme correcte pour l'exécutable. Même si le CM a x86 sélectionné pour l’application, vérifiez les propriétés du projet (onglet Construction): il peut toujours y indiquer "Tout processeur". Et si vous exécutez un exécutable "N'importe quel processeur" sur une plate-forme 64 bits, il s'exécutera en mode 64 bits et refusera de charger les DLL d'accompagnement qui ont été générés pour la plate-forme x86.
Construction cible x64Hébergement sur serveur cible IIS 64 bits
Si la version de l'application cible le système d'exploitation 64 bits, définissez sur le serveur 64 bits hébergeant les services Internet (IIS) l'application enable 32 bits du pool d'applications exécutant le site Web/l'application Web.
Je suis surpris que personne d'autre ne l'ait mentionné, je partage donc au cas où rien de ce qui précède ne m'aiderait (mon cas).
Ce qui se passait, c’est qu’une instance de VBCSCompiler.exe était en quelque sorte bloquée et qu’elle ne libérait pas les descripteurs de fichiers pour permettre aux nouvelles instances d’écrire correctement les nouveaux fichiers et était à l’origine du problème. Cela est devenu évident lorsque j'ai essayé de supprimer le dossier "bin" et qu'il se plaignait du fait qu'un autre processus utilisait des fichiers.
VS fermé, gestionnaire de tâches ouvert, recherche et fin de toutes les instances de VBCSCompiler et suppression du dossier "bin" pour revenir à l’emplacement où j’étais.
Pour .NET Core, il existe un bogue Visual Studio 2017 qui peut amener la page de génération des propriétés du projet à afficher la cible de plate-forme incorrecte. Une fois que vous découvrez que le problème est, les solutions de contournement sont assez faciles. Vous pouvez modifier la cible en une autre valeur, puis la rétablir.
Vous pouvez également ajouter un identifiant d'exécution au fichier .csproj. Si vous avez besoin que votre fichier .exe s'exécute en tant que x86 pour pouvoir charger une DLL native x86, ajoutez cet élément dans une variable PropertyGroup:
<RuntimeIdentifier>win-x86</RuntimeIdentifier>
C'est un bon endroit pour placer ceci juste après l'élément TargetFramework ou TargetFrameworks.
Lorsque j'ai fait face à ce problème, voici ce qui a été résolu pour moi:
J'appelais une dll OpenCV depuis un autre exe, ma dll ne contenait pas les dll 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 tout a soudainement fonctionné.
Cette erreur "Impossible de charger le fichier ou l'assembly" exemple "ou l'une de ses dépendances. Vous avez tenté de charger un programme avec un format incorrect" est généralement due à une configuration incorrecte du pool d'applications.
- Assurez-vous que l'option "Activer les applications 32 bits" sur False est activée pour l'AppPool sur lequel votre site s'exécute actuellement.
- Assurez-vous que vous utilisez la version correcte pour votre plate-forme.
- 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).
- Assurez-vous également que la référence à cette assemblée dans Visual Studio pointe vers le fichier correct dans le dossier des packages.
- Assurez-vous que la version correcte de la DLL est installée dans les sites GAC for 2.0.
- Cela peut également être causé par la promotion de WSODLibs avec le projet Web.
Pour tous ceux qui peuvent arriver ici plus tard ...
Pour la solution de bureau, j'ai une exception BadImageFormatException.
Toutes les options de construction du projet étaient correctes (toutes x86). Mais le projet de solution StartUp a été remplacé par un autre projet (projet de bibliothèque de classes).
Changer le projet de démarrage en projet d'origine (projet d'application .exe) était une solution dans mon cas
Supprimez votre dépendance sur 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>