2009年4月的日子裡，每天總有那麼幾次，早上、中午或者夜裡都可能出現它的身影，不知它給園子裡多少朋友帶來了麻煩!，它就是：
HTTP Error 503. The service is unavailable
伴隨著503，事件日志會記錄下列信息：
1)Event ID 1023: .Net Runtime version 2.0.50727.4013 - Fatal Execution Engine Error (000007FEF94BA5C6) (80131506)
2)Event ID 1000: Faulting application w3wp.exe, version 7.0.6001.18000, time stamp 0x47919ed8, faulting module mscorwks.dll, version 2.0.50727.4013, time stamp 0x498d1a0f, exception code 0xc0000005, fault offset 0x00000000002ce6f0, process id 0x%9, application start time 0x%10.
3)Event ID 5010: A process serving application pool 'cnblogs' failed to respond to a ping. The process id was '10576'
也就是.Net應用程序發生了Crash，開始我們把這個問題歸罪於應用程序本身，走了不少彎路。
而最終發現這個問題的最大嫌疑人竟然是：.Net Framework 3.5 SP1(X64)。
當我們把應用程序池切換到32位模式，503就不再出現。
從事件日志看，問題是在安裝.Net Framework 3.5 SP1後出現的。
在博客程序出現503的期間，社區程序(http://space.cnblogs.com/)在事件日志中也有同樣的錯誤，只不過不是表現為HTTP Error 503，而是浏覽器一直處於連接狀態，服務器無響應。當切換到32位模式，問題也不再出現。
所以我們推斷：64位.Net Framework 3.5 SP1可能存在Bug，在特定的情況下會讓應用程序崩潰。
本想找出這些特定情況，通過Debug Diagnostic Tool v1.1 在503時生成Userdump，可是Debug Diagnostic Tool v1.1只有x86版本，x64版本的微軟有，但還沒有對外發布。
用adplus去抓Userdump，簡直是大海撈針，只要發生線路中止，就會生成Userdump，比如調用了Response.End()。
還記得Windows Server 2003(IIS 6)+ ASP.Net 2.0 X64的奇怪問題。現在又是X64的問題，看來X64還不是我們想像的那麼成熟。
不管怎麼樣，總算可以通過回到32位模式解決問題。
面對這樣的問題，我們只能等待微軟發現並解決這個問題!希望不要等太久。
在與503奮戰的日子裡，非常感謝鞠強的幫助!
