A process serving application pool 'Classic .NET AppPool' suffered a fatal communication error with the Windows Process Activation Service

Question

I am running an ASP.NET 3.5 web application on IIS 7 on Windows Server 2008.

I received the following error earlier this afternoon:

HTTP Error 503. The

Answer 1

I just tracked down and fixed the same nasty problem. A couple things that could cause the problem:

• A Server.Transfer() loop
• Calling CurrentThread.Abort() in certain scenarios.. (Like after a Server.Transfer()!)

Fixing those things is what fixed it for us.

Answer 2

This one is a pretty nasty one. I recommend getting the IIS Debug Diagnostics tools. You can probably alleviate the symptom by turning off "Rapid Fail Protection" in the properties of your application pool, but that will just mask the problem. What is going on is that your application is experiencing an exception so often/so repeatedly that the service shuts itself off. You'll need to run the diagnostic tool to capture everything going in and out to find the exception that's occuring.

This can be a very laborious task because the tool will gather gigabytes of junk to sift through. If you're lucky, the turning off of the "Rapid Fail Protection" might allow the exception to proceed through to the browser, but my guess is that the server will just end up hanging.

Answer 3

Its most likely caused by an infinite loop.

(I just had the same problem.) So you will just have to look for places in the code that use loops and see if removing one of them stops the error. Once you have found the culprit, then you can try to figure out whats causing it to loop indefinitely.

Answer 4

I had the same problem now on IIS-10 / Windows Server. The app worked well in development environment but produced errors in production server. I assume the problem may be related to some memory/heap/stack management. Publishing release version instead of debug solved the issue. More detailed: "Advanced Build Settings" / "Debug Info" /"full" -> "pdb-only".

Update: The next day, I accidentally released a debug version again. Now the running software produced a bit different behaviour. Now the solution was to disable "Check for arithmetic overflow/underflow" (Build->Advanced) (VS2013)

Answer 5

I had this problem, the event viewer had "The Module DLL C:\Windows\system32\RpcProxy\RpcProxy.dll failed to load. The data is the error." This post had the steps to correct this: http://forums.iis.net/t/1154189.aspx

Answer 6

If you are using NServiceBus make sure whatever account the application pool is running under has permissions to read off of the message queue.

NServiceBus runs a background task on application startup that timesout after 10 seconds, causing the w3wp process to be killed if it can't read from the queue. After n (default of 5) w3wp crashes Rapid-Fail Protection kicks in and stops the application pool.

http://blog.jonathanoliver.com/2010/11/nservicebus-w3wp-exe-processes-crashing/