Las excepciones administradas se implementan utilizando los mecanismos normales de Windows Structured Exception Handling. El código de excepción es 0xe0434f4d. Windows busca un manejador de excepciones que esté dispuesto a manejar la excepción. Si el código no tiene un bloque try activo en la pila, o si ningún bloque catch está dispuesto a atrapar la excepción gestionada, el último grito de sorpresa en el código administrado es el evento AppDomain.UnhandledException.
Si eso no se implementa, ya sea que el manejo de excepciones cambie a un manejo no administrado, un filtro de excepción establecido con SetUnhandledExceptionFilter obtiene una oportunidad. En su defecto, siempre hay un controlador predeterminado proporcionado por Windows. Normalmente invoca WER, el programa de informe de errores de Windows. Eso ofrece al usuario un diálogo para enviar los detalles de la excepción a Microsoft. No esperes nada de eso.
En el momento en que ha progresado más allá de AppDomain.UnhandledException, se pierde toda la información sobre la excepción administrada. Sin seguimiento de pila, sin mensaje de excepción. Solo el código de excepción, que ya conoce, y una dirección de excepción, que no tendrá uso alguno porque el compilador JIT genera dinámicamente el código.
Asegúrese de atrapar la excepción en la última etapa de jadeo, escriba un controlador de eventos para AppDomain.UnhandledException. Registre el valor de e.ExcdeptionObject.ToString() y elimine el programa con Environment.Exit(). También tenga cuidado con el evento Application.ThreadException en el código de Windows Forms y en el evento Dispatcher.UnhandledException en el código WPF. Son una parada para las excepciones que surgen durante el procesamiento de eventos en el hilo de la interfaz de usuario.
Su pregunta no parece ser específica de .net ya que una gran parte de la aplicación en su PC local no son necesariamente aplicaciones .net. – shoosh
Sí, tienes razón. Solo para aclarar, estoy más interesado en los bloqueos causados por las aplicaciones .net porque es más probable que hayan sido causados por mí. – Richard
AFAIK, una excepción .Net no detectada no es un bloqueo. Se produce un bloqueo cuando el sistema operativo detecta una excepción SEH y llama a TerminateProcess. El CLR atrapa una excepción .Net y causa una llamada a ExitProcess, una salida mucho más agradable. – MSalters