事件ID(54)的描述(在资源(HTTP)中)无法找到 解决办法

现象：

事件 ID ( 54 )的描述(在资源( HTTP )中)无法找到。本地计算机可能没有必要的注册信息或消息 DLL 文件来从远程计算机显示消息。您可能可以使用 /AUXSOURCE= 标识来检索词描述；查看帮助和支持以了解详细信息。下列信息是事件的一部分: \Device\Http\AppPool.

解决办法1：

相信这是由于不正确地设置了回收进程导致，建议关闭下列进程回收设置：
回收工作进程(分钟)：1200
回收工作进程(请求数目)：10000
启用CPU监视，最大CPU使用率：90%

由于设定了进程自动回收，而当每达到10000次点击，或CPU超过100%,就会强行回收application，导致客户端会出现Sevice Unavailable的错误。(实际上10000次点击，访问量一般的网站，几分钟就够了。) 建议启用计数器日志来监视CPU利用率和asp.net的指标，可以帮助你定位每5~10分钟出现一次是否是上述原因导致。

另外，不要无理由地打开回收工作进程和使用工作进程池。一般理由通常是有不明原因的内存泄露、线程挂起等.

解决办法2：

　　相信这是由于不正确地设置了回收进程导致,建议关闭下列进程回收设置：
　　回收工作进程(分钟)：1440 【24小时回收一次】
　　回收工作进程(请求数目)：50000【默认35000,改动更大点】
　　启用CPU监视,最大CPU使用率：60%【默认不启用,如是虚拟主机最好启用】
　　由于设定了进程自动回收,而当每达到50000次点击,或CPU超过60%,就会强行回收应用程序池,导致客户端会出现Sevice Unavailable[短暂大概60-90秒]的错误。

注意：除非是服务器上虚拟站点过多,应用程序池默认配置即可。

采用定时回收的方法，在0:00、12:00、19:00三个时间进行回收

1、以上设定有弊端：仅仅这样设定是不够的，因为当该应用程序池下的站点越来越多时，以上设定可能将会出现问题。
2、对于访问量过大的站点应单独开设应用程序池。
3、每个应用程序池下设定的站点不要过多。

 

经调试发现,以上方式根本没用,最后终于找到了原因及解决方法：
重置C:\Windows\Temp 文件夹权限即可,加上everyone 读与写入的权限,此问题即可解决,一般人都想看到立竿见影的效果，所以改了后直接观察，还是发现总有相关记录，您可以重启下服务器或不是上网高峰时重启下，再观察会发现没有这些记录了。OK，问题解决。