【终极解决方案】为应用程序池“XXX”提供服务的进程在与 Windows Process Activation Service 通讯时出现严重错误。该进程 ID 为“XXXX”。数据字段包含错误号。

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，屁用不中

一、按照直接思惟，感受应该是服务器配置上哪里出了问题，应为本机调试环境下，历来没碰到过这个问题，因而乎更换服务器，winserver08=>winserver2012 r2 无奈问题依旧

二、乖乖分析上述日志错误，在系统日志和w3p日志中均未见该异常的描述。上述事件异常中提示，异常代码为0xc00000fd ,解释为栈溢出，基本判定为是程序某个位置出了问题，极可能是死循环形成的，可是具体在哪一个问题，无从查起

三、了解到还能够经过dmp文件直接跟踪iis崩溃的缘由

找到dmp文件

dmp文件是啥？本身百度。简单的说就是黑匣子，记录程序崩溃前的操做，那么如何找到这个黑匣子呢？

一、启动 Windows Error Reporting Service 服务

 

二、执行下面注册表脚本，设置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

三、查看dmp文件

IIS崩溃后，在D:\dumps文件夹能看到dmp文件,能够用于分析dmp文件，找出IIS崩溃的缘由。

调试dmp文件

如何调试dmp文件，这就不得不请出宇宙第一IDE，VS了，我用的vs2013来调试，能够直接打开dmp文件

一、双击DMP文件会直接进入VS，能够看到Summary信息

二、可选步骤：设置符号路径

三、设置关联源代码路径（可忽略）

四、一切就绪，点击“调试托管内存”

五、查看具体异常缘由，定位异常代码位置

打开局部变量和堆栈调试，异常代码位置里面顿现！而后就是找到这个大bug kill它！事件记录终于清爽了！

感激宇宙第一IDE！

 

 

 

 

 

 

 

 

 

二、找到下面这个项

HKEY_LOCAL_MACHINE\SOFTWARE

\Microsoft\Windows\Windows Error Reporting\LocalDumps

三、在他下面建立一个项，名字为你要检测的程序名。

此项中须要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