Causa alternativa de BadImageFormatException en .NET Assembly?

Question

Estoy trabajando en una aplicación de consola .NET 3.5 en C# que usa una DLL no administrada de VC++. Se ejecutó sin problemas cuando trabajé en él hace unas semanas, pero vuelvo hoy y ahora obtengo una BadImageFormatException ("Se intentó cargar un programa con un formato incorrecto. (Excepción de HRESULT: 0x8007000B)).

Mi estación de trabajo de desarrollo ejecuta Windows 7 de 64 bits y trabajo mucho con código no administrado, por lo que inmediatamente compruebo que el ensamblado .NET y la biblioteca VC++ tienen objetivos x86. Lo hicieron.

sólo para estar seguro, he limpiado y reconstruido biblioteca de la VC++ y el ensamblado de .NET, sin ningún resultado.

Ninguno de estos sistemas está haciendo nada particularmente inusual. el VC++ cargas biblioteca un dat binaria un archivo y realiza un procesamiento matemático de sus contenidos. El ensamblado .NET tiene DllImports para la biblioteca y algún código para conectarlo. Todo esto funcionó hace unas semanas.

Así que ahora me pregunto si hay alguna otra causa de BadImageFormatException que sea menos común que un conflicto x86/x64 con el que me pueda encontrar.

Gracias.

EDIT: Obtengo el mismo error independientemente del modo x86 o x64, pero cuando se establece en 'Cualquier CPU', la ejecución pasa ese punto, pero la ejecución finaliza en una llamada posterior a la biblioteca VC++ sin excepción. Independientemente de si eso está relacionado con este problema, ¿hay algo que 'Cualquier CPU' haga de manera diferente tanto de x86 como de x64, lo que podría arrojar algo de luz sobre esto?

Answer 1

Quizás esté intentando cargar un ensamblaje creado para CLR 4.0 en CLR 2.0.

Answer 2

Dado el uso de código nativo aquí, creo que el problema más probable aquí es que está intentando cargar una DLL nativa como si fuera un ensamblado .Net. Este es un escenario que generará un BadImageFormatException.

Intenta ejecutar tu aplicación y configurarla para que se rompa en el lanzamiento para BadImageFormatException y ver qué DLL se está cargando. Si es nativo, ese es el problema.

Answer 3

Cuando obtengo este error, siempre se produce al cargar una DLL de 32 bits en un proceso de 64 bits.

Establezca el archivo EXE para compilar en x86 y ver si funciona.

Answer 4

¡Compruebe si hay un conflicto de carga .dll!

Estaba llamando a un dll C++/CLI desde C#; la biblioteca C++/CLI es un contenedor alrededor de una dll nativa de un tercero.

Resulta que tenía dos dlls con el mismo nombre, ambos en la ruta (libeay32.dll).

Con el fin de descubrir la fuente del problema I instalado Windows herramientas de depuración: http://www.microsoft.com/whdc/devtools/debugging/default.mspx

'gflags' Run (en la "C:... \ Archivos de programa \ Herramientas de depuración" carpeta) con el fin de habilitar la visualización del cargador "instantáneas"

ie

> gflags -i <my test app.exe> +sls 

continuación, ejecute la aplicación en CDB (consola depurador) o windbg y arrastre a través de la salida para saber qué DLL provocó la excepción.

p. Ej.

> cdb -g <my test app.exe> 

Renombrando el 'malo' libeay32.dll demostró el problema, pero es solo una solución temporal.

El mismo enfoque de detección de fallos podría funcionar para usted de todos modos.

Answer 5

En mi caso, desactivar Enable unmanaged code debugging en la pestaña Debug de las propiedades del proyecto EXE irónicamente hizo el truco, si está marcado.

Para ser sincero, no estoy seguro de por qué esa es la causa del problema.