BadImageFormatExceptionのトラブルシューティング
Visual Studio 2010を使用し、完全な.NET Framework 4を対象とするC＃で記述されたWindowsサービスがあります。デバッグビルドから実行すると、サービスは期待どおりに実行されます。ただし、リリースビルドから実行すると、System.BadImageFormatExceptionが発生します（詳細は以下）。私はインターネットで解決策を探してきましたが、これまでに見つけたすべてのものが解決策を見つける助けにはなりませんでした。
この問題は、Windows 7 64ビット（dev）とWindows XP SP3 32ビット（ターゲット）システムの両方に存在します。
ここに私がこれまで試したものがあります：
- プラットフォームターゲットなどの検証済みビルド設定はすべて同じ（x86）です。
- / verboseオプションと共にpeverifyを使用して、アセンブリバイナリが有効であることを確認しました。
- Fuslogvwを使用して、読み込みの問題を探します。
- CheckAsmを使用して、欠落したファイルまたはアセンブリを探しました。
これらのチェックはすべて何も変更しませんでした。以下に、企業マスターの秘密を守るために一部の名前を変更した例外情報の全文を記載しました。
System.BadImageFormatExceptionは処理されませんでした Message =ファイルまたはアセンブリ「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 [.____の下で実行。] ---詳細なエラーログが続きます。 ===事前バインド状態情報=== LOG：ユーザー= XXX LOG：DisplayName = XxxDevices、バージョン= 1.0.0.0、Culture =ニュートラル、PublicKeyToken = null （完全指定） LOG：Appbase = file：/// c：/ Dev/TeamE/bin/Release/ LOG：Initial PrivatePath = NULL Calling Assembly：XxxDevicesService、Version = 1.0.0.0、Culture = neutral、PublicKeyToken = null。 === LOG：このバインドはデフォルトのロードコンテキストで開始されます。 ____。] LOG：アプリケーション構成ファイルの使用：c：\ TeamE\bin\Release\XxxDevicesService.vshost.exe.Config LOG：ホスト構成ファイルの使用： LOG：マシン構成ファイルの使用C：\ Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config。 LOG：この時点でポリシーは参照に適用されていません（プライベート、カスタム、部分、または場所ベースのアセンブリバインド）。 LOG：新しいURLファイルのダウンロードを試みています：/// c：/TeamE/bin/Release/XxxDevices.DLL。 ERR：アセンブリのセットアップの完了に失敗しました（hr = 0x8007000 b）。プローブの終了。 StackTrace： at XxxDevicesService.Program.Main（String [] args） at System.AppDomain._nExecuteAssembly（RuntimeAssembly Assembly、String [] args） at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly（） at System.Threading.ExecutionContext.Run（ExecutionContext executionContext、ContextCallback callback、Object state、Boolean ignoreSyncCtx） System.Threading.ExecutionContext.Run（ExecutionContext executionContext、ContextCallback callback、Object state） at System.Threading.ThreadHelper.ThreadStart（） InnerException：
プラットフォームターゲットなどの検証済みビルド設定はすべて同じです（x86）。
それはクラッシュログが言うことではありません：
C：\ Windows\Microsoft.NET\Framework64から読み込まれたアセンブリマネージャー
名前の64に注意してください。これは、フレームワークの64ビットバージョンのホームです。クラスライブラリプロジェクトではなく、EXEプロジェクトでターゲットプラットフォーム設定を設定します。 XxxDevicesService EXEプロジェクトは、プロセスのビット数を決定します。
この問題を解決するのに一週間費やしたことを考えて、机の上で頭を叩くのをやめた後、私は自分のために働いたものを共有しています。 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サイトとプロジェクトにIIS Expressの64ビットバージョンを使用]オプションをチェックすることでした。
通常は、.csprojのターゲットフレームワークを変更し、元のフレームワークに戻したときに発生します。
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モードでサービスを実行していました。
ソリューション
- アプリプールを選択します。
- アプリケーションプールのデフォルト設定...または詳細設定...を選択します。
- 32ビットアプリケーションを有効にするをTrueに変更します。
- OKをクリックします。
- アプリケーションプールのデフォルト設定...または詳細設定...を選択します再び。
- 32ビットアプリケーションを有効にするをFalseに戻します。
- OKをクリックします。
別の「アプリケーションプール」を使用するようにWebアプリを変更することにより、この問題を修正しました。
後でここに到着するかもしれない人のために....何も私のために働いた。すべてのアセンブリは正常でした。 Visual Studioプロジェクトの1つにあるはずのないアプリ構成がありました。そのため、アプリの構成ファイルが必要であることを確認してください。
余分なアプリの設定を削除し、機能しました。
32ビットアプリケーションを有効にするをTrueに設定して、アプリケーションが使用するアプリケーションプールを決定し、プロパティを設定します。これは、アプリケーションプールの事前設定によって実行できます。
32ビットまたは64ビットプラットフォーム用のアプリを構築する場合（私の経験はVisual Studio 2010を使用しています）、Configuration Managerに依存して実行可能ファイルの正しいプラットフォームを設定しないでください。 CMでアプリケーション用にx86が選択されている場合でも、プロジェクトプロパティ（[ビルド]タブ）を確認します。「Any CPU」と表示される場合があります。また、64ビットプラットフォームで「任意のCPU」実行可能ファイルを実行すると、64ビットモードで実行され、x86プラットフォーム用にビルドされた付随DLLのロードを拒否します。
私は他の誰もこれについて言及していないことに驚いているので、上記の助けのいずれも私のケースではない場合に共有しています。
起こっていたのは、VBCSCompiler.exeインスタンスが何らかの理由でスタックし、実際に新しいインスタンスが新しいファイルを正しく書き込むことを可能にするファイルハンドルを解放せず、問題を引き起こしていたことです。これは、「bin」フォルダーを削除しようとしたときに明らかになり、別のプロセスがそこにあるファイルを使用していると不平を言っていました。
VSを閉じ、タスクマネージャーを開き、すべてのVBCSCompilerインスタンスを検索して終了し、「bin」フォルダーを削除して、現在の場所に戻りました。
。NET Coreには、 Visual Studio 2017のバグ があり、プロジェクトプロパティの[ビルド]ページに誤ったプラットフォームターゲットが表示される可能性があります。問題が見つかったら、回避策は非常に簡単です。ターゲットを他の値に変更してから、元に戻すことができます。
または、ランタイム識別子を.csprojに追加できます。 x86ネイティブDLLをロードできるように.exeをx86として実行する必要がある場合は、PropertyGroup内にこの要素を追加します。
<RuntimeIdentifier>win-x86</RuntimeIdentifier>
これを配置する適切な場所は、TargetFrameworkまたはTargetFrameworks要素の直後です。
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>
ターゲットビルドx64ターゲットサーバーホスティングIIS 64ビット
アプリケーションビルドが64ビットOSをターゲットにしている場合、IISをホストしている64ビットサーバーで、Webサイト/ Webアプリケーションを実行しているアプリプールの32ビットアプリケーションをfalseに設定します。
この問題に直面したとき、次のことで解決しました。
私は別のexe内からOpenCV dllを呼び出していましたが、私のdllには、exeファイルのフォルダで利用可能なhighgui、features2dなどの必要なopencv dllが含まれていませんでした。これらをすべてexeプロジェクトのディレクトリにコピーすると、突然動作しました。
このエラー「ファイルまたはアセンブリの「例」またはその依存関係の1つをロードできませんでした。不適切な形式のプログラムをロードしようとしました」は、通常、アプリケーションプールの構成が正しくないことが原因です。
- サイトが現在実行されているAppPoolの「32ビットアプリケーションを有効にする」がFalseに設定されていることを確認します。
- プラットフォームに適したバージョンを使用していることを確認してください。
- Webサイトでこのエラーが発生する場合は、アプリケーションプールが正しいモードで実行するように設定されていることを確認してください（3.0サイトは64ビットモードで実行する必要があります）
- また、Visual Studioでのそのアセンブリへの参照が、パッケージフォルダー内の正しいファイルを指していることを確認する必要があります。
- 2.0サイトのGACに正しいバージョンのdllがインストールされていることを確認してください。
- これは、WSODLibsがWebプロジェクトでプロモートされることによっても発生します。
後でここに到着する可能性のある人のために...
デスクトップソリューションの場合、BadImageFormatException例外が発生しました。
すべてのプロジェクトのビルドオプションは正常でした（すべてx86）。しかし、ソリューションのスタートアッププロジェクトは、他のプロジェクト（クラスライブラリプロジェクト）に変更されました。
私の場合、Startupプロジェクトを元の（.exeアプリケーションプロジェクト）に変更することがソリューションでした