0

假设我有一个未处理的异常（或已知的严重、不可恢复的错误）。最可怕的情况是安全漏洞，但它可能适用于任何意味着我的状态如此严重以至于无法安全继续下去的事情。

我该怎么办？

在传统应用程序中，通常的技术是快速结束我的进程。尽早。我正在调用 Process.Exit、TerminateProcess、die 或环境具有的任何其他意味着“END. NOW”的工具。Eric Lippert 的帖子很好地表达了这种态度的原因。

在 IIS 上运行的生产 ASP.NET 应用程序中，情况并非如此简单。我当然可以结束当前进程并将错误记录到事件日志或任何地方。这基本上就是任何未处理的异常都会发生的情况。但是下一次请求进来时，IIS 将启动一个新的工作进程。如果我的致命错误是一个短暂的问题，那就太好了。

但是，如果我的问题在我的流程生命周期之后仍然存在，那么新的问题也不会好转。它甚至可能因初始化代码或重新尝试而复杂化。另外，如果 IIS 在同一个应用程序池中运行多个工作进程，即使终止我的进程也不会终止应用程序。从逻辑上讲，所有其他工人可能也被灌输了，只是还不知道。

到目前为止，我只提出了两个选择。

  • 结束这个过程并希望最好。知道应用程序将重新启动，这与“catch(Exception) {}”几乎相同。很难令人满意。
  • “伸出手”告诉 IIS 禁用应用程序、停止 IIS、机器等。这似乎是一个残酷的 hack。此外，我猜它可能需要提升安全凭证。在终止可能受损的进程期间，似乎是一个糟糕的时间来拥有这些。
4

1 回答 1

1

我能想到的有以下几点：

  1. 您可以继续使用IIS中名为“Rapid-Fail protection”的应用程序池的高级设置，将Failure Interval设置为足够长，并将Maximum Failures设置为1，然后继续抛出异常并使IIS认为此应用程序池无法正常工作，因此它将服务不可用发送回客户端，甚至重置连接（取决于您的设置）。有关更多详细信息，请在此处查看：应用程序池的故障设置. 但是您需要非常小心不要过度杀伤，我的意思是您需要编写一个非常好的应用程序，所有异常都得到正确处理，并且只有您想要终止应用程序的应用程序才能被 IIS 真正检测到，否则可能只是单个用户单击关闭了您的网站。

  2. 另一种解决方案是继续编写自己的代码，我的意思是你可以以某种方式记录这样的错误，比如创建一个名为SystemCrashed的文件，然后终止应用程序，然后检查文件是否存在于Application_Startup上，除了终止之外什么都不做找到文件后申请。像锁一样的东西。这需要更多的代码，但可能比 IIS 设置更安全，我的意思是只要你能正确地移除锁，就不会有太多的矫枉过正。

于 2013-01-25T09:02:45.783 回答