BadImageFormatExceptionのトラブルシューティング

Visual Studio 2010を使用し、完全な.NET Framework 4を対象とするC＃で記述されたWindowsサービスがあります。デバッグビルドから実行すると、サービスは期待どおりに実行されます。ただし、Releaseビルドから実行すると、System.BadImageFormatExceptionが発生します（詳細は以下）。私はインターネットで解決策を探していましたが、これまでに見つけたすべてのものは解決策を見つけるのに役立ちませんでした。

この問題は、Windows 7 64ビット（dev）システムとWindows XP SP3 32ビット（ターゲット）システムの両方に存在します。

これが私がこれまでに試したことです：

• プラットフォームターゲットなどの検証済みビルド設定はすべて同じです（x86）。
• / verboseオプションを指定してpeverifyを使用し、アセンブリバイナリが有効であることを確認しました。
• ロードの問題を探すためにfuslogvwを使用します。
• CheckAsmを使用して、不足しているファイルまたはアセンブリを探しました。

これらのチェックはすべて何も変更しませんでした。以下に、例外情報の全文を含めました。一部の名前は、会社のマスターの秘密を保護するために変更されています。

System.BadImageFormatExceptionが処理されませんでした
  メッセージ=ファイルまたはアセンブリ 'XxxDevices、Version = 1.0.0.0、Culture = neutral、PublicKeyToken = null'またはその依存関係の1つを読み込めませんでした。不正な形式のプログラムを読み込もうとしました。
  Source = XxxDevicesService
  FileName = XxxDevices、Version = 1.0.0.0、Culture = neutral、PublicKeyToken = null
  FusionLog =から読み込まれるアセンブリマネージャー：C：\ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ clr.dll
実行可能ファイルc：\ Dev \ TeamE \ bin \ Release \ XxxDevicesService.vshost.exeで実行
---詳細なエラーログが続きます。 

===バインド前の状態情報===
ログ：ユーザー= XXX
ログ：DisplayName = XxxDevices、Version = 1.0.0.0、Culture = neutral、PublicKeyToken = null
 （完全指定）
ログ：Appbase = file：/// c：/ Dev / TeamE / bin / Release /
ログ：初期PrivatePath = NULL
呼び出しアセンブリ：XxxDevicesService、バージョン= 1.0.0.0、カルチャ=ニュートラル、PublicKeyToken = null。
===
ログ：このバインドは、デフォルトのロードコンテキストで開始されます。
ログ：アプリケーション構成ファイルを使用：c：\ TeamE \ bin \ Release \ XxxDevicesService.vshost.exe.Config
ログ：ホスト構成ファイルを使用： 
ログ：C：\ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ config \ machine.configのマシン構成ファイルを使用します。
ログ：現時点で参照に適用されていないポリシー（プライベート、カスタム、部分的、またはロケーションベースのアセンブリバインド）。
ログ：新しいURL file：/// c：/TeamE/bin/Release/XxxDevices.DLLのダウンロードを試みています。
ERR：アセンブリのセットアップを完了できませんでした（hr = 0x8007000b）。プローブが終了しました。

  スタックトレース：
       XxxDevicesService.Program.Main（String [] args）
       System.AppDomain._nExecuteAssembly（RuntimeAssemblyアセンブリ、String [] args）で
       Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly（）で
       System.Threading.ExecutionContext.Run（ExecutionContext executionContext、ContextCallbackコールバック、オブジェクトの状態、ブール値ignoreSyncCtx）で
       System.Threading.ExecutionContext.Run（ExecutionContext executionContext、ContextCallbackコールバック、オブジェクトの状態）
       System.Threading.ThreadHelper.ThreadStart（）で
  InnerException： 

プラットフォームターゲットなどの検証済みビルド設定はすべて同じです（x86）。

それはクラッシュログが言うことではありません：

から読み込まれたアセンブリマネージャー：C：\ Windows \ Microsoft.NET \ Framework64

名前の64に注意してください。これは、64ビットバージョンのフレームワークのホームです。クラスライブラリプロジェクトではなく、EXEプロジェクトでターゲットプラットフォーム設定を設定します。XxxDevicesService EXEプロジェクトは、プロセスのビット数を決定します。

私がこの問題を解決するために費やした1週間全体を考えて頭を叩くのをやめた後、私は何がうまくいったかを共有しています。Win7 64ビット、32ビットのOracleクライアントを使用していて、Oracleのビット数のため、MVC 5プロジェクトをx86プラットフォームで実行するように設定しています。私は同じエラーを出し続けました：

ファイルまたはアセンブリ「Oracle.DataAccess」またはその依存関係の1つをロードできませんでした。不正な形式のプログラムを読み込もうとしました。

私はNuGetパッケージを再読み込みし、別のアプリで他の人のために機能するDLLのコピーを使用し、依存アセンブリのコードベースをプロジェクトのbinフォルダーを指すように設定し、CopyLocalをtrueまたはfalseとして試し、すべてを試しました。 最後に、他に十分なことを行って、コードをチェックインしたいと思いました。新しい請負業者として、私はsubversionをセットアップしていませんでした。それをVSにフックする方法を探している間に、私は答えにつまずきました。私が機能したのは、[ツール] => [オプション]メニューの[プロジェクトとソリューション] => [Webプロジェクト]セクションにある[WebサイトとプロジェクトにIIS Expressの64ビットバージョンを使用する]オプションをオフにすることでした。

私が機能したのは、[ツール]> [オプション]メニューの[プロジェクトとソリューション] => [Webプロジェクト]セクションにある[Webサイトとプロジェクトに64ビットバージョンのIIS Expressを使用する]オプションをチェックすることでした。

通常、.csprojのターゲットフレームワークを変更し、それを元の状態に戻したときに発生します。

app.configの起動タグの下のsupportedRuntime version = "cs project targetとは異なるランタイム"の場合は1にしてください。

2を確認します。これは、他の自動生成されたファイルまたは他のファイルをプロパティフォルダーでチェックして、これらのファイルと.csprojファイルで定義されているファイルとの間にランタイムの不一致がないかどうかを確認することも意味します。

エラーを克服するために、プロジェクトプロパティでさまざまなことを試す前に、これらを使用することで多くの時間を節約できます。

64ビットのWindows 7を使用していて、プロジェクトのプロパティで64ビットのDLL b / cをロードしていても、同じ問題が発生しました。ビルド「32ビット優先」をオンにしました。（デフォルトで設定されている理由がわかりません）。チェックを外すと、すべて正常に動作しました

アプリケーションが.NET Framework 4.5（たとえば）をターゲットとしていて、次のapp.configがある場合にも、この例外が発生する可能性があります。

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

アプリケーションのデバッグを起動しようとすると、BadImageFormatExceptionが発生します。

v2.0バージョンを宣言する行を削除すると、エラーがクリアされます。

ターゲットプラットフォームを古い.NET 2.0プロジェクトから.NET 4.5に変更しようとしたときに、最近この問題が発生しました。

バックグラウンド

IIS 6.2を実行しているWindows 2012 R2サーバーでWCFサービスをAnyCPUからx64に切り替えたときに、今日これを取得し始めました。

最初に、参照されている唯一のアセンブリを10回チェックして、実際にx86 dllではないことを確認しました。次に、アプリケーションプールを何度もチェックして、32ビットアプリケーションを有効にしていないことを確認しました。

気まぐれで設定を切り替えてみました。IISのアプリケーションプールは既定で[ 32ビットアプリケーションを有効にする]の値がFalseになっていることがわかりましたが、IISは何らかの理由でサーバー上でそれを無視し、常にx86モードでサービスを実行していました。

解決

• アプリプールを選択します。
• Set Application Pool Defaults ...またはAdvanced Settings ...を選択します。
• 32ビットアプリケーションの有効化をTrueに変更します。
• OKをクリックします。
• 選択して[アプリケーションプールの既定値...か... [詳細設定]をもう一度。
• [ 32ビットアプリケーションを有効にする]をFalseに戻します。
• OKをクリックします。

別の「アプリケーションプール」を使用するようにWebアプリを変更することで、この問題を修正しました。

後でここに到着するかもしれない人のために....私のために何もうまくいきませんでした。私のすべてのアセンブリは大丈夫でした。Visual Studioプロジェクトの1つにアプリの構成がありませんでした。したがって、アプリの構成ファイルが必要であることを確認してください。

私は余分なアプリの設定を削除し、それが機能しました。

ターゲットビルドx64ターゲットサーバーホスティングIIS 64ビット

アプリケーションのビルドが64ビットOSをターゲットにしている場合は、IISをホストしている64ビットサーバーで、Webサイト/ Webアプリケーションを実行しているアプリプールで32ビットアプリケーションを有効にするをfalseに設定します。

アプリケーションが使用するアプリケーションプールを特定し、[32ビットアプリケーションを有効にする]をTrueに設定して、プロパティを設定します。これは、アプリケーションプールの事前設定を通じて行うことができます。

32ビットまたは64ビットプラットフォーム用のアプリを構築する場合（私の経験はVisual Studio 2010を使用しています）、実行可能ファイルの正しいプラットフォームを設定するために構成マネージャーに依存しないでください。CMでアプリケーション用にx86が選択されている場合でも、プロジェクトのプロパティ（[ビルド]タブ）を確認します。そこに「すべてのCPU」と表示される場合があります。また、「任意のCPU」実行可能ファイルを64ビットプラットフォームで実行すると、64ビットモードで実行され、x86プラットフォーム用にビルドされた付随するDLLのロードを拒否します。

Web.ConfigでSystem.Runtimeへの依存関係を削除します。それは私にとってはうまくいきました：

<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>

以下のために.NETのコア、そこにあるのVisual Studio 2017のバグプロジェクトのプロパティの[ビルド]ページが正しくないプラットフォームターゲットを表示することがあります。問題が見つかったら、回避策は非常に簡単です。ターゲットを他の値に変更してから、元に戻すことができます。

または、.csprojにランタイム識別子を追加できます。.exeをx86として実行してx86ネイティブDLLをロードできるようにする必要がある場合は、この要素を内に追加しますPropertyGroup。

<RuntimeIdentifier>win-x86</RuntimeIdentifier>

これを配置するのに適した場所は、TargetFrameworkor TargetFrameworks要素の直後です。

他の誰もこれについて言及していないので驚きますので、上記のヘルプのどれもが私の場合（私の場合）に備えて共有しています。

起こっていたのは、VBCSCompiler.exeインスタンスがどういうわけかスタックしていて、新しいインスタンスが新しいファイルを正しく書き込むことができるようにファイルハンドルを解放しておらず、問題を引き起こしていたことです。これは「bin」フォルダを削除しようとしたときに明らかになり、別のプロセスがそこにあるファイルを使用していると不平を言っていました。

VSを閉じ、タスクマネージャーを開き、すべてのVBCSCompilerインスタンスを調べて終了し、「bin」フォルダーを削除して、元の場所に戻りました。

リファレンス：https : //developercommunity.visualstudio.com/content/problem/117596/vbcscompilerexe-process-stays-runing-after-exiting.html

後でここに来るかもしれない人のために...
デスクトップソリューションのために私はBadImageFormatException例外を得ました。
すべてのプロジェクトのビルドオプションは問題ありませんでした（すべてx86）。ただし、ソリューションのスタートアッププロジェクトが他のプロジェクト（クラスライブラリプロジェクト）に変更されました。

StartUpプロジェクトを元の（.exeアプリケーションプロジェクト）に変更することが私の場合の解決策でした

私がこの問題に直面したとき、以下は私のためにそれを解決しました：

別のexe内からOpenCV dllを呼び出していましたが、私のdllには、exeファイルのフォルダーにあるhighgui、features2dなどの必要なopencv dllが含まれていませんでした。これらすべてをexeプロジェクトのディレクトリにコピーしましたが、突然動作しました。

このエラー「ファイルまたはアセンブリ 'example'またはその依存関係の1つを読み込めませんでした。不正な形式のプログラムを読み込もうとしました」は、通常、不正なアプリケーションプール構成が原因です。

1. サイトが現在実行されているAppPoolの[32ビットアプリケーションを有効にする]がFalseに設定されていることを確認します。
2. ご使用のプラットフォームに適したバージョンを使用していることを確認してください。
3. Webサイトでこのエラーが発生する場合は、アプリケーションプールが正しいモードで実行されるように設定されていることを確認してください（3.0サイトは64ビットモードで実行する必要があります）
4. また、Visual Studioでのそのアセンブリへの参照が、パッケージフォルダー内の正しいファイルを指していることを確認する必要もあります。
5. 2.0サイトのGACに正しいバージョンのdllがインストールされていることを確認してください。
6. これは、WebプロジェクトでプロモートされているWSODLibsが原因である場合もあります。