c# - Excepciones que el bloque try-catch no puede detectar en el código de la aplicación

exception

Question

MSDN declara que StackOverflowException no puede detectarse mediante el bloque try-catch a partir de .NET Framework 2.

A partir de .NET Framework versión 2.0, un bloque try-catch no puede capturar un objeto StackOverflowException y el proceso correspondiente finaliza de forma predeterminada.

¿Hay alguna otra excepción con el mismo comportamiento?

Answer 1

Sí, hay algunos otros:

• La ThreadAbortedException es especial. Siempre se volverá a levantar cuando se detecte, a menos que el bloque catch llame a ResetAbort (). Es completamente imposible de atrapar cuando el CLR realiza un aborto grosero del hilo. Hecho cuando el dominio de aplicación se descarga, por ejemplo, normalmente al salir del programa.

• Cualquier excepción nativa lanzada por un código no administrado en un subproceso que se inició por un código nativo es incatchable. El escenario común aquí son los componentes COM que inician sus propios subprocesos. El CLR es incapaz de atrapar tales excepciones, no conoce el hilo y no puede inyectar un bloque catch. Si el código nativo no detecta la excepción, Windows finaliza el proceso.

• Cualquier excepción lanzada por los finalizadores, a menos que sean finalizadores críticos. Abortarán el hilo finalizador que termina el proceso.

• A partir de .NET 4.0, una ExecutionEngineException es incatchable. El CLR lo lanza cuando detecta que sus estructuras de datos internas están comprometidas. Normalmente, por una excepción AccessViolationException que se genera mientras el recolector de basura está ocupado. Continuar ejecutando el código administrado cuando el montón de GC está comprometido es una propuesta arriesgada y explotable .NET 4 lo desconectó por completo.

• Comenzando con la versión .NET 4.0 del CLR, pero posiblemente también presente en el código no administrado con el que se interopera en versiones anteriores, el CRT seguro de Microsoft puede terminar un programa al instante cuando se detecta un problema de seguridad. Esto no es realmente una excepción bajo el capó, el proceso se termina instantáneamente ya que el código considera que el proceso está comprometido y no es capaz de procesar excepciones de manera segura. Un caso común es cuando el marco de la pila de la función nativa se rompe, un problema común en el código nativo y el código viral lo utiliza para jugar con la dirección de retorno para ejecutar código arbitrario. Un escenario de ataque llamado "desbordamiento de búfer de pila". Hubo algunas falsas alarmas en el código CLR, temprano después del lanzamiento de .NET 4.0, pero no he visto ninguna desde hace bastante tiempo. Puede desencadenar tal aborto escribiendo más allá de los límites de un stackalloc .

• Muy infame, las excepciones lanzadas por los manejadores de mensajes de Windows cuando ejecutas código en modo de 32 bits en la capa de emulación WOW64 en un sistema operativo de 64 bits y tienes un depurador adjunto. Mejor conocido por el problemático evento de carga en Winforms, pero también está presente para otros mensajes y en otros entornos de ejecución. Los detalles feos están en esta respuesta .

• A partir de .NET 4.5, las excepciones que Microsoft clasifica como excepciones de estado dañado (CSE). Se pueden capturar, pero eso solo lo debe hacer un controlador de excepciones de nivel superior que no haga nada pero genere un diagnóstico para el beneficio del usuario y finalice la aplicación de forma incondicional. Backgrounder está disponible en este artículo de la revista .

• Cualquier excepción lanzada por el jitter antes de que su código pueda comenzar a ejecutarse no puede ser detectada o reportada. No compilar su método Main () es el caso común, generalmente una excepción FileNotFoundException.