在园子的发展过程中，曾经遭遇过多次应用程序池崩溃问题（比如：为什么应用程序池总是崩溃），每次都被搞得精疲力尽，后来稀里糊涂地解决了问题，却没找到问题的真正原因。
而这一次，一天内解决了问题并找到了真正原因。这次与以前有什么不同呢？我想主要的不同是面对问题时心态的改变。心态一变，一切随之而变。
在去年阻挡淘宝图片外链造成的巨量请求时（满园尽是503，记曾经的一次IIS 7性能考验），ISAPI_Rewrite曾经立下了汗马功劳，而这次它却是罪魁祸首。一切皆有可能，解决问题时，不要主观地忽视一些因素。
遇到Crash问题，用WinDbg分析dump文件是王道。之前由于觉得它高深、复杂，不敢轻易用它。而这次只用了两个命令，就找到了问题的线索。做一件事情，要从最难、你最害怕的地方着手。
在解决问题的过程中，这篇文章（Debugging Faulting Application w3wp.exe Crashes）给了我很大的帮助，感谢作者Paul White!
下面分享一下问题的解决过程：
一、系统环境
IIS 7.5 + ASP.NET 4 X64 + Managed Pipeline Mode(Integrated) + ISAPI_Rewrite
注：ISAPI_Rewrite是一个进行URL重写的ISAPI Filter。
猜测1：问题可能与应用程序池以集成模式运行有关，IIS用托管程序处理请求，而ISAPI_Rewrite是非托管程序。
猜测2：请求是由System.Web.Hosting.PipelineRuntime转发给ISAPI_Rewrite的。
二、问题的现象
1. 在事件日志中的体现：
Event ID 5011:
Event ID 1000:
Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 0x4a5bd0eb
Faulting module name: ntdll.dll, version: 6.1.7600.16695, time stamp: 0x4cc7b325
Exception code: 0xc0000005
Fault offset: 0x000000000004c8f4
Faulting process id: 0x29f4
Faulting application start time: 0x01cc55c536f78bbc
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: fe796009-c1ba-11e0-85cd-842b2b196be7
Event ID 1001:
Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Problem signature:
P1: w3wp.exe
P2: 7.5.7600.16385
P3: 4a5bd0eb
P4: ntdll.dll
P5: 6.1.7600.16695
P6: 4cc7b325
P7: c0000005
P8: 000000000004c8f4
P9:
P10:
Attached files:
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_w3wp.exe_bacc1121e4b19011b4fc1a203d345983b1ae9c_1c835602
Analysis symbol:
Rechecking for solution: 0
Report Id: fe796009-c1ba-11e0-85cd-842b2b196be7
Report Status: 0
2. 用户访问时的体现：
如果用户在发出请求后服务器响应的过程中发生Crash（这是猜测，不一定准确），浏览器一直处于连接加载状态，直到出现连接超时或连接重置错误。
如果在Crash已发生时，用户发出访问请求，浏览器会显示：The service is unavailable.
Crash发生后，当前W3P进程会重启，这时访问速度会慢。
另外：由于W3P进程会经常重启，也会造成CPU占用偏高。
三、问题分析
从上面的事件日志1001可以看出，发生Crash时，系统会生成dump文件，文件存放的位置就在日志内容中。
运行WinDbg，通过File>Open Crash Dump打开dump文件（比如WER3300.tmp.hdmp），如下图：
在命令框中输入.loadby sos clr，结果如下图：
继续在命令框中输入!clrstack，结果如下：
0:074> !clrstack
...
OS Thread Id: 0x18d0 (74)
Child SP IP Call Site
0000000010ccf048 0000000076ddfc6a [NDirectMethodFrameStandalone: 0000000010ccf048] System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr, System.Web.RequestNotificationStatus ByRef)
0000000010ccf010 000007fef17bf997 DomainNeutralILStubClass.IL_STUB_PInvoke(IntPtr, System.Web.RequestNotificationStatus ByRef)*** WARNING: Unable to verify checksum for System.Web.ni.dll
*** ERROR: Module load completed but symbols could not be loaded for System.Web.ni.dll
0000000010ccf0e0 000007fef1898994 System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr, IntPtr, IntPtr, Int32)
0000000010ccf280 000007fef1898d32 System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr, IntPtr, IntPtr, Int32)
0000000010ccf2d0 000007fef1896e51 DomainNeutralILStubClass.IL_STUB_ReversePInvoke(Int64, Int64, Int64, Int32)
0000000010ccf538 000007fef974a7bb [ContextTransitionFrame: 0000000010ccf538]
从上面的结果看，Crash是在调用System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion方法时发生的。
用ILSpy查看一下MgdIndicateCompletion的代码：
webengine.dll是什么东东？当时我们没有深究。从这里的代码可以看出这是一个非托管调用，也就是Crash发生在非托管调用时。于是，我们就分析哪些地方会引发非托管调用，能想到的唯一地方就是ISAPI_Rewrite.
同时，我们在网上发现了一篇ISAPI_Rewrite引起应用程序池Crash的文章，而且异常信息显示Crash也是发生在调用System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion时。
难道真的是ISAPI_Rewrite引起的？当时从感情上有点不愿接受，它曾经立过汗马功劳！。。。可能由于之前对它的好感，一直把它忽视了，现在它作为怀疑对象突然出现在眼前，虽然感情有些不能接受，但直觉上觉得就是它。
四、问题解决
别无选择！立即撤下ISAPI_Rewrite，换上URL Rewrite module。（当然其中的过程没这么轻松，要改URL重写规则）
自从昨天晚上换过后，事件日志中的错误信息再也没有出现，CPU占用也降下来了，访问页面也没遇到速度慢、连接超时/重置的问题。
我们终于可以欢呼：这一次，我们成功地解决了IIS应用程序池崩溃的问题！