Server.ClearError()是否阻止IIS快速失败保护

时间:2015-07-13 13:41:04

标签: c# asp.net iis error-handling

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

这是我们服务器设置的一个问题,因为我们希望保持IIS Rapid Fail Protection按预期工作,并将所有错误写入我们的自定义错误日志。因此,为了避免意外重置服务器并充斥我们的​​错误日志,我在Global.asax.cs中添加了一些代码来抑制某些类型的错误。目前我们正在研究IIS本身抛出的两种HttpExceptions,以防止过长的URL(基于maxUrlLength设置),并防止出现错误的WebResource或ScriptResource请求。由于一些webcrawler生成它们,我们无法阻止它们。

我有兴趣知道,我很难在任何地方找到信息:

  1. 引用的HttpExceptions是否可能导致Rapid 失败保护重启服务器?我被告知任何未被捕获的 例外可能会导致它,但这对我来说似乎不合逻辑 异常应该能够导致它。
  2. 如果我在Application_Error()事件中调用Server.ClearError(),是否足以抑制可能导致快速失败保护重启的错误? 或者现在已经太晚了?因为我们已经在 响应未处理的异常的过程。

1 个答案:

答案 0 :(得分:0)

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

  1. 不直接。如果尝试处理错误的逻辑失败,则工作进程可能会崩溃。这将触发RFP。通常,这不会发生,因为IIS将尝试处理Application_Error中的异常。
  2. 如果您的应用程序在Application_Error中正常处理了异常,那么它就会停在那里。你的例外是"未处理"在应用程序级别,但IIS能够处理它(通常服务于"死亡的黄色屏幕")。因此,工作进程仍然健康,不会触发RFP。
  3. 我在以下情况下看到IIS工作进程崩溃:

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