我有一个托管在 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/