2010-11-22 11 views
5

Tengo una aplicación de Visual C++ 9 Win32 que utiliza una biblioteca de terceros. Cuando se llama a una función de esa biblioteca con un cierto conjunto de parámetros, el programa se bloquea con el "código de excepción 0xC000000D".El programa se bloquea con 0xC000000D y sin excepciones. ¿Cómo lo depuro?

Intenté adjuntar el depurador de Visual Studio: no se lanzan excepciones (ni C++ ni infracciones de acceso a la estructura como) y tampoco se llama al terminate(). Aún así, el programa simplemente termina en silencio.

¿Cómo ocurre que el programa simplemente finaliza anormalmente pero sin detenerse en el depurador? ¿Cómo puedo localizar el problema?

+0

¿es multiproceso o de un solo hilo? – Simone

+0

@Simone: un hilo de trabajo, varios hilos de servicio generados por RPC. Probamos la sincronización a fondo, es poco probable que el problema sea el multihilo. – sharptooth

+0

¿Está ejecutando una versión de lanzamiento o una versión de depuración? He visto casos extraños de versiones de lanzamiento que no se detienen en el depurador. –

Respuesta

5

Eso es STATUS_INVALID_PARAMETER, utilice WinDbg para localizar a quien lo tiró (es decir, adjunte WinDbg, sxe eh y luego g.

+1

El OP ya dijo que "adjuntar depurador VS - no se lanzan excepciones" ... ¿cómo cambiaría WinDbg la imagen? –

+0

La búsqueda parece indicar que hay funciones que arrojan esto, pero también que hay funciones que usan STATUS_INVALID_PARAMETER como valor de retorno. Así que tal vez no se arroje nada después de todo ... –

+0

@Martin VS ocultará ciertos tipos de excepciones que no sabe cómo manejar (raramente). El uso de WinDbg 100% descarta cualquier tipo de excepción. –

1

Si no tiene información de origen y de depuración para su biblioteca de terceros, no podrá acceder a ella con el depurador. Como lo veo, tus elecciones son;

  • armar un caso de prueba sencilla que ilustra el accidente y enviarlo al desarrollador biblioteca
  • Wrap que la función de biblioteca en su propio código que comprueba los parámetros ilegales y lanzar una excepción/devolver un código de error cuando están aprobada por su propia aplicación
  • reescribir las partes de la biblioteca que no funcionan o que utilizan una alternativa

muy difícil de corregir código que se proporciona como único objeto

Editar También podría ser capaz de salir con más gracia usando __try __finally alrededor de su bucle principal de mensajes, algo así como

int CMyApp::Run() 
{ 
    __try 
    { 
     int i = CWinApp::Run(); 
     m_Exitok = MAGIC_EXIT_NO; 
     return i; 
    } 
    __finally 
    { 
     if (m_Exitok != MAGIC_EXIT_NO) 
      FaultHandler(); 
    } 
} 
+1

Por supuesto, puede ingresar usando el depurador. –

+0

@Paul, claro, pero solo en ensamblador sin el PDB. Con el PDB pero sin fuente, obtienes amablemente anotar assmebler con etiquetas de la fuente. OMI, rara vez vale la pena depurar las manos, ya que se debe hacer una corrección en el ensamblador, lo que llevará mucho tiempo y provocará una futura pesadilla de mantenimiento. –

+0

No creo que el problema de OP haya sido entrar en el código, sino capturar la excepción, que dice que no ocurre. –

2

Otras respuestas y comentarios a la pregunta ayudaron mucho. Esto es lo que hice.

que se da cuenta de que si corro el programa bajo el depurador de Visual Studio que sólo termina en silencio, pero si me quedo sin depurador se bloquea con un cuadro de mensaje (cuadro de mensaje de Windows habitual decir que he perdido mis datos no guardados y todo el mundo es tan lo siento).

Así que comencé el programa sin depurador, lo dejé colgar y luego, mientras el cuadro de mensaje todavía estaba allí, adjunté el depurador y presioné "Salir". Aquí está la pila de llamadas:

[email protected]() 
[email protected]() + 0xc bytes 
[email protected]() - 0x48 bytes 
[email protected]() + 0x18 bytes 
faultrep.dll!StartDWException() + 0x5df bytes 
faultrep.dll!ReportFault() + 0x533 bytes 
[email protected]() + 0x55c bytes 
//SomeThirdPartyLibraryFunctionAddress 
//SomeThirdPartyLibraryFunctionAddress 
//SomeThirdPartyLibraryFunctionAddress 
//SomeThirdPartyLibraryFunctionAddress 
//OurCodeInvokingThirdPartyLibraryCode 

por lo que obviamente es un problema dentro de la biblioteca de la fiesta tripartita. De acuerdo con MSDN, se llama al UnhandledExceptionFilter() en situaciones fatales y claramente la llamada se realiza debido a algún problema en el código de la biblioteca. Intentaremos resolver el problema primero con el proveedor de la biblioteca.

Cuestiones relacionadas