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 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奋战的日子里，非常感谢鞠强的帮助!
