Server.ClearError() 是否会阻止 IIS 快速故障保护

Question

在我们的 ASP.Net 应用程序中，我们通常会尝试通过在相关位置捕获异常来处理我们所有的异常，以便为最终用户提供有用的错误消息，但由于某些异常被抛出的位置，我们无法捕获它们。

这是我们服务器设置的一个问题，因为我们希望保持 IIS 快速故障保护按预期工作，并将所有错误写入我们的自定义错误日志。因此，为了避免服务器意外重置并淹没我们的错误日志，我在 Global.asax.cs 中添加了一些代码来抑制某些类型的错误。目前我们正在研究 IIS 本身抛出的两种 HttpExceptions，以防止 URL 过长（基于 maxUrlLength 设置），以及防止错误的 WebResource 或 ScriptResource 请求。由于某些网络爬虫会生成它们，因此我们无法阻止它们。

我有兴趣知道的，我很难在任何地方找到信息的是：

1. 引用的 HttpExceptions 甚至可能导致 Rapid 无法保护重新启动服务器？有人告诉我，任何未被抓住的 异常可能会导致它，但对我来说这种情况似乎不合逻辑 的异常应该能够导致它。
2. 如果我在 Application_Error() 事件中调用 Server.ClearError()，是否足以抑制可能导致快速故障保护重启的错误？ 还是现在已经太晚了？既然我们已经在 响应未处理异常的过程。

Answer 1

快速失败保护（此处为 RFP）功能旨在保护系统免受无法正常启动或经常失败的应用程序池和工作进程的影响。这些问题可能是由您的应用程序或 IIS 工作进程引起的。可以在here 找到官方（尽管是旧的）原因列表。

1. 不直接。如果尝试处理错误的逻辑失败，则工作进程可能会崩溃。这将触发 RFP。通常，这不会发生，因为 IIS 会尝试处理 Application_Error 中的异常。
2. 如果您的应用程序已经优雅地处理了Application_Error 中的异常，那么它将停在那里。您的异常在应用程序级别“未处理”，但 IIS 能够处理它（通常服务于“黄屏死机”）。因此，工作进程仍然健康，不会触发 RFP。

---

我看到 IIS 工作进程在以下情况下崩溃：

• 递归调用导致无限循环。
• 系统资源不足，无法处理请求（内存不足或达到内存限制）。