web-dev-qa-db-de.com

BadImageFormatException beim Laden der 32-Bit-DLL, Ziel ist x86

Ich habe ein DLL (FreeType), das sicherlich 32-Bit (Header: IMAGE_FILE_MACHINE_I386) ist.

Ich möchte es aus C # -Code mit DllImport verwenden.

Ziel meiner Anwendung ist x86, IntPtr.Size ist 4, der Prozess ist 32-Bit.

Ich erhalte jedoch BadImageFormatException (Ausnahme von HRESULT: 0x8007000B). Was kann falsch sein? 

Natürlich verwende ich 64-Bit Windows 7.

31
Coder

Soweit ich weiß, kann eine Assembly, die speziell für x86 erstellt wurde und in einem 64-Bit-Betriebssystem ausgeführt wird, nur Bibliotheken laden, die für x86 erstellt wurden. Andernfalls wird eine BadImageFormatException ausgelöst. In einem 64-Bit-Betriebssystem löst eine Assembly, die für Any CPU oder x64 erstellt wurde, dieselbe Ausnahme aus, wenn versucht wird, eine x86-Bibliothek zu laden.

Vorausgesetzt, es geht nichts Unvorstellbares vor, würde ich sicherstellen, dass Sie Ihre Anwendung so einstellen, dass sie als x86 erstellt wird, indem Sie die Projekteigenschaften öffnen und auf die Registerkarte Erstellen klicken. Stellen Sie sicher, dass "Platform Target" auf "x86" und nicht auf Any CPU gesetzt ist.

Alternativ können Sie versuchen, eine 64-Bit-Version von DLL zu Testzwecken zu finden.

39
Eric Smith

Kompilieren Sie die DLL mit der Option "Any CPU" in Build -> Platform. 

enter image description here

6
RckLN

OK, scheint eine falsche Warnung zu sein. Es hatte nichts mit Bitness zu tun, es fehlten nur noch andere DLL, von denen Freetype abhängt. Fehlermeldungen können jedoch hilfreicher sein. 

6
Coder

Für Webanwendungen müssen außerdem 32-Bit-Anwendungen in IIS 7 ausgeführt werden. Siehe http://www.fishofprey.com/2009/04/badimageformatexception-in-iis-70-on-64 .html

4
Anastacia

Dieselbe Fehlermeldung beim Aufruf einer 64-Bit-C Dll von C #. Ich musste C # Properties->Build->Platform target manuell von Any Cpu in x64 ändern. Anscheinend ist Any Cpu manchmal NoCpu.

4
BSalita

Ich hatte einen ähnlichen Fehler ... Ich konnte es lösen, indem ich die ucrtbase.dll oder ucrtbased.dll für debug sowie die vcruntime140.dll oder vcruntime140d.dll für das debug in das Verzeichnis der ausführbaren Datei hinzufügte. Ich denke, die Version 140 hängt von der Versionsnummer des verwendeten Visual Studio ab.

ucrtbase.dll liegt normalerweise in C:\Windows\System32. vcruntime140.dll liegt in C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x86\vcruntime140.dll

Weitere Informationen finden Sie hier: http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx

2
Peter Ittner

Wenn Sie eine native Anwendung/DLL etwas mit Visual Studio erstellen, wird eine Abhängigkeit von dem Paket "Redistributable" für diese Version von Visual Studio hergestellt. Das enthält DLLs wie msvcr100.dll und msvcp100.dll (für verschiedene Werte von 100).

In meinem Fall hatte ich diese DLLs im Windows/system32-Verzeichnis des Zielcomputers gesehen, also dachte ich, alles sei gut. Es stellt sich heraus, dass diese DLLs x64 waren! Ich habe keine Ahnung, warum ein Verzeichnis namens system32 64-Bit-DLLs enthält. Also durchsuchte ich mein Visual Studio 2010-Verzeichnis nach allem, was msvc*.dll heißt, und fand x86-Versionen von msvcr100.dll und msvcp100.dll. Ich habe diese auf den Zielcomputer kopiert (an einem Ort, auf den Sie von meinem Programmpfad aus zugreifen können), und alles war gut.

Ich hoffe, das hilft jemandem, der sich mit Microsofts purem Wahnsinn konfrontiert.

1
ulatekh

Sie können die Option "Eigenschaften" -> "Erstellen" -> "Unsicheren Code zulassen" aktivieren.

0
ADM-IT

sie verwenden Eigenschaften in C # -Projekt und ändern "Plattformziel" in x64 . Bildbeschreibung hier eingeben

0
xuanbka1

Ich vermute, dass sich die häufige Ursache für diese Ausnahme in den acht Jahren seit der Erstbefragung geändert hat. Bei meinem Setup mit VS 2017 habe ich festgestellt, dass die Deaktivierung "Bevorzugen 32-Bit" das Problem gelöst hat:

Deaktivieren Sie in den Erstellungsoptionen die Option "32-Bit bevorzugen"

Dies hat dazu geführt, dass mein 64-Bit DLL, das aus C++ erstellt wurde, korrekt geladen wurde. Wenn Sie diese Option aktivieren, sollten 32-Bit-DLLs korrekt geladen werden.

0
Caleb