我对 ASP.Net 工作进程如何处理进程的了解非常不足。我希望那里的一些专家可以填补我的空缺。
如果我使用 System.OutOfMemoryException 使工作进程崩溃，那么由同一进程提供服务的其他用户的用户体验是什么？他们会得到一个空白屏幕吗？503错误？
我将尝试与我们实验室的其他一些人一起测试这个场景，但我想我会把它浮出水面。我将更新我们的结果。
更新：我们的结果各不相同。如果我们人为地引发 OOM 异常（例如通过将越来越大的 PDF 加载到内存中），该工作进程所服务的其他线程将暂时“挂起”然后完成，而其他线程似乎永远不会返回。谢谢你的回复。
IIS 在通用工作进程 - w3wp.exe 中运行所有 Web 应用程序。无论您是用 ASP.NET、ISAPI 还是其他框架编写的，为 Web 请求提供服务的进程都是 w3wp.exe。在 ASP.NET 案例中，w3wp.exe 加载 ASP.NET JIT 编译的 DLL 并通过它们为请求提供服务。在其他情况下，它的工作方式不同。但关键是，w3wp.exe是进程。该模型始于 IIS6.0，并延续到 IIS7.0。
如果 W3WP.exe 出于任何原因意外失败，它正在处理的所有事务都可能会出现 500 错误（服务器错误）。IIS 将在其位置启动一个新的工作进程（MS 称之为“健康监控”），这意味着 Web 应用程序将继续运行。在失败时没有请求由失败的进程提供服务的用户将不会意识到这一点。
在这种情况下，客户端收到的 HTTP 500 错误将与客户端在应用程序错误的情况下收到的 500 错误无法区分，假设您的 ASPNET 应用程序代码中存在未捕获的异常。
对于那些在失败过程中的请求，没有办法恢复它们。它们将导致浏览器出现 500 错误。由于连接数的阈值，IIS 主动拒绝连接导致 503 服务器忙。503 不是由应用程序故障导致的，因此您不应期望在内存不足和崩溃的情况下看到 503 进行中的事务。在负载较重的系统上，您可能会在进程崩溃和重新启动发生时看到 503，这是次要影响。如果这确实是您所看到的，那么您需要更大的安全余量来处理单错误条件下的负载。
IIS 对请求有一种切换方法。当它们到达网络层（Http.sys）时，它们被放置在一个队列中，由工作进程提取。任何在 IIS 队列中等待由 WP 处理的请求将继续不受影响，尽管由于资源争用，它们可能会看到延迟（服务时间）略有临时增加，因为服务器上运行的进程减少了。在正确配置的系统上，此队列中的等待时间通常非常短。
当此队列已满时，您将看到 503 错误。
IIS 有一个自动重新启动（或“nanny”）设施，通过它在工作进程超过配置的阈值（例如内存大小、请求数或运行时间）后重新启动它们。在所有这些情况下，当达到配置的阈值时，IIS 将停止并重新启动工作进程。这些主动重启通常不会导致任何请求中断。当 IIS 决定需要重新启动工作进程时，它会阻止任何新请求到达该要静默的 WP。现有请求已耗尽：允许该 WP 中的任何进行中的事务正常完成。当 WP 中的所有请求都完成时，WP 就会死掉，而 IIS 会在它的位置启动一个新请求。然后，这个新进程立即开始从调度队列中获取新请求。这对用户或浏览器都是透明的。
我说正常是因为工作进程可能在达到阈值的同时真正生病了。在这种情况下，w3wp.exe 可能不会在配置的“静默”超时内响应 IIS ，因此 IIS 最终必须终止该进程，即使它没有报告其所有正在进行的请求都已完成。这应该是非常罕见的，因为这是两种截然不同的异常情况，但它确实发生了。在这种情况下，进行中的请求将再次出现 500 错误。
此外 - IIS 允许在单个服务器上使用多个工作进程。 MS 将其称为“网络花园”，即“网络农场”中的文字游戏。如果您设置了一个网络花园，则由 w3wp.exe 实例提供的事务（而不是失败的实例）将继续不受影响。但是，“未受影响”假定内存不足错误是本地化的，而不是系统范围的问题。
最重要的是，您自己的测试无可替代。配置选项非常广泛——从重启阈值到网络花园等等。此外，故障模式往往非常复杂和多样，无论是内存、超时、太忙等等。你会想了解会发生什么。
ps：这个问答真的属于serverfault.com！
参考资料：http:
//blogs.iis.net/thomad/archive/2008/05/07/the-iis-process-model-features.aspx
将启动一个新的工作线程，用户不会知道发生了什么。除非它通过快速失败完全关闭（http://technet.microsoft.com/en-us/library/cc779127(WS.10).aspx）
如果是内存不足的情况，iis 通常只是回收应用程序池。
正如其他答案所说，在大多数情况下，一切都会重新启动，而大多数当时没有待处理请求的用户只会注意到延迟。
但是，如果您的应用程序使用具有 In-Proc 会话状态的会话变量，则当应用程序池重新启动时，所有用户的所有会话变量都将丢失。这可能会对用户产生负面影响，也可能不会产生负面影响，具体取决于您对会话变量所做的事情。您可以通过切换到 StateServer 或 SQL Server 会话存储来避免这种情况。