LoadLibrary 193
Erstelle ich ein C++/CLI-dll, die geladen wird, in eine legacy-c++ - Anwendung. Die legacy-Anwendung tut dies mit einem traditionellen Aufruf von LoadLibrary. Die Anwendung und die C++/CLI-dll kompiliert werden, die in 64-bit-Modus.
Wenn die LoadLibrary-Aufruf passiert, es schlägt fehl mit Fehler 193. Dies bedeutet in der Regel, dass einige nicht-64bit-Komponente zu laden versucht. Wenn ich mir die dll laden Ausgabe in visual studio 2010, ich sehen das der Fehler Auftritt, wenn mscoree.dll geladen wird (um genau zu sein, sehe ich meine dll geladen wird, dann mscoree geladen, dann mscoree entladen, dann meine dll entladen, dann wird der Fehler, der zurückgegeben wird). Speziell C:\Windows\System32\mscoree.dll geladen wird, wenn ich dies zu untersuchen mscoree.dll ich finde, dass es targeting-I386.
Wie kann ich sicherstellen, dass meine Anwendung verknüpft wird gegen die richtigen mscoree.dll? Ich verstehe dies könnte getan werden, mit einem manifest, aber ich finde keine guten Informationen über die Einrichtung eines. Die ideale Lösung wäre compilation im 32bit oder 64bit Modus und wähle das richtige mscoree.dll.
Als seitliche Anmerkung fand ich eine mscoree.dll in einem side-by-side-Ordner, die ich überprüft, ist 64bit-Modus und kopiert es in meine Anwendung ein Verzeichnis mit der Hoffnung, dass Sie abholen würde, dass man ersten. Dies hat nicht funktioniert und die C:\Windows\System32 version war immer noch geladen.
Dank,
Max
Ausgabe CorFlags.exe auf die C++/CLI dll -
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.
Version : v4.0.30319
CLR Header: 2.5
PE : PE32+
CorFlags : 16
ILONLY : 0
32BIT : 0
Signed : 0Ausgabe pedump.exe auf C:\System32\mscoree.dll
PS C:\Windows\System32> pedump.exe .\mscoree.dll
Dump of file .\MSCOREE.DLL
File Header
Machine: 014C (I386)
Number of Sections: 0004
TimeDateStamp: 4B90752B -> Thu Mar 04 22:06:19 2010
PointerToSymbolTable: 00000000
NumberOfSymbols: 00000000
SizeOfOptionalHeader: 00E0
Characteristics: 2102
EXECUTABLE_IMAGE
32BIT_MACHINE
DLL
...(pedump geht von hier aus zu beschreiben, Importe und Exporte, aber das ist hier nicht wichtig)
Erweiterte be-Informationen
Dies ist die vollständige Ausgabe failed load.
Hinweis: Die C++/CLI-dll aufgerufen wird DsfClr.dll
die Ausgabe wurde, die durch das laufen gflags.exe -ich [Programmname] +sls und die Untersuchung der Ergebnisse in einem debugger
UPDATE:
Mit einem Tipp geschrieben, in einen unten Kommentar von Ruben, ich war in der Lage zu bestimmen, dass mscoree.dll ist in der Tat targeting-AMD64, aber pedump ist die Angabe von ungültigen Daten, weil Sie ausgeführt werden, die im WOW64. Dass gesagt wird, ich kann immer noch nicht laden Sie diese Bibliothek, wenn jemand irgendwelche Vorschläge, Sie würde sehr geschätzt werden.
Eine weitere Sache, die ich versucht habe: ich habe ein neues C# - Anwendung und auf die C++/CLI-dll, dann in der main () - Funktion, ich instanziiert eine Klasse in der C++/CLI-dll. Dies verursacht eine Zugriffsverletzung Ausnahme, bevor die main () - Funktion aufgerufen wird. Wenn ich entfernen Sie die Instanziierung, die die main-Funktion läuft einwandfrei. Meine Vermutung ist, dass die Instanziierung verursacht eine Verzögerung laden meiner C++/CLI-assembly, die bewirkt, dass die gleiche Belastung Fehler, die ich sah, von den einheimischen Montage.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Falls jemand läuft über diesen Fehler, es stellte sich heraus, dass es verursacht wurde durch meine native Bibliotheken verwenden von boost::threading. Die boost::threading-Bibliothek verwendet einige seltsame Einstellungen für Zusammenstellung. Das Ergebnis ist eine statische Bibliothek, die nicht kompatibel mit clr-oder mixed-mode-Binärdateien. Natürlich, visual studio hat keine Ahnung von diesem, so dass Sie glücklich links Schub und stürzt ab, wenn die dll geladen wird.
Die Lösung ist dynamisch zu verknüpfen, die in boost::threading. Der einfachste Weg dies zu tun ist, um zu definieren, BOOST_THREAD_DYN_LINK in den Einstellungen Ihres Projektes. Einmal habe ich definiert, dass die dll geladen gut.
Eine schnelle google-Suche nach C++/CLI-boost-threading geben wird, viel mehr Informationen zu diesem Fehler
Ich habe gerade ein ähnliches Szenario.
LoadLibrary fehlgeschlagen mit 193.
Meine DLL ist eine verwaltete C++/CLI-DLL aufgerufen, aus einer nativen Anwendung mit LoadLibrary.
Jedoch bekomme ich nur den Fehler auf win7 Systemen. Es lädt problemlos auf win10. Das Datum der ursprünglichen Frage es vermuten lässt, war win7.
Ich verengt Sie sich auf eine thread_local Klasse.
Es scheint win7 unterstützt nur die grundlegenden Typen wie C Zeiger als thread_local. Etwas komplexere, auch std::shared_ptr, welche win10 akzeptiert, erzeugt Fehler 193 auf Dll laden.
Für den Datensatz, der compiler ist VS2015, und der code-Stil ist c++11.