LoadLibrary 193

Question

Sto creando una DLL C ++/CLI che verrà caricata in un'applicazione C ++ legacy. L'applicazione legacy lo fa con una chiamata tradizionale a LoadLibrary. Sia l'applicazione che la DLL C ++/CLI sono compilati in modalità a 64 bit.

Quando si verifica la chiamata a carico, non riesce con l'errore 193. Questo di solito significa che un componente non 64 bit sta cercando di caricare. Quando guardo l'uscita del carico DLL in Visual Studio 2010, vedo che si verifica il errore quando mscoree.dll viene caricato (per essere esatti, vedo la mia DLL caricata, quindi mSoree caricato, quindi mscorse non caricato, quindi la mia DLL non è stata caricata , quindi l'errore restituito). In particolare C: Windows System32 mscoree.dll viene caricato, quando esamino questo mcoree.dll, trovo che mi prenda di mira i386.

Come posso assicurarmi che la mia applicazione si collega al corretto mscoree.dll? Capisco che questo potrebbe essere fatto con un manifest, ma non riesco a trovare buone informazioni sull'impostazione di una. La soluzione ideale consentirebbe la compilation in modalità 32 bit o 64 bit e target il mSoree.dll corretto.

Come nota a margine, ho trovato una mscoSee.dll in una cartella fianco a fianco che ho verificato è la modalità a 64 bit e l'ho copiata nella mia directory dell'applicazione con la speranza che lo raccogliesse per primo. Questo non ha funzionato e la versione C: Windows System32 è stata ancora caricata.

Grazie,

Max

Output di Corflags.exe su 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

Output di Pedump.exe su 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 continua da qui per descrivere importazioni ed esportazioni, ma non è importante qui)

Informazioni di caricamento esteso

Questo è l'output completo dal carico non riuscito.

Nota: la dll C ++/CLI è chiamata dsfclr.dll
L'output è stato ottenuto eseguendo gflags.exe -i [exename] +SLS ed esaminando i risultati in un debugger

http://pastebin.com/fyumuimn

AGGIORNARE:

Usando un suggerimento pubblicato in un commento seguente di Reuben, sono stato in grado di determinare che mscoSee.dll sta effettivamente prendendo di mira AMD64, ma Pedump sta fornendo informazioni non valide perché viene eseguita in WOW64. Detto questo, non riesco ancora a caricare questa biblioteca, se qualcuno ha qualche suggerimento sarebbe molto apprezzato.
Un'altra cosa che ho provato: ho fatto una nuova applicazione C# e ho fatto riferimento alla DLL C ++/CLI, quindi, nella funzione principale (), ho istanziato una classe nella DLL C ++/CLI. Ciò ha causato un'eccezione di violazione dell'accesso prima che venga chiamata la funzione principale (). Quando rimuovo l'istanza, la funzione principale funziona bene. La mia ipotesi è che l'istanziazione sta causando un carico di ritardo del mio gruppo C ++/CLI, che provoca lo stesso errore di carico che stavo vedendo dall'assemblaggio nativo.

Answer 1

Nel caso in cui qualcuno attraversasse questo errore, si è scoperto che è stato causato dall'uso delle mie biblioteche native di boost :: threading. La libreria di threading Boost :: utilizza alcune strane impostazioni di compilazione. Il risultato è una libreria statica incompatibile con CLR o binari in modalità mista. Naturalmente, Visual Studio non ha idea di questo, quindi si collega felicemente a un aumento e si blocca quando la DLL è caricata.
La soluzione è quella di collegarsi dinamicamente in threading Boost ::. Il modo più semplice per farlo è definire boost_thread_dyn_link nelle impostazioni del tuo progetto. Una volta che l'ho definito, la DLL è stata carinata bene.
Una rapida ricerca su Google di threading C ++/CLI Boost fornirà molte più informazioni su questo errore

Answer 2

Ho solo uno scenario simile. LoadLibrary non è riuscito con 193. La mia DLL è una DLL C ++/CLI gestita chiamata da un'applicazione nativa con carico.

Tuttavia ricevo solo l'errore sui sistemi Win7. Si carica bene su Win10. La data di questa domanda originale suggerisce che era Win7.

L'ho ridotto a una classe thread_local. Sembra Win7 supporta solo tipi di base come i puntatori C come thread_local. Qualcosa di più complesso, anche std :: shared_ptr che Win10 accetta, genera errori 193 sul caricamento DLL.

Per il record, il compilatore è VS2015 e lo stile del codice è C ++ 11.