上周末，我们运行IIS 6.0的网站停止处理对Web服务的调用。 日志文件被填充以下错误，直到服务器大约8小时后重新启动：
2011-05-08 01：53：12,109错误 – 无法获取执行权限。
在System.Security.SecurityManager.ResolvePolicy（证据证据，PermissionSet reqdPset，PermissionSet optPset，PermissionSet denyPset，PermissionSet＆denied，Boolean checkExecutionPermission）上发生错误。
上述错误在Web日志文件中出现了另外的316,871次。
时间是有趣的，上面的第一个错误发生在29小时的应用池回收计划之后，因为我看到这个条目：
进程ID为“758628”的服务应用程序池“gpsigolf.com”的工作进程已经请求回收，因为工作进程达到了允许的处理时间限制。
在事件日志（使用事件查看器）之前，问题和相关日志文件充满执行权限错误开始。 这个条目也是在事件日志中的前一个这样的条目之后的29个小时。
服务器一直运行，因为没有问题通过几个应用程序池回收，并已经运行五天之前发生这个问题。 这是我们迁移到的一个新的服务器，所以在遇到这个问题之前总共只有五天的时间。
问题是为什么/如何应用程序池回收导致此问题？ 我们应该避免像重叠回收这样的某些设置吗？
我会在29小时后（1740分钟）closures回收站。 这只是默认设置，不能用于生产。 如果您必须自动回收，请在指定时间下class。
重叠的应用程序池非常健康。 在我的Web Pro系列中查看这个最近的video 。
我猜测发生了什么事是你的网站上的一个关键文件的处理和IIS无法获得执行权限。 它可能没有启动，直到IIS在回收过程中发布文件，而其他的东西被接pipe。
当它再次发生（它可能会这样做，因为没有任何改变），我build议使用进程监视器和/或进程资源pipe理器找出哪个文件被locking。 它应该通过在进程监视器捕获中search“拒绝”来启动。 这是另一个关于如何使用Process Monitor的快速video 。