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


Comments

# by Billy

thanks,问题如你所述,一摸一样,解决了。

Post a comment


63 - 53 =