我有一个托管在 IIS 7.5 (Windows Server 2008 R2) 中的 CLR 4 WCF 服务，使用 WebHttp 绑定(bind)(使用 [WebGet])。该服务调用用 C++ (Visual Studio 2010) 实现的非托管组件。
我故意在非托管组件中添加了访问冲突(通过在指针上重复调用delete、通过删除的指针调用方法等)来测试转储文件生成设置。访问冲突导致 w3wp.exe 进程崩溃，考虑到 CLR 4 中的“损坏状态异常”，这并不奇怪。但是，当进程重新启动时(由于 IIS 中的预热和始终开启设置)，相同的请求似乎会重播到服务，从而再次导致 w3wp.exe 进程崩溃。几次后(由“最大失败”应用程序池设置控制)，应用程序池将停止。
我使用浏览器作为测试客户端，在重新启动序列正在进行时，请求仍在进行中。当应用程序池停止时，请求将返回 503 Service Unavailable。
我可以通过在代码周围放置 try...catch block 并使用 [HandleProcessCorruptedStateExceptions] 属性来解决该问题。当我这样做时，w3wp.exe 进程不会崩溃。然而，这不是期望的行为——我希望进程崩溃(访问冲突或内存损坏已经足够糟糕了)，但我希望它重新启动到干净状态并且不重播请求。
我无法使用 BasicHttp 绑定(bind)重现该问题。
最佳答案
这就是 HTTP.sys 的工作原理(在较低级别处理 http 请求的内核驱动程序)。它将请求排队并在池/服务器备份后将它们发送到 IIS。
关于asp.net - 遇到访问冲突时，w3wp.exe 崩溃并反复重新启动，直到应用程序池停止，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4934287/