Pregunta

Estoy creando una DLL C ++/CLI que se cargará en una aplicación Legacy C ++. La aplicación heredada hace esto con una llamada tradicional a LoadLibrary. Tanto la aplicación como la DLL C ++/CLI se compilan en modo de 64 bits.

Cuando ocurre la llamada de carga de carga, falla con el error 193. Esto generalmente significa que algún componente que no sea de 64 bits está tratando de cargar. Cuando miro la salida de carga de DLL en Visual Studio 2010, veo que la falla se produce cuando se está cargando mscoree.dll (para ser exacto, veo que mi DLL cargó, luego se cargó de mscoree, luego se descarga mscoree, luego mi DLL descarga. , luego se devolvió el error). Específicamente c: windows system32 mscoree.dll se está cargando, cuando examino este mscoree.dll, encuentro que está dirigido a i386.

¿Cómo puedo asegurarme de que mi aplicación se vincule con el mscoree.dll correcto? Entiendo que esto podría hacerse con un manifiesto, pero no puedo encontrar ninguna buena información sobre la configuración de una. La solución ideal permitiría la compilación en modo de 32 bits o 64 bits y se dirigiría al mscoree.dll correcto.

Como nota al margen, encontré un mscoree.dll en una carpeta de lado a lado que verifiqué es el modo de 64 bits y lo copié en mi directorio de aplicaciones con la esperanza de que lo recogiera primero. Esto no funcionó y la versión C: Windows System32 todavía estaba cargada.

Gracias,

Máximo

Salida de corflags.exe en el 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

Salida de pedump.exe en 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 continúa desde aquí para describir las importaciones y exportaciones, pero eso no es importante aquí)

Información de carga extendida

Esta es la salida completa de la carga fallida.

Nota: El DLL C ++/CLI se llama DSFCLR.DLL
La salida se obtuvo ejecutando gflags.exe -i [Exename] +SLS y examinando los resultados en un depurador

http://pastebin.com/fyumuimn

ACTUALIZAR:

Usando un consejo publicado en un comentario a continuación de Reuben, pude determinar que MSCoree.dll está dirigido a AMD64, pero Pedump está proporcionando información no válida porque se está ejecutando en WOW64. Dicho esto, todavía no puedo cargar esta biblioteca, si alguien tiene alguna sugerencia, sería muy apreciado.
Una cosa más que he probado: hice una nueva aplicación C# y hice referencia a la DLL C ++/CLI, luego, en la función Main (), instancié una clase en la DLL C ++/CLI. Esto causó una excepción de violación de acceso antes de que se llame a la función Main (). Cuando elimino la instancia, la función principal funciona bien. Supongo que la instancia está causando una carga de retraso de mi ensamblaje C ++/CLI, lo que causa el mismo error de carga que estaba viendo en el ensamblaje nativo.

¿Fue útil?

Solución

En caso de que alguien atraviese este error, resultó que fue causado por mis bibliotecas nativas de uso de Boost :: Threading. La biblioteca Boost :: Threading utiliza una configuración de compilación extraña. El resultado es una biblioteca estática que es incompatible con CLR o binarios de modo mixto. Por supuesto, Visual Studio no tiene idea de esto, por lo que felizmente vincula el aumento y se bloquea cuando se carga la DLL.
La solución es vincular dinámicamente en Boost :: Threading. La forma más fácil de hacer esto es definir boost_thread_dyn_link en la configuración de su proyecto. Una vez que definí eso, la DLL se cargó bien.
Una búsqueda rápida de Google de C ++/CLI Boost Threading dará mucha más información sobre este error

Otros consejos

Solo tengo un escenario similar. LoadLibrary falló con 193. Mi DLL es una DLL C ++/CLI administrada llamada desde una aplicación nativa con LoadLibrary.

Sin embargo, solo recibo el error en los sistemas Win7. Se carga bien en Win10. La fecha de esta pregunta original sugiere que fue Win7.

Lo reduje a una clase Thread_Local. Parece que Win7 solo admite tipos básicos como Cointers C como Thread_Local. Cualquier cosa más compleja, incluso std :: shared_ptr que Win10 acepta, genera Error 193 en la carga DLL.

Para el registro, el compilador es VS2015, y el estilo de código es C ++ 11.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top