Ich habe eine DLL (FreeType), die sicherlich 32-Bit (Header: IMAGE_FILE_MACHINE_I386) ist.BadImageFormatException beim Laden von 32-Bit-DLL, Ziel ist x86
Ich möchte es von C# -Code verwenden, mit DllImport.
Ziel meiner Anwendung ist x86, IntPtr.Size ist 4, Prozess ist 32-Bit.
Aber ich bekomme BadImageFormatException (Ausnahme von HRESULT: 0x8007000B). Was kann falsch sein?
Natürlich verwende ich 64-Bit-Windows-7
Von dem, was ich verstehe, eine Anordnung speziell für x86 gebaut und in einem 64-Bit-Betriebssystem ausgeführt wird, können nur Last-Bibliotheken für x86 gebaut oder ein BadImageFormatException wird geworfen. In einem 64-Bit-Betriebssystem löst eine Assembly, die für Any CPU oder x64 erstellt wurde, die gleiche Ausnahme aus, wenn sie versucht, eine x86-Bibliothek zu laden.
Also unter der Annahme, dass nichts Unheimliches passiert, würde ich sicherstellen, dass Sie Ihre Anwendung als x86 erstellen, indem Sie die Projekteigenschaften öffnen und auf die Registerkarte Erstellen klicken. Stellen Sie sicher, dass "Platform Target" auf "x86" und nicht auf "Any CPU" eingestellt ist.
Alternativ können Sie versuchen, eine 64-Bit-Version der DLL zu Testzwecken zu finden.
Ich bin 100% sicher, dass meine C# -App 32-Bit ist. Ich selbst gebrauchte CorFlags überprüfen es: Version: v2.0.50727 CLR Rubrik: 2,5 PE: PE32 CorFlags: 3 ILONLY: 1 32BIT: 1 Gezeichnet: 0 – Coder
@Eric Smith Ich hatte das gleiche Problem ... das hat es behoben. Ich danke dir sehr! – bsara
+1. Das gleiche Problem haben und erfolgreich behoben. –
OK, scheint wie eine falsche Warnung. Es war nicht mit Bitness verbunden, es gab nur eine andere DLL, von der Freetype abhängt. Fehlermeldungen könnten jedoch hilfreicher sein.
Diese Hälfte löste mein Problem mit BadImageFormatException - Ich habe vergessen, über die abhängigen DLLs zu kopieren. Leider bekomme ich jetzt DllNotFoundException auf der ursprünglichen DLL ... – jarmond
Bitte markieren Sie diese Frage als beantwortet –
@jarmond stellen Sie sicher, dass Sie Release-Version gebaut (nicht Debug) –
Außerdem für Web-Anwendungsanforderungen lösen 32-Bit-Anwendungen in IIS ausgeführt 7. Siehe http://www.fishofprey.com/2009/04/badimageformatexception-in-iis-70-on-64.html
Ich hatte das gleiche Ausnahme in MS Visual C# Express 2010 Ich habe alle bauen DLL- und EXE-Dateien mit Dependency Walker und MiTeC EXE Explorer wurde alles für 32bit erstellt!
Am Ende war es die folgende Zeile in meiner CSPROJ Datei fehlt:
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'MY_CONFIG|x86'">
...
<PlatformTarget>x86</PlatformTarget>
...
</PropertyGroup>
Ich weiß nicht, warum es fehlte ... ich denke, MS Visual C# Express 2010 nicht bugfree ist;)
Kompilieren Sie die DLL erneut mit der Option "Any CPU" in Build -> Platform.
Das hat mein Problem gelöst! Danke –
Jede CPU ist nicht in der Liste für mich. – ShadowMan
Sie können versuchen, die Option "Eigenschaften" überprüfen -> "Build" -> "Erlaube unsicheren Code".
Ich hatte einen ähnlichen Fehler. Ich könnte es lösen, indem Sie die ucrtbase.dll oder ucrtbased.dll für das Debug sowie die vcruntime140.dll oder vcruntime140d.dll zum Debuggen in das Verzeichnis der ausführbaren Datei hinzufügen. Ich denke, das 140 hängt von der Versionsnummer von Visual Studio ab, die Sie verwenden.
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
Sie weitere Informationen finden Sie hier: http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx
den gleichen Fehler Haben Sie, wenn Sie eine 64-Bit-C-DLL aus C# aufrufen.Ich musste C# Properties->Build->Platform target von Any Cpu zu x64 manuell ändern. Anscheinend ist Any Cpu manchmal NoCpu.
Wenn Sie eine native Anwendung/DLL etwas mit Visual Studio erstellen, erhält es eine Abhängigkeit vom Paket "redistributable" für diese Version von Visual Studio. Das enthält DLLs wie msvcr100.dll und msvcp100.dll (für verschiedene Werte von 100).
In meinem Fall hatte ich diese DLLs im Verzeichnis Windows/system32 der Zielmaschine 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 habe ich mein Visual Studio 2010-Verzeichnis nach allem mit dem Namen msvc*.dll durchsucht und x86-Versionen von msvcr100.dll und msvcp100.dll gefunden. Ich kopierte diese auf die Zielmaschine (an einem Ort, der über den Pfad meines Programms erreichbar war) und alles war gut.
Ich hoffe, dass dies jemand anderen hilft, der mit dem bloßen Wahnsinn von Microsoft konfrontiert wird.
Ich vermute, die gemeinsame Ursache dieser Ausnahme hat sich in den 8 Jahren seit der ersten Frage geändert. mit VS 2017 auf meinem Setup fand ich, dass "Bevorzugen 32-Bit" löste das Problem unchecking:
Uncheck "Prefer 32-bit" in the Build options
Das machte meine 64-Bit-DLL aus C++ Last richtig gebaut. Wenn Sie diese Option aktivieren, sollten 32-Bit-DLLs korrekt geladen werden.
Abstimmung zu schließen als "keine echte Frage" - die Grundlage für die Frage war ein Missverständnis; das OP fand, dass die betreffende DLL korrekt geladen wurde – STW