2009年4月的日子里，每天總有那么幾次，早上、中午或者夜里都可能出現(xiàn)它的身影，不知它給園子里多少朋友帶來了麻煩!，它就是：

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應(yīng)用程序發(fā)生了Crash，開始我們把這個(gè)問題歸罪于應(yīng)用程序本身，走了不少彎路。

而最終發(fā)現(xiàn)這個(gè)問題的最大嫌疑人竟然是：.NET Framework 3.5 SP1(X64)。

當(dāng)我們把應(yīng)用程序池切換到32位模式，503就不再出現(xiàn)。

從事件日志看，問題是在安裝.NET Framework 3.5 SP1后出現(xiàn)的。

在博客程序出現(xiàn)503的期間，社區(qū)程序(http://space.cnblogs.com/)在事件日志中也有同樣的錯(cuò)誤，只不過不是表現(xiàn)為HTTP Error 503，而是瀏覽器一直處于連接狀態(tài)，服務(wù)器無響應(yīng)。當(dāng)切換到32位模式，問題也不再出現(xiàn)。

所以我們推斷：64位.NET Framework 3.5 SP1可能存在Bug，在特定的情況下會讓應(yīng)用程序崩潰。

本想找出這些特定情況，通過Debug Diagnostic Tool v1.1 在503時(shí)生成Userdump，可是Debug Diagnostic Tool v1.1只有x86版本，x64版本的微軟有，但還沒有對外發(fā)布。

用adplus去抓Userdump，簡直是大海撈針，只要發(fā)生線路中止，就會生成Userdump，比如調(diào)用了Response.End()。

還記得Windows Server 2003(IIS 6)+ ASP.NET 2.0 X64的奇怪問題。現(xiàn)在又是X64的問題，看來X64還不是我們想像的那么成熟。

不管怎么樣，總算可以通過回到32位模式解決問題。

面對這樣的問題，我們只能等待微軟發(fā)現(xiàn)并解決這個(gè)問題!希望不要等太久。

在與503奮戰(zhàn)的日子里，非常感謝鞠強(qiáng)的幫助!