仓酷云

标题: ASP.NET网页编程之ISAPI_Rewrite引发的IIS使用程序池溃散(fatal communication error) 仓酷云 ... [打印本页]

作者: 仓酷云 时间: 2015-1-18 11:21
标题: ASP.NET网页编程之ISAPI_Rewrite引发的IIS使用程序池溃散(fatal communication error) 仓酷云 ...
说句实话，net网页编程跨平台根本就不是外行人想想的那种，一次编译，处处运行。在园子的开展过程当中，已经遭受过量次使用程序池溃散成绩（好比：为何使用程序池老是溃散），每次都被弄得精疲力尽，厥后莫名其妙地办理了成绩，却没找到成绩的真正缘故原由。
而这一次，一天内办理了成绩并找到了真正缘故原由。此次与之前有甚么分歧呢？我想次要的分歧是面临成绩时心态的改动。心态一变，统统随之而变。
在客岁反对淘宝图片外链酿成的巨量哀求时（满园尽是503，记已经的一次IIS7功能磨练），ISAPI_Rewrite已经立下了丰功伟绩，而此次它倒是祸首罪魁。统统皆有大概，办理成绩时，不要客观地无视一些要素。
碰到Crash成绩，用WinDbg剖析dump文件是霸道。之前因为以为它深邃、庞大，不敢容易用它。而此次只用了两个命令，就找到了成绩的线索。做一件事变，要从最难、你最惧怕的中央动手。
在办理成绩的过程当中，这篇文章（DebuggingFaultingApplicationw3wp.exeCrashes）给了我很年夜的匡助，感激作者PaulWhite!
上面分享一下成绩的办理历程：
1、体系情况
IIS7.5+ASP.NET4X64+ManagedPipelineMode(Integrated)+ISAPI_Rewrite
注：ISAPI_Rewrite是一个举行URL重写的ISAPIFilter。
推测1：成绩大概与使用程序池以集成形式运转有关，IIS用托管程序处置哀求，而ISAPI_Rewrite长短托管程序。
推测2：哀求是由System.Web.Hosting.PipelineRuntime转发给ISAPI_Rewrite的。
2、成绩的征象
1.在事务日记中的表现：
EventID5011:
Aprocessservingapplicationpoolcnblogs_comsufferedafatalcommunicationerrorwiththeWindowsProcessActivationService.Theprocessidwas10740.Thedatafieldcontainstheerrornumber.EventID1000:
Faultingapplicationname:w3wp.exe,version:7.5.7600.16385,timestamp:0x4a5bd0eb
Faultingmodulename:ntdll.dll,version:6.1.7600.16695,timestamp:0x4cc7b325
Exceptioncode:0xc0000005
Faultoffset:0x000000000004c8f4
Faultingprocessid:0x29f4
Faultingapplicationstarttime:0x01cc55c536f78bbc
Faultingapplicationpath:c:windowssystem32inetsrvw3wp.exe
Faultingmodulepath:C:WindowsSYSTEM32
tdll.dll
ReportId:fe796009-c1ba-11e0-85cd-842b2b196be7
EventID1001:
Faultbucket,type0
EventName:APPCRASH
Response:Notavailable
CabId:0
Problemsignature:
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:
Attachedfiles:
Thesefilesmaybeavailablehere:
C:ProgramDataMicrosoftWindowsWERReportQueueAppCrash_w3wp.exe_bacc1121e4b19011b4fc1a203d345983b1ae9c_1c835602
Analysissymbol:
Recheckingforsolution:0
ReportId:fe796009-c1ba-11e0-85cd-842b2b196be7
ReportStatus:0
2.用户会见时的表现：
假如用户在收回哀求后服务器呼应的过程当中产生Crash（这是推测，纷歧定正确），扫瞄器一向处于毗连加载形态，直到呈现毗连超时或毗连重置毛病。
假如在Crash已产生时，用户收回会见哀求，扫瞄器会显现：Theserviceisunavailable.
Crash产生后，以后W3P历程会重启，这时候会见速率会慢。
别的：因为W3P历程会常常重启，也会形成CPU占用偏高。
3、成绩剖析
从下面的事务日记1001能够看出，产生Crash时，体系会天生dump文件，文件寄存的地位就在日记内容中。
运转WinDbg，经由过程File>OpenCrashDump翻开dump文件（好比WER3300.tmp.hdmp），以下图：

<br>
在命令框中输出.loadbysosclr，了局以下图：

<br>
持续在命令框中输出!clrstack，了局以下：
0:074>!clrstack
...
OSThreadId:0x18d0(74)
ChildSPIPCallSite
0000000010ccf0480000000076ddfc6a[NDirectMethodFrameStandalone:0000000010ccf048]System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr,System.Web.RequestNotificationStatusByRef)
0000000010ccf010000007fef17bf997DomainNeutralILStubClass.IL_STUB_PInvoke(IntPtr,System.Web.RequestNotificationStatusByRef)***WARNING:UnabletoverifychecksumforSystem.Web.ni.dll
***ERROR:ModuleloadcompletedbutsymbolscouldnotbeloadedforSystem.Web.ni.dll
0000000010ccf0e0000007fef1898994System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr,IntPtr,IntPtr,Int32)
0000000010ccf280000007fef1898d32System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr,IntPtr,IntPtr,Int32)
0000000010ccf2d0000007fef1896e51DomainNeutralILStubClass.IL_STUB_ReversePInvoke(Int64,Int64,Int64,Int32)
0000000010ccf538000007fef974a7bb[ContextTransitionFrame:0000000010ccf538]
从下面的了局看，Crash是在挪用System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion办法时产生的。
用ILSpy检察一下MgdIndicateCompletion的代码：

<br>
webengine.dll是甚么东东？事先我们没有穷究。从这里的代码能够看出这是一个非托管挪用，也就是Crash产生在非托管挪用时。因而，我们就剖析哪些中央会激发非托管挪用，能想到的独一中央就是ISAPI_Rewrite.
同时，我们在网上发明了一篇ISAPI_Rewrite引发使用程序池Crash的文章，并且非常信息显现Crash也是产生在挪用System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion时。
岂非真的是ISAPI_Rewrite引发的？事先从情感上有点不肯承受，它已经立过丰功伟绩！。。。大概因为之前对它的好感，一向把它无视了，如今它作为嫌疑对象俄然呈现在长远，固然情感有些不克不及承受，但直觉上以为就是它。
4、成绩办理
别无选择！当即撤下ISAPI_Rewrite，换上URLRewritemodule。（固然个中的历程没这么轻松，要改URL重写划定规矩）
自从今天早晨换事后，事务日记中的毛病信息再也没有呈现，CPU占用也降上去了，会见页面也没碰到速率慢、毗连超时/重置的成绩。
我们终究能够喝彩：这一次，我们乐成地办理了IIS使用程序池溃散的成绩！
语言是不是不是最重要的？

作者: 柔情似水 时间: 2015-1-29 05:12
ASP.NET:ASP.net是Microsoft.net的一部分，作为战略产品，不仅仅是ActiveServerPage(ASP)的下一个版本；它还提供了一个统一的Web开发模型，其中包括开发人员生成企业级Web应用程序所需的各种服务。ASP.NET的语法在很大程度上与ASP兼容，同时它还提供一种新的编程模型和结构，可生成伸缩性和稳定性更好的应用程序，并提供更好的安全保护。

作者: 活着的死人 时间: 2015-1-31 12:52
在一个项目中谁敢保证每天几千万甚至几亿条的数据不丢失?谁敢保证应用的高可靠性？有可以借签的项目吗？

作者: 小妖女 时间: 2015-1-31 20:30
HTML:当然这是网页最基本的语言,每一个服务器语言都需要它的支持,要学习,这个肯定是开始,不说了.

作者: admin 时间: 2015-2-5 20:06
平台无关性是PHP的最大优点，但是在优点的背后，还是有一些小小的缺点的。如果在PHP中不使用ODBC，而用其自带的数据库函数（这样的效率要比使用ODBC高）来连接数据库的话，使用不同的数据库，PHP的函数名不能统一。这样，使得程序的移植变得有些麻烦。不过，作为目前应用最为广泛的一种后台语言，PHP的优点还是异常明显的。

作者: 再见西城 时间: 2015-2-11 01:51
平台无关性是PHP的最大优点，但是在优点的背后，还是有一些小小的缺点的。如果在PHP中不使用ODBC，而用其自带的数据库函数（这样的效率要比使用ODBC高）来连接数据库的话，使用不同的数据库，PHP的函数名不能统一。这样，使得程序的移植变得有些麻烦。不过，作为目前应用最为广泛的一种后台语言，PHP的优点还是异常明显的。

作者: 若相依 时间: 2015-2-11 03:55
众所周知，Windows以易用而出名，也因此占据不少的服务器市场。

作者: 爱飞 时间: 2015-2-23 09:28
ASP是把代码交给VBScript解释器或Jscript解释器来解释，当然速度没有编译过的程序快了。

作者: 简单生活 时间: 2015-3-5 00:48
主流网站开发语言之ASP:ASP是微软（Microsoft）所开发的一种后台脚本语言，它的语法和VisualBASIC类似，可以像SSI（ServerSideInclude）那样把后台脚本代码内嵌到HTML页面中。虽然ASP简单易用，但是它自身存在着许多缺陷，最重要的就是安全性问题。

作者: 金色的骷髅 时间: 2015-3-7 12:09
平台无关性是PHP的最大优点，但是在优点的背后，还是有一些小小的缺点的。如果在PHP中不使用ODBC，而用其自带的数据库函数（这样的效率要比使用ODBC高）来连接数据库的话，使用不同的数据库，PHP的函数名不能统一。这样，使得程序的移植变得有些麻烦。不过，作为目前应用最为广泛的一种后台语言，PHP的优点还是异常明显的。

作者: 山那边是海 时间: 2015-3-15 04:05
但是java靠开源打出的一片天地，特别是在微软的垄断下能打开今天的局面还是有它的生命力的。

作者: 飘飘悠悠 时间: 2015-3-21 17:42
Asp.net脚本的出现，为ASP空间带来了更高的稳定性，同时也为程序员建站提供更高环境!

欢迎光临仓酷云 (http://ckuyun.com/)