-
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技巧。
-
KB-.NET Windows Form縮骨功?
-
我之前寫過一台潛盾機(潛盾機的典故後面再說)，起因是手邊有幾個網站用的是NT整合式驗證，雖然有測試用的網域跟假帳號，但每次都得重開IE後輸入不同的帳號假扮不同的使用者，很令人抓狂。
所以我寫了一個小工具--IE Impersonate，可以先把不同的帳號密碼儲存起來，由它自動幫你開啟IE，連至特定URL，並在IE跳出登入對話框時自動填入預先指定的帳號、密碼，省去反覆輸入不同帳號密碼的困擾。
這個小程式真的可以省下可觀的按鍵次數及操作時間，很受到幾個常做網站測試同事的歡迎。不過，今天才得到消息，這個程式在部分機器上(Windows XP & Windows 2003都有)展現縮骨功，變成只有120px寬的怪樣子(正常應為430px)。
我懷疑是Windows Form雞婆，自作聰明調動了表單大小，所以認真查了一下Form1物件，看有沒有什麼可疑的屬性，結果發現了一個AutoScaleMode，預設為Font模式。這個名稱一看就讓人起疑，調了一下，設成Gdi或None之後，表單的顯示就完全正常了。
回頭查了一下，找到一篇關於AutoScaleMode的探討文章，而關於AutoScaling的官方文件在這裡。
最後講一下潛盾機的由來。我是個很愛寫小工具改善工作方式的人，有一天同事小娟說了一個故事:
一個教授對他的三個博士班學生說：我們要到高山另一頭的村子買瓶醬油。
第一個學生乖乖地爬了一個月的山，終於把醬油買回來；第二個學生花了數年研發挖山洞專用的TDM潛盾機，並發表三篇Paper拿到博士學位；第三個學生則跑到兩條街外的7-11，五分鐘就把醬油買回來了。
而我就是那個該死的第二個學生，專案常常會Delay不是沒原因的。