2008-08-12 4 views
6

Tengo una aplicación MFC compilada con/clr y estoy tratando de implementar un controlador final para las excepciones gestionadas de otra manera no detectadas. Para las excepciones nativas, prevalece el CWinApp::ProcessWndProcException.Gestor de excepciones administrado final en un ejecutable nativo/administrado mixto?

Los dos eventos sugeridos en Jeff CodeProject article, Application.ThreadException y AppDomain.CurrentDomain.UnhandledException, no se generan.

¿Alguien puede sugerir una forma de proporcionar un manejador de excepciones gestionado final para un ejecutable mixto?


Actualización:

Parece que estos controladores de excepciones sólo se lanzan aguas abajo de Application.Run o similar (. Hay un sabor subproceso de trabajo, no recuerdo el nombre) Si se desea capturar verdaderamente a nivel mundial una excepción gestionada, necesita instalar un filtro SEH. No obtendrás un System.Exception y si quieres un callstack, tendrás que mover tu propio andador.

En una pregunta del foro de MSDN sobre este tema, se sugirió anular un punto suficientemente bajo del subproceso MFC principal en try ... catch (Exception^). Por ejemplo, CWinApp::Run. Esta puede ser una buena solución, pero no he analizado ninguna implicación de perf o estabilidad. Tendrás la oportunidad de iniciar sesión con una pila de llamadas antes de fianza y puedes evitar el comportamiento de excepción predeterminado de windows.

+0

Tal vez nos ayudaría saber más acerca de las excepciones que están siendo lanzadas y que no son detectadas por los dos eventos que usted mencionó? – Charlie

+0

Cualquier excepción gestionada en absoluto: cualquier heredero de System :: Exception. El objetivo de los eventos anteriores es disparar cuando no se detecta ninguna excepción gestionada/any/managed. –

Respuesta

2

Echando un vistazo alrededor de los internets, usted encontrará que es necesario instalar un filtro para obtener las excepciones no administrados pasa por los filtros en su camino hacia su AppDomain. De CLR and Unhandled Exception Filters:

El CLR se basa en el mecanismo de filtro de excepciones no controladas SEH para detectar excepciones no controladas.

0

El uso de estos dos manejadores de excepciones debería funcionar. ¿Seguro que la has añadido en un lugar donde van a ser llamado y establecer correctamente (es decir, en su aplicación de logró punto de entrada - que pusiste en uno, ¿verdad?)

+0

Creo que el problema es que no hay aplicación. Ejecutar en cualquier lugar. –

1

Usar esos dos manejadores de excepciones debería funcionar.

¿Por qué "should?"

Los acontecimientos no son criados mediante el siguiente:

extern "C" void wWinMainCRTStartup(); 

// managed entry point 
[System::STAThread] 
int managedEntry(void) 
{ 
    FinalExceptionHandler^ handler = gcnew FinalExceptionHandler(); 

    Application::ThreadException += gcnew System::Threading::ThreadExceptionEventHandler(
             handler, 
             &FinalExceptionHandler::OnThreadException); 

    AppDomain::CurrentDomain->UnhandledException += gcnew UnhandledExceptionEventHandler(
                 handler, 
                 &FinalExceptionHandler::OnAppDomainException); 

    wWinMainCRTStartup(); 

    return 0; 
} 

// final thread exception handler implementation 
void FinalExceptionHandler::OnThreadException(Object^ /* sender */, System::Threading::ThreadExceptionEventArgs^ t) 
{ 
    LogWrapper::log->Error("Unhandled managed thread exception.", t->Exception); 
} 

// final appdomain exception handler implementation 
void FinalExceptionHandler::OnAppDomainException(System::Object ^, UnhandledExceptionEventArgs ^args) 
{ 
    LogWrapper::log->Error("Unhandled managed appdomain exception.", (Exception^)(args->ExceptionObject)); 
} 

BOOL CMyApp::InitInstance() 
{ 
    throw gcnew Exception("test unhandled"); 
    return TRUE; 
} 
Cuestiones relacionadas