violación de acceso cuando se ejecuta aplicaciones C ++ nativo que utiliza un / CLR DLL construidos

Question

Estoy reorganzing un legado mixto (DLL administrados y no administrados) aplicación de manera que el segmento principal de la aplicación es administrado MFC y que voy a llamar a un DLL de C ++ compilado con / clr bandera que va a cerrar la comunicación entre el administrado (C # DLL) y el código no administrado. Desafortunadamente, mi cambiado han dado lugar a una violación de acceso que se produce antes de la aplicación InitInstance () se llama. Esto hace que sea muy difícil de depurar. La única información que tengo es el siguiente seguimiento de la pila.

>   64006108()  
ntdll.dll!_ZwCreateMutant@16()  + 0xc bytes 
kernel32.dll!_CreateMutexW@12()  + 0x7a bytes   

Por lo tanto, aquí hay algunos sceanrios que he probado.
- Se activa Excepciones-> Win32 Excepciones-> c0000005 acceso Violación de romper cuando se lanza. Aún así, la mayoría de los detalles que se ve es de la traza de la pila anterior. He probado la aplicación con F10, pero falla antes de que los puntos de ruptura son golpeados y falla con el seguimiento de la pila anterior.
-. He apagó la DLL puente de modo que sólo tiene un método que devuelve un bool y que método es simplemente falsa codificados para retorno (sin código de C # llamado)

bool DllPassthrough::IsFailed() { return false; }

Si la apagó DLL se compila con la bandera / CLR, la aplicación falla. Si se compila sin el / la bandera de CLR, se ejecuta la aplicación.
- He creado una aplicación MFC talón mediante el asistente de Visual Studio para aplicaciones multidocumento y llamo DllPassthrough :: IsFailed (). Esto sucede incluso con la bandera / CLR utilizado para compilar la DLL.
- He intentado hacer un LoadLibrary manual sobre Winmm.lib como se indica en la siguiente nota violación de acceso cuando se utiliza C ++ / CLI . La aplicación sigue fallando.
Por lo tanto, mis preguntas son cómo resolver el problema? ¿Alguna pista, estrategias o incidentes anteriores. Y, en su defecto, ¿cómo puedo obtener más información sobre qué segmento de código o biblioteca que está causando la excepción de acceso? Si intento soluciones más complicadas como hacer llamadas LoadLibrary, me gustaría limitar la búsqueda a las bibliotecas que fallan.
Gracias. Por cierto, estamos utilizando Visual Studio 2008 y el proyecto se está construyendo contra el marco .NET 2.0 para las secciones administradas.

Answer 1

Creo que resolver mi problema. Al eliminar sistemáticamente cada referencia de la biblioteca y comentando las llamadas a esa biblioteca particular en el código de la aplicación (no administrado), al final me quité la biblioteca problema y tengo el programa a ejecutar. Es una forma de fuerza bruta para diagnosticar el problema, y ??afortunadamente yo no tenga que quitar muchas bibliotecas para resolverlo. Todavía estaría ansioso por ver si alguien tiene un comentario si la biblioteca podría haber sido identificado, aunque el depurador.
Por lo tanto, el siguiente paso es mover estas llamadas a las bibliotecas a código administrado y pasar la parte posterior información al lado no administrado a través de mi puente DLL. Por cierto, me reintegran los Winmm.lib en el proyecto y todavía funciona.