在应用程序代码中不能被try-catch块捕获的异常 [英] Exceptions that can't be caught by try-catch block in application code

问题描述

MSDN声明 StackOverflowException 不能被try-catch块从.NET Framework 2开始捕获。

MSDN states that StackOverflowException can't be caught by try-catch block starting with .NET Framework 2.

从...开始。 .NET Framework 2.0版，一个StackOverflowException对象不能被try-catch块捕获，相应的进程默认终止。

Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default.

是还有其他一些例外，相同的行为？

Are there any other exceptions with the same behavior?

推荐答案

是的，还有其他一些：

• ThreadAbortedException是特殊的。捕获时总是重新提出，除非catch块调用ResetAbort（）。当CLR执行粗体中止线程时，这是完全不可行的。当AppDomain被卸载时，通常在程序退出时完成。

• The ThreadAbortedException is special. It will always be re-raised when caught unless the catch block calls ResetAbort(). It is entirely uncatchable when the CLR performs a rude abort of the thread. Done when the AppDomain gets unloaded for example, typically at program exit.

由本机代码启动的线程中由非托管代码抛出的任何本机异常都是不可批处理的。常见的情况是启动自己的线程的COM组件。 CLR无力捕获这种异常，它不知道线程，也不能注入一个catch块。如果本机代码没有捕获异常，那么Windows终止进程。

Any native exceptions thrown by unmanaged code in a thread that got started by native code are uncatchable. The common scenario here is COM components that start their own threads. The CLR is powerless to trap such exceptions, it doesn't know about the thread and can't inject a catch block. If the native code doesn't catch the exception then Windows terminates the process.

除非是关键的终结器，否则finalizer抛出任何异常。他们会中止终结进程的终结者线程。

Any exceptions thrown by finalizers, unless they are critical finalizers. They'll abort the finalizer thread which terminates the process.

从.NET 4.0开始，ExecutionEngineException是不可修复的。当它检测到其内部数据结构被泄露时，它被CLR抛出。最常见的是垃圾回收器忙时引发的AccessViolationException异常。当GC堆被破坏时，继续执行托管代码是一个冒险的提议，并且可以利用，.NET 4完全拉出了插件。

Starting with .NET 4.0, an ExecutionEngineException is uncatchable. It is thrown by the CLR when it detects that its internal data structures are compromised. Most typically by an AccessViolationException that's raised while the garbage collector is busy. Continuing to execute managed code when the GC heap is compromised is a risky proposition, and exploitable, .NET 4 pulled the plug on it entirely.

从.NET 4.0版本的CLR，但也可能存在于早期版本中互操作的非托管代码中，Microsoft的安全CRT可以在检测到安全问题时立即终止程序。这实际上并不是一个例外，由于代码认为进程受到损害，并且无法安全处理异常，因此该过程将立即终止。常见的情况是本机功能的堆栈框架被破坏，这是本机代码中常见的问题，病毒代码用于修复返回地址以运行任意代码。一种称为堆栈缓冲区溢出的攻击场景。在.NET 4.0发布之后，CLR代码中有一些虚假的警报，但是在一段时间内我还没有看到任何内容。您可以通过写入超出 stackalloc 的范围来触发此类中止。

Starting with the .NET 4.0 version of the CLR, but possibly also present in unmanaged code that you interop with in earlier versions, Microsoft's secure CRT can terminate a program instantly when a security problem is detected. This is not actually an exception under the hood, the process is instantly terminated since the code considers the process compromised and not capable of safely processing exceptions. A common case is where the stack frame of native function is smashed, a common problem in native code and used by viral code to tinker with the return address to run arbitrary code. An attack scenario called "stack buffer overflow". There were a few false alarms in CLR code, early after the .NET 4.0 release but I haven't seen any in quite a while. You can trigger such an abort yourself by writing beyond the bounds of a stackalloc.

非常臭名昭着的是Windows消息处理程序抛出的异常当您在64位操作系统上的WOW64仿真层中以32位模式运行代码，并附加了一个调试器。以Winforms中的繁琐负载事件而闻名，但对于其他消息和其他运行时环境也是如此。丑恶的细节在这个答案。

Quite infamously, exceptions thrown by Windows message handlers when you run code in 32-bit mode in the WOW64 emulation layer on a 64-bit operating system and you have a debugger attached. Best known for the troublesome Load event in Winforms but also present for other messages and in other runtime environments. The ugly details are in this answer.

从.NET 4.5开始，Microsoft将异常分类为状态异常自定义搜索引擎）。他们可以被捕获，但这只能由顶级的异常处理程序完成，除了为用户的利益生成诊断以及无条件地终止应用程序之外，它不会做任何事情。背景技术可以在这本杂志文章中获得。

Starting with .NET 4.5, exceptions that Microsoft classifies as Corrupted State Exceptions (CSEs). They can be caught, but that should only ever be done by a top-level exception handler that doesn't do anything but generate a diagnostic for the user's benefit and terminates the app unconditionally. Backgrounder is available in this magazine article.

您的代码可以开始运行之前发生的抖动引发的任何异常都无法被捕获或报告。没有编译您的Main（）方法是常见的情况，通常是FileNotFoundException。

Any exception that is thrown by the jitter before your code can start running cannot be caught or reported. Failure to compile your Main() method is the common case, typically a FileNotFoundException.

这篇关于在应用程序代码中不能被try-catch块捕获的异常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！