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.
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.