Frage

Ich erstelle eine C ++/Cli -DLL, die in eine Legacy C ++ -Anwendung geladen wird. Die Legacy -Anwendung führt dies mit einem herkömmlichen Aufruf zur Lastlibrary. Sowohl die Anwendung als auch die C ++/Cli DLL werden im 64 -Bit -Modus zusammengestellt.

Wenn der Loadlibrary-Aufruf stattfindet, schlägt er bei Fehler 193 fehl. Dies bedeutet normalerweise, dass einige Nicht-6-Bit-Komponenten versucht, sie zu laden. Wenn ich mir die DLL -Lastausgabe in Visual Studio 2010 anschaue, sehe ich, dass der Fehler auftritt, wenn mscoree.dll geladen wird (um genau zu sein, sehe ich meine DLL geladen, dann geladen mscoree, dann mscoree entladen, dann entlastete meine DLL, meine DLL entladen dann wurde der Fehler zurückgegeben). Insbesondere C: Windows System32 mscoree.dll wird geladen, wenn ich diese mscoree.dll untersuche, finde ich, dass sie auf i386 abzielt.

Wie kann ich sicherstellen, dass meine Bewerbung mit dem richtigen mscoree.dll verlinkt wird? Ich verstehe, dass dies mit einem Manifest geschehen könnte, aber ich kann keine guten Informationen über die Einrichtung eines finden. Die ideale Lösung würde die Kompilierung im 32 -Bit- oder 64 -Bit -Modus ermöglichen und auf die richtige mscoree.dll abzielen.

Als Randnotiz fand ich einen MSCOREE.dll in einem von mir verifizierten Side-by-Side-Ordner im 64-Bit-Modus und kopierte ihn in mein Anwendungsverzeichnis, in der Hoffnung, dass er zuerst diesen aufnehmen würde. Dies funktionierte nicht und die Version C: Windows System32 wurde noch geladen.

Vielen Dank,

Max

Ausgabe von corflags.exe auf der 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    : 0

Ausgabe von 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, um Importe und Exporte zu beschreiben, aber das ist hier nicht wichtig.)

Erweiterte Ladeinformationen

Dies ist die vollständige Ausgabe aus fehlgeschlagener Last.

Hinweis: Die C ++/Cli DLL heißt dsfclr.dll
Die Ausgabe wurde durch Ausführen von GFLAGs.exe -i [Exename] +SLS und der Untersuchung der Ergebnisse in einem Debugger erhalten

http://pastebin.com/fyumuimn

AKTUALISIEREN:

Mit einem Tipp, der in einem folgenden Kommentar von Reuben veröffentlicht wurde, konnte ich feststellen, dass mscoree.dll tatsächlich auf AMD64 abzielt, aber Pedump liefert ungültige Informationen, da es in WOW64 ausgeführt wird. Davon abgesehen kann ich diese Bibliothek immer noch nicht laden, wenn jemand Vorschläge hat, wären sie sehr geschätzt.
Eine weitere Sache, die ich ausprobiert habe: Ich habe eine neue C# -Anwendung erstellt und auf die C ++/Cli -DLL verwiesen. In der Funktion main () habe ich eine Klasse in der C ++/Cli DLL instanziiert. Dies führte zu einer Ausnahme von Zugriffsverletzungen, bevor die Funktion main () aufgerufen wird. Wenn ich die Instanziierung entferne, läuft die Hauptfunktion gut. Ich vermute, dass die Instanziierung eine Verzögerungsbelastung meiner C ++/CLI -Baugruppe verursacht, was den gleichen Lastfehler verursacht, den ich bei der nativen Baugruppe gesehen habe.

War es hilfreich?

Lösung

Falls jemand diesen Fehler durchläuft, stellte sich heraus, dass er durch die Verwendung von Boost :: Threading durch meine nativen Bibliotheken verursacht wurde. Die Boost :: Threading -Bibliothek verwendet einige seltsame Kompilierungseinstellungen. Das Ergebnis ist eine statische Bibliothek, die mit CLR- oder Mixed-Mode-Binärdateien nicht kompatibel ist. Natürlich hat Visual Studio keine Ahnung davon, daher steigert es glücklich, wenn die DLL geladen wird.
Die Lösung besteht darin, in Boost :: Threading dynamisch zu verknüpfen. Der einfachste Weg, dies zu tun, besteht darin, Boost_thread_dyn_link in Ihren Projekteinstellungen zu definieren. Sobald ich das definiert habe, wurde die DLL gut geladen.
Eine schnelle Google -Suche nach C ++/CLI Boost -Threading gibt viele weitere Informationen zu diesem Fehler

Andere Tipps

Ich habe nur ein ähnliches Szenario. Lastlibrary ist mit 193 fehlgeschlagen. Meine DLL ist eine verwaltete C ++/Cli -DLL, die von einer nativen Anwendung mit Lastlibrary bezeichnet wird.

Ich bekomme jedoch nur den Fehler auf Win7 -Systemen. Es lädt bei Win10 gut. Das Datum dieser ursprünglichen Frage deutet darauf hin, dass es Win7 war.

Ich habe es auf eine Thread_local -Klasse eingegrenzt. Es scheint, dass Win7 nur grundlegende Typen wie C -Zeiger als Thread_local unterstützt. Alles komplexere, selbst std :: shared_ptr, das Win10 akzeptiert, erzeugt Fehler 193 bei DLL -Last.

Für den Datensatz ist der Compiler VS2015 und der Codestil C ++ 11.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top