ISAPI_Rewrite引起的IIS应用程序池崩溃(fatal communication error)

在园子的发展过程中,曾经遭遇过多次应用程序池崩溃问题(比如:为什么应用程序池总是崩溃),每次都被搞得精疲力尽,后来稀里糊涂地解决了问题,却没找到问题的真正原因。

而这一次,一天内解决了问题并找到了真正原因。这次与以前有什么不同呢?我想主要的不同是面对问题时心态的改变。心态一变,一切随之而变。

在去年阻挡淘宝图片外链造成的巨量请求时(满园尽是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:

A process serving application pool 'cnblogs_com' suffered a fatal communication error with the Windows Process Activation Service. The process id was '10740'. The data field contains the error number.

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应用程序池崩溃的问题!

posted @ 2011-08-09 11:53  dudu  阅读(15924)  评论(22编辑  收藏  举报