c# - Application.ThreadException vs AppDomain.UnhandledException

winforms exception-handling

Question

Primero algunos antecedentes: tengo una aplicación WinForms multiproceso que está haciendo interoperabilidad con dlls nativos. Esta aplicación se cuelga a veces con excepción no controlada y estamos tratando de investigar por qué sucede. Para facilitarlo, estoy creando un controlador global de excepciones y planeo generar un archivo de volcado del proceso a partir de él.

Ahora viene la pregunta: a partir de ahora esta aplicación tiene controlador para Application.ThreadException pero aún se bloquea con una excepción no controlada. Estoy pensando en agregar un controlador para AppDomain.UnhandledException también, aunque no estoy seguro si va a ayudar. ¿Hay alguna excepción no controlada posible en este escenario que no sea detectada por Application.ThreadException ?

Answer 1

Le recomiendo que use la generación de minivolcados del sistema operativo en lugar de la suya. Esto es por varias razones:

1. Generar un minivolcado desde dentro del mismo proceso es extremadamente problemático y no siempre es posible.
2. En el momento en que se ThreadException o UnhandledException , la pila de excepciones ya se ha desenrollado. Generar un minivolcado en ese punto solo lo dirigirá al controlador, no a la fuente de la excepción.

Si su aplicación está en el campo, use WER. Si estás haciendo pruebas internas, usa ProcDump . También puede copiar el archivo de minivolcado mientras el cuadro de diálogo Informes de error está activo.

PD Hay algunas condiciones excepcionales, especialmente cuando se realiza p / Invoke, donde ni ThreadException ni UnhandledException funcionarán.

PPS Si tiene un escenario depurable, intente activar los Asistentes de depuración administrados relacionados con p / Invoke.

Answer 2

Application.ThreadException solo se generará para excepciones no controladas en WinForms UI hilos (ver aquí .) Agregar un controlador para AppDomain.UnhandledException podría ayudar en este caso (aunque con algunas advertencias, como se describe en la sección de comentarios aquí ).

Answer 3

Sí, Application.ThreadException solo puede interceptar excepciones que se generan en el subproceso de UI. En el código que se ejecuta debido a las notificaciones de Windows. O en términos técnicos, los eventos que se desencadenan por el ciclo del mensaje. La mayoría de los eventos de Winforms se ajustan a esta categoría.

Lo que no atrapa son las excepciones planteadas en cualquier hilo que no sea UI, como un hilo de trabajo iniciado con Thread.Start (), ThreadPool.QueueUserWorkItem o el método BeginInvoke () de un delegado. Cualquier excepción no controlada en esos terminará la aplicación, AppDomain.UnhandledException es el último grito de asombro.

Yendo más allá colina abajo, las excepciones de hardware que se generan en un hilo no administrado por código nativo que nunca hizo ninguna llamada CLR administrada no se pueden detectar con ningún mecanismo CLR. Un AccessViolation (código de excepción 0xc0000005) es la causa más común de muerte. La única forma de atraparlos es a través de la API de Windows, SetUnhandledExceptionFilter (). Esto es difícil de hacer bien.

Puede deshabilitar Application.ThreadException con Application.SetUnhandledExceptionMode (). Lo cual es una buena decisión, darle al usuario la opción Continuar no tiene mucho sentido. Ahora todas las excepciones en subprocesos administrados se comportan igual, use AppDomain.UnhandledException para registrarlas.