2013-10-30 65 views
5

我們有一種情況,我們的應用程序有時會提出ExecutionEngineException。我認爲,當它發生時,應用程序應該崩潰,但它不會崩潰。即使事件查看器聲稱應用程序已終止 - 它仍會繼續運行!只是似乎這個冒犯的線程被默默地殺死了。如何讓.NET 4拋出ExecutionEngineException?

問題在於我們無法在發生條件時重新創建條件 - 在發生異常之前執行可疑代碼幾千次。日誌中沒有任何內容。總之 - 我們感到困惑。

我希望能夠隨意產生這個異常,以便了解我們的應用程序在發生時的行爲。當然,它必須由框架本身拋出,發行throw new ExecutionEngineException不算。

所以,我的問題是 - 我怎樣才能可靠地導致它?請提供代碼示例。

我們對.NET 4中,很快移動到.NET 4.5

回答

3

MSDN documentation

在某些情況下,針對.NET框架的應用程序時可以 拋出一個異常ExecutionEngineException垃圾回收 當一個應用程序或它運行的系統是在一個 重負載下。在這種情況下,要解決此問題,可以通過修改應用程序的 配置文件來禁用 併發垃圾回收。有關更多信息,請參閱 How to: Disable Concurrent Garbage Collection

如果MSDN文檔建議的解決方法不適用於您,則必須根據您對軟件的瞭解進行測試。

現在,創建一個模擬真實應用程序的加載,多線程行爲和內存消耗的測試應用程序是一回事 - 將實際軟件用作測試軟件可能會更好(可能會增加一些額外的調試日誌記錄+測試代碼)。這意味着,不幸的是,這裏沒有代碼示例:(

爲了使負載測試有意義,您還需要在測試系統上運行這些測試,該測試系統與您的生產系統具有非常相似的硬件/軟件配置。只有這樣你才能發現你的ExecutionEngineException是由GC引起還是由於其他原因造成的運行時錯誤

+0

我相當相信EEE可以在壓力較小的情況下發生。瀏覽網頁會產生一個動態發出IL代碼的印象,可能會導致此類異常。 – mark

+0

如果越野車「手工製作」的IL代碼是罪魁禍首,那麼首先猜測,您的問題可能會以一致的方式重複出現。這個問題只是「有時」發生,因爲第一個猜測指出了有關耗盡資源或競爭條件的一些問題。無論如何,所有這些都是可能的原因,你將沒有其他辦法,而不是檢查每種可能性,直到找到問題的原因:( – elgonzo

1

除非你重現問題,否則你不能輕易導致ExecutionEngineException(即使你必須在生產中這樣做環境)微軟有DebugDiag等實用工具,可幫助您在發生此類異常情況時捕獲全部內存轉儲,

http://blogs.msdn.com/b/chaun/archive/2013/09/15/steps-to-trigger-a-user-dump-of-a-process-with-debugdiag-1-2-when-a-specific-net-exception-is-thrown.aspx

並通過轉儲分析很容易找到罪魁禍首。不要期望你的日誌可以告訴,因爲當這種異常發生時,CLR崩潰,並且你的日誌永遠不會那麼深。

+0

這就是問題所在,CLR不會崩潰,我不會發布此問題如果我們只是簡單地通過分析轉儲來解決這個問題,那麼懷疑可以提出的代碼來自http://fasterflect.codeplex.com/ - 一個相當經過測試的庫,再加上我已經提到過,同樣的路徑已經被執行千次之前,EEE的條件出現我仍然不相信這種異常不會在實驗室中隨意產生 – mark

+1

「不會崩潰」是不合適的當這種異常發生時CLR不能可靠地恢復自己過程終止並不總是我們追逐的國旗如果你只考慮終止爲崩潰,那麼請讓我知道,我將刪除我上面無用的答案。實際上你使用的開源庫非常危險,因爲它可能會遇到.NET Framework的迴歸問題,因爲它可以直接操縱IL。既然你想在實驗室重現它,我祝你好運。 –

相關問題