KB-W3SVC throw 0x800703e9 exception

今天幫忙排除一台主機的IIS問題，只要執行特定網頁，就會出現以下訊息:
JIT偵錯失敗，發生以下錯誤: 存取被拒。
JIT偵錯是使用者帳戶'NT AUTHORITY\NETWORK SERVICE'所啟動。
如需詳細資訊，請在文件索引中查看'Just-in-time偵錯，錯誤'。

事實上，這是一個表面的錯誤訊息，根本的問題不在於執行權限不對，或是有人Debug Web App失敗，而是執行ASP.NET的底層的.NET程式發生錯誤所致。真正的錯誤訊息則可以在事件檢視器中看到，W3SVC發出了以下的錯誤:

伺服應用程式集區 'DefaultAppPool' 的處理序已意外中止了。處理序識別碼為 '2488'。處理序結束碼為 '0x800703e9'。
(英文原文為A process serving application pool 'DefaultAppPool' terminated unexpectedly. The process id was '2488'. The process exit code was '0x800703e9'.)

這是一個很棒的錯誤訊息，用0x800703e9 Goggle一下就可以找到"Debugger Lady" Tess的Blog文章，裡面提到了一個案例，因為Exception Handling中又觸發同樣的Exception而導致無止盡的Recursive，最後以Recursion too deep, StackOverFow收場。我請同事特別檢查Exception Handling部分的Logic，果然找到以下的奪命陷阱:

pubic string GetDbCnnString()
{
    try
    {
        ...從web.config取得DbCnnString設定值...
    }
    catch (找不到值的Exception) 
    {
        LogErrorToDb("找不到DbCnnString!");
    }
}

哈! 當找不到DbCnnString時，試著要將Error Log到DB，在LogErrorToDb()中少不了又要呼叫GetDbCnnString()。Bingo! 無窮迴圈~~~ 跟Debugger Lady所提到的Scenario完全相同。找到根源，問題當然就迎刃而解了，Case Closed!

題外話，我在Scott Hanselman的Blogroll中見識到Debugger Lady這號人物，如Scott所形容的，她神奇到讓你覺得自己很笨。她的Blog上有一個又一個案例，解析龐大的Memory Dump檔，像CSI影集一樣抽絲剝繭，還原命案現場，然後揪出導致當機的凶手。只可惜自已在.NET Runtime上沒下什麼苦功，除了一邊看文章，一邊膜拜之外，永遠學不會她出神入化的.NET Debugging技巧。