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

问题描述

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

从 .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?

推荐答案

是的，还有一些其他的:

Yes, there are some others:

• 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.

终结器抛出的任何异常，除非它们是关键终结器.他们将中止终止进程的终结器线程.

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.

从 CLR 的 .NET 4.0 版本开始，但也可能出现在与早期版本互操作的非托管代码中，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.

非常臭名昭著的是，当您在 64 位操作系统上的 WOW64 仿真层中以 32 位模式运行代码并且附加了调试器时，Windows 消息处理程序会抛出异常.最著名的是 Winforms 中麻烦的 Load 事件，但也存在于其他消息和其他运行时环境中.丑陋的细节在 这个答案.

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 将异常归类为损坏状态异常 (CSE).它们可以被捕获，但这只能由顶级异常处理程序完成，该异常处理程序除了为用户的利益生成诊断信息并无条件终止应用程序外，什么都不做.这篇杂志文章中提供了背景资料.

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屋！