【终极解决方案】为应用程序池“XXX”提供服务的进程在与 Windows Process Activation Service 通信时出现严重错误。该进程 ID 为“XXXX”。数据字段包含错误号。
Posted on 2019-08-30 08:49 yuanws 阅读(748) 评论(0) 编辑 收藏 举报https://www.cnblogs.com/qidian10/p/6028784.html
症状
日志中大量报错,IIS严重错误,此类错误默认情况下5分钟连续出现5次会导致IIS应用程序池直接挂掉,挂掉之后应用基本上是废掉了,访问量越高,挂的越快!
临时补救该错误的一个方法为,调整应用程序池“服务不可用”响应类型为TcpLevel,这样好歹应用程序池不会挂了,但问题依旧存在。
分析症状
0、搜一下,基本都是这个解决方案http://www.cnblogs.com/freeton/archive/2012/08/28/2660585.html,屁用不中
1、按照直接思维,感觉应该是服务器配置上哪里出了问题,应为本机调试环境下,从来没碰到过这个问题,于是乎更换服务器,winserver08=>winserver2012 r2 无奈问题依旧
2、乖乖分析上述日志错误,在系统日志和w3p日志中均未见该异常的描述。上述事件异常中提示,异常代码为0xc00000fd ,解释为栈溢出,基本断定为是程序某个位置出了问题,很可能是死循环造成的,但是具体在哪个问题,无从查起
3、了解到还可以通过dmp文件直接跟踪iis崩溃的原因
找到dmp文件
dmp文件是啥?自己百度。简单的说就是黑匣子,记录程序崩溃前的操作,那么如何找到这个黑匣子呢?
1、启动 Windows Error Reporting Service 服务
2、执行下面注册表脚本,设置w3wp.exe 崩溃时自动抓取dmp文件,保存在D:\dumps文件夹里
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe]
"DumpFolder"=hex(2):64,00,3a,00,5c,00,64,00,75,00,6d,00,70,00,73,00,00,00
"DumpCount"=dword:00000002
"DumpType"=dword:00000002
备注,如果没有D盘,可以保存到C盘,修改一下DumpFolder。"DumpFolder"=hex(2):63,00,3a,00,5c,00,64,00,75,00,6d,00,70,00,73,00,00,00
3、查看dmp文件
IIS崩溃后,在D:\dumps文件夹能看到dmp文件,可以用于分析dmp文件,找出IIS崩溃的原因。
调试dmp文件
如何调试dmp文件,这就不得不请出宇宙第一IDE,VS了,我用的vs2013来调试,可以直接打开dmp文件
1、双击DMP文件会直接进入VS,可以看到Summary信息
2、可选步骤:设置符号路径
3、设置关联源代码路径(可忽略)
4、一切就绪,点击“调试托管内存”
5、查看具体异常原因,定位异常代码位置
打开局部变量和堆栈调试,异常代码位置里面顿现!然后就是找到这个大bug kill它!事件记录终于清爽了!
感激宇宙第一IDE!
2、找到下面这个项
HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\Windows\Windows Error Reporting\LocalDumps
3、在他下面创建一个项,名字为你要检测的程序名。
此项中需要4个值配置
值:DumpFolder, 类型:REG_EXPAND_SZ - 顾名思义,就是存储dump的位置
值:DumpCount, 类型:REG_DWORD - 最大保留的dump个数,默认为10.
值:DumpType, 类型:REG_DWORD - Dump类型,0:Custom dump, 1: Mini dump, 2: Full dump. 默认值为1
值:CustomDumpFlags, 类型:REG_DWORD - 没怎么用,暂时不解释。
b)启动Windows Error Reporting Server服务
服务启动后如果相应程序出现了崩溃的情况,WER就会自动将Crash Dump保存到指定的目录
https://www.cnblogs.com/50614090/p/5602657.html