應用程序代碼中的try-catch塊無法捕獲的異常

Question

MSDN聲明，從.NET Framework 2開始， try-catch塊無法捕獲 StackOverflowException 。

從.NET Framework 2.0版開始，try-catch塊無法捕獲StackOverflowException對象，默認情況下會終止相應的進程。

是否存在相同行為的其他異常？

Answer 1

是的，還有其他一些：

• ThreadAbortedException是特殊的。 除非catch塊調用ResetAbort（），否則在捕獲時將始終重新引發它。 當CLR執行線程的粗暴中止時，它完全無法捕獲。 例如，在AppDomain卸載時完成，通常在程序退出時完成。

• 由本機代碼啟動的線程中的非托管代碼拋出的任何本機異常都是無法捕獲的。 這里常見的場景是啟動自己的線程的COM組件。 CLR無法捕獲此類異常，它不知道線程並且無法注入catch塊。 如果本機代碼未捕獲異常，則Windows將終止該進程。

• 終結者拋出的任何異常，除非它們是關鍵的終結者。 他們將中止終結進程的終結器線程。

• 從.NET 4.0開始，ExecutionEngineException無法捕獲。 當CLR檢測到其內部數據結構受到破壞時，它會拋出它。 最常見的是在垃圾回收器忙時引發的AccessViolationException。 當GC堆被泄露時繼續執行托管代碼是一個冒險的命題，並且可利用，.NET 4完全取消了它。

• 從CLR的.NET 4.0版本開始，但可能也存在於您在早期版本中互操作的非托管代碼中，Microsoft的安全CRT可以在檢測到安全問題時立即終止程序。 這實際上並不是一個例外，由於代碼認為流程受到破壞而無法安全地處理異常，因此流程會立即終止。 常見的情況是本機函數的堆棧幀被粉碎，這是本機代碼中的常見問題，並且由病毒代碼用於修改返回地址以運行任意代碼。 一種稱為“堆棧緩沖區溢出”的攻擊場景。 在.NET 4.0發布之后的早期，CLR代碼中出現了一些錯誤警報但我在很長一段時間內都沒有看到過。 您可以通過寫入stackalloc的范圍來自行觸發此類中止。

• 相當臭名昭着，當您在64位操作系統上的WOW64仿真層中以32位模式運行代碼並且連接了調試器時，Windows消息處理程序拋出異常。 以Winforms中令人煩惱的Load事件而聞名，但也出現在其他消息和其他運行時環境中。 丑陋的細節在這個答案中 。

• 從.NET 4.5開始，Microsoft將其歸類為損壞狀態異常 （CSE）的異常 。 它們可以被捕獲，但這應該只能由頂級異常處理程序完成，該處理程序除了為用戶的利益生成診斷並無條件終止應用程序之外什么都不做。 Backgrounder可以在這篇雜志文章中找到 。

• 無法捕獲或報告在代碼開始運行之前抖動引發的任何異常。 編譯Main（）方法失敗是常見的情況，通常是FileNotFoundException。