遇到访问冲突时，w3wp.exe 崩溃并反复重新启动，直到应用程序池停止
我有一个托管在 IIS 7.5 (Windows Server 2008 R2) 中的 CLR 4 WCF 服务，使用 WebHttp 绑定（使用 [WebGet]）。该服务调用用 C++ (Visual Studio 2010) 实现的非托管组件。
我故意在非托管组件中添加了访问冲突（通过在指针上重复调用删除、通过删除的指针调用方法等）来测试转储文件生成设置。访问冲突导致 w3wp.exe 进程崩溃，考虑到 CLR 4 中的“损坏状态异常”，这并不奇怪。但是，当进程重新启动时（由于 IIS 中的预热和始终开启设置），相同的请求似乎会重播到服务，从而再次导致 w3wp.exe 进程崩溃。几次后（由“最大失败”应用程序池设置控制）应用程序池将停止。
我使用浏览器作为测试客户端，当重新启动序列正在进行时，请求仍在进行中。当应用程序池停止时，请求将返回 503 Service Unavailable。
我可以通过在代码周围放置 try...catch 块并使用 [HandleProcessCorruptedStateExceptions] 属性来解决该问题。当我这样做时，w3wp.exe 进程不会崩溃。然而，这不是期望的行为——我希望进程崩溃（访问冲突或内存损坏已经足够糟糕了），但我希望它重新启动到干净状态并且不重播请求。
我无法使用 BasicHttp 绑定重现该问题。
I have a CLR 4 WCF service hosted in IIS 7.5 (Windows Server 2008 R2), using the WebHttp binding (with [WebGet]). The service calls into an unmanaged component implemented in C++ (Visual Studio 2010).
I deliberately added an access violation inside the unmanaged component (by calling delete on a pointer repeatedly, calling methods through a deleted pointer, etc.) to test dump file generation settings. The access violation crashes the w3wp.exe process, which is not surprising considering "Corrupted State Exceptions" in CLR 4. However, when the process restarts (due to warmup and always-on settings in IIS), the same request seems to be replayed to the service so that it crashes the w3wp.exe process again. After a few times (governed by the "max failures" application pool setting) the application pool is stopped.
I'm using the browser as the test client, and while the restart sequence is underway the request is still in flight. When the application pool is stopped, the request returns with 503 Service Unavailable.
I can work around the problem by placing try...catch block around the code and using the [HandleProcessCorruptedStateExceptions] attribute. When I do that, the w3wp.exe process does not crash. However, this is not the desired behavior -- I want the process to crash (an access violation or a memory corruption is bad enough) but I want it to restart into a clean state and not have the request replayed.
I was not able to reproduce the problem using the BasicHttp binding.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这就是 HTTP.sys 的工作原理（在较低级别处理 http 请求的内核驱动程序）。它将请求排队并在池/服务器备份后将它们发送到 IIS。
This is how HTTP.sys works (the kernel driver that handles http-requests on the lower level). It queues requests and sends them to IIS after the pool/server is back up.