[IIS]为什么应用程序池总是崩溃(Crash)

baacloud免费翻墙vpn注册使用

转载:http://blog.csai.cn/user1/17029/archives/2006/6810.html 
   过了一个既很有意义又很郁闷的五一节,有意义的是为了解决博客园Blog程序中一个奇怪的问题劳动了7天,郁闷的是到现在问题还没解决。
     这个问题的特征可以用一个字形容:怪。
     这个问题的主题:Blog应用程序引起的IIS 6应用程序池崩溃。
     问题的主要现象:
     当把新版的Blog程序投入到正式运行环境中后,一开始运行正常,过几分钟后,打开页面速度就变得很慢,浏览器一直处于请求状态(浏览器右上角的图标一直 在忙碌),却得不到服务器的正常响应,我的理解就是IIS虽然接受了请求,但应用程序池中的程序却不能对请求作出响应,从而让浏览器在苦苦等待。这 时,CPU占用却很少,系统事件日志中会出现这样的警告:    

A process serving application pool 'AppPool_CNBlogs_New' failed to respond to a ping. The process id was '3844'.

我把这样的现象描述为:应用程序池崩溃。
当 应用程序池崩溃时,运行于内核模式的HTTP.SYS会建立一个新的应用程序池进程w3wp.exe 处理新的请求,并回收旧的应用程序池,可新的应用程序池进程运行一会儿又崩溃,IIS又建立新的应用程序池进程,这样反反复复,网站处于一种很不稳定的运 行状态。当IIS回收旧的应用程序池时,系统事件日志中还会出现这样的警告:

A process serving application pool 'AppPool_CNBlogs_New' exceeded time limits during shut down. The process id was '2380'. 

这个警告是通配符映射应用程序存在的通病,可能是通配符映射这样的方式让IIS无法对应用程序池占用的所有资源进行正常回收。
     对于这个问题,大家都知道肯定是程序中的Bug,而关键问题是找出Bug所在,而我七天的努力却一无所获。同样的程序在本机和服务器上测试都很正常,可是 一切换到正式运行环境就出问题。新版本中代码改动不少,但我把主要的改动恢复了也不能解决问题,几天来在代码苦苦寻找Bug的线索也没有收获,也许是很小 的代码问题引起的,但我就是找不到。如果没有一定的线索,即使将所有代码检查一遍,也不一定能找到Bug所在。
     今天,我用Debug Diagnostics Tool 1.0 捕获应用程序池崩溃时的一些信息,Debug Diagnostics Tool 1.0 会在应用程序池崩溃时生成dmp文件并能对dmp文件进行分析,分析的结果是:

the assembly instruction at kernel32!RaiseException+53 in C:\WINDOWS\SysWOW64\kernel32.dll has caused an unknown exception (0xe0434f4d) on thread 56
This exception originated from mscorwks!RaiseTheExceptionInternalOnly+226. 

想看详细结果请下载结果文件(mht文件)。
从分析结果可以看出在程序运行时产生了未处理异常,而该异常让应用程序池崩溃,我接下来的任务是找出这些未处理异常,将参考文章:
1、http://support.microsoft.com/?id=911816
2、http://blogs.msdn.com/tess/archive/2006/04/27/584927.aspx
今天晚上的任务就是找出未处理异常,就写到这,继续去处理这个问题。
希望有经验的朋友能够提供一些参考意见。
一些参考文章:
HOWTO: Understand and Diagnose an Application Pool Crash 
ASP.NET 2.0 Crash case study: Unhandled exceptions
Unhandled exceptions cause ASP.NET-based applications to unexpectedly quit in the .NET Framework 2.0

赞(0) 打赏
分享到: 更多 (0)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏