Alternative Ursache für BadImageFormatException in .NET Assembly?

Question

Ich arbeite an einer .NET 3.5-Konsolenanwendung in C#, die eine VC++ - nicht verwaltete DLL verwendet. Es lief ohne Probleme, als ich vor ein paar Wochen daran arbeitete, aber ich komme heute darauf zurück und erhalte jetzt eine BadImageFormatException ("Es wurde versucht, ein Programm mit einem falschen Format zu laden. (Ausnahme von HRESULT:

Meine Entwicklungs-Workstation läuft mit 64-Bit-Windows 7, und ich arbeite ziemlich viel mit nicht verwaltetem Code, also habe ich sofort überprüft, ob die .NET-Assembly und die VC++ - Bibliothek x86-Ziele hatten.

Nur um sicherzugehen, ich gereinigt und die Bibliothek VC++ neu aufgebaut und die .NET-Assembly, ohne Erfolg.

Weder System etwas zu tun, ist besonders ungewöhnlich. die Bibliothek VC++ lädt eine binäre dat eine Datei und führt eine mathematische Verarbeitung ihres Inhalts durch. Die .NET-Assembly verfügt über die DllImports für die Bibliothek und etwas Code, um es zu verkabeln. Das alles hat vor ein paar Wochen funktioniert.

So bin ich jetzt gefragt, ob es eine andere Ursache für BadImageFormatException gibt, die weniger häufig ist als ein x86/x64-Konflikt, in dem ich möglicherweise laufen würde.

Danke.

BEARBEITEN: Ich bekomme den gleichen Fehler unabhängig von x86 oder x64-Modus, aber wenn auf 'Any CPU' gesetzt wird Ausführung über diesen Punkt, aber Ausführung bricht bei einem späteren Aufruf der VC++ Bibliothek ohne Ausnahme ab. Unabhängig davon, ob dies mit diesem Problem zusammenhängt, gibt es etwas, das "Irgendeine CPU" anders als x86 und x64 tut, was etwas Licht in dieses Thema bringen könnte?

Answer 1

Möglicherweise versuchen Sie, eine für CLR 4.0 erstellte Baugruppe in CLR 2.0 zu laden.

Answer 2

Angesichts Ihrer Verwendung von nativen Code hier denke ich, das wahrscheinlichste Problem hier ist, dass Sie versuchen, eine native DLL zu laden, als ob es eine .Net-Assembly wäre. Dies ist ein Szenario, das ein BadImageFormatException hervorbringen wird.

Versuchen Sie, Ihre Anwendung laufen zu lassen und setzen Sie es auf Throw für BadImageFormatException brechen und sehen, welche DLL geladen wird. Wenn es ein natives ist, dann ist das das Problem.

Answer 3

Wenn ich diesen Fehler bekomme, wird es immer durch das Laden einer 32-Bit-DLL in einem 64-Bit-Prozess verursacht.

Legen Sie die EXE-Datei auf x86 kompilieren und sehen, ob es funktioniert.

Answer 4

Auf einen .dll-Ladekonflikt prüfen!

Ich habe eine C++/CLI-DLL aus C# aufgerufen; Die C++/CLI-Bibliothek ist ein Wrapper um eine native DLL eines Drittanbieters.

Es stellte sich heraus, ich hatte zwei DLLs mit dem gleichen Namen, beide im Pfad (libeay32.dll).

Um die Ursache des Problems zu entdecken installiert ich die Fenster Debugging-Tools: http://www.microsoft.com/whdc/devtools/debugging/default.mspx

Run 'gflags' (in den "c:... \ Programme \ Debugging Tools" -Ordner), um Anzeige des Loaders aktivieren "snaps"

ie

> gflags -i <my test app.exe> +sls 

dann führen die Anwendung in CDB (console Debuggers) oder windbg und Schlepp durch den Ausgang, um herauszufinden, welche DLL die Ausnahme verursacht.

z.B.

Das Umbenennen der "falschen" libeay32.dll demonstrierte das Problem, ist aber nur eine temporäre Lösung!

Derselbe Fehlerfindungsansatz könnte für Sie trotzdem funktionieren.

Answer 5

In meinem Fall hat das Ausschalten der Enable unmanaged code debugging Debugging-Registerkarte der Projekteigenschaften von EXE ironischerweise den Trick, wenn es überprüft wird.

Um ehrlich zu sein, bin ich mir nicht sicher, warum das die Ursache des Problems ist.