IIS7: A process serving application pool 'YYYYY' suffered a fatal communication error with the Windows Process Activation Service

Question

We're running a 32-bit Windows server 2008 with an IIS version of 7.
We're attempting to publish an asp.net 4.0 webapp and so far our attempts have only yielded a few warnings in the serverlog without even stopping the 4.0 application pool

A process serving application pool 'ASP.NET v4.0' suffered a fatal communication error with the Windows Process Activation Service. The process id was '1904'. The data field contains the error number.

The application is running under a 4.0 app-pool and under the default website.
We've also got some older .asp's running flawlessly.
Even when attempting to publish a barren (read. only 1 line of text) .aspx-file it failed miserably... We've since long run out of ideas on what to do so any form of input would be appreciated...

Updated link: http://mvolo.com/troubleshooting-iis7-503-quotservice-unavailablequot-errors-with-startup-debugging/ — William Gross, Jan 28 '16 at 19:58
In my case, problem was an unlimited recursive loop in my application code. — Mohsen Tavoosi محسن طاوسی, May 19 '16 at 13:46
I know the post is old, but I've got to say that when I was searching for a solution to my problem, it didn't help. I must say that my problem was related to database users. They didn't have EXECUTION permissions. C-ya. — MaGnumX, Feb 25 '21 at 13:33

score 17 · Answer 1 · edited Feb 08 '18 at 16:19

17

Make sure that each Application Pool in IIS, under Advanced Settings has Enable 32 bit Applications set to True

edited Feb 08 '18 at 16:19

Steve

25,163
2
32
42

answered Aug 26 '11 at 12:57

Peter Bromberg

1,506
8
11

15

Could you please explain why this would solve the OP's issue? I am asking because I and encountered the same issue on 64-bit Windows Server 2008 R2 and would like to know if this solution can be generalized to my case. Thank you! – sfarbota Oct 03 '13 at 17:31
Same answer given here http://stackoverflow.com/a/7920145/28411, so seems to be something to it. Didn't work for me unfortunately. – RJFalconer Nov 11 '13 at 14:21
I recently ran into this issue with an ODBC connected product moved to a new server. Flipping the Enable 32-Bit Application to true solved the issue. – Josh Apr 14 '14 at 22:01
1

what if i do not want 32-bit apps on the AppPool, and really need 64-Bit? what is the solution for "Run only 64-Bit" scenarios? – Zafar Apr 28 '14 at 19:41
1

Had the same issue. But this is weird. I switch that setting to true, apply the change, and then, go back and put it to false again and guess what, it is still working... I'm mystify by this... – Marc-Andre R. Aug 13 '15 at 17:21
19

This is a red herring, not a solution to the problem. The problem is whatever is causing the application to fail. – Stan Mar 29 '17 at 22:54
4

For me the windows logs showed a problem with virtual memory of the process which could not be increased. I think that setting "Enable 32Bits Application" limits the size of the process at 2GB and simply forces a pool recycle when the limit is reached. You can also set the a virtual memory limit in the advanced parameters of the application pool. – Pak Jun 08 '17 at 09:00
Downvoting. Stan is right: "The problem is whatever is causing the application to fail." This workaround will cause you some serious headaches if you require the app pool to run 64 bit. – Morten Gorm Madsen Mar 15 '18 at 07:29

score 15 · Answer 2 · edited Aug 03 '18 at 16:18

15

I was debugging the problem for the better part of the day and when I was close to burning the building I discovered the Process Monitor tool from Sysinternals.

Set it to monitor w3wp.exe and check last events before it exits after you fire a request in the browser. Hope that helps further readers.

edited Aug 03 '18 at 16:18

James Skemp

7,696
9
60
101

answered May 25 '13 at 00:09

Grozz

8,054
4
37
53

3

Mine was missing nuget packages (System.Net.Primitives in my case) – Dany Gauthier Apr 29 '15 at 15:02
3

In my case, problem was an unlimited recursive loop in my application code. – Mohsen Tavoosi محسن طاوسی May 19 '16 at 13:46
I had numerous missing files and a wrong build of some type. Something wrong with my deploy setup. – Jason Cheng Feb 26 '19 at 17:43
In my case, problem was 'ApplicationPoolIdentity' that did not have read permissions. see: https://stackoverflow.com/questions/7334216/iis7-permissions-overview-applicationpoolidentity – mathijsuitmegen Oct 23 '19 at 09:11
For me it was URL Rewrites and Application Request Routing not recognized by IIS. – jrap May 12 '21 at 16:09
It worked, it didn't show an explicit error but the last working operation was an access to %systemroot% that failed – Francesco B. Nov 19 '21 at 10:43

score 12 · Answer 3 · answered Nov 06 '16 at 15:16

12

Debug Diagnostics Tool (DebugDiag) can be a lifesaver. It creates and analyze IIS crash dumps. I figured out my crash in minutes once I saw the call stack. https://support.microsoft.com/en-us/kb/919789

answered Nov 06 '16 at 15:16

mhenry1384

7,332
5
52
73

1

For further information, here's a TechNet blog article showing how to configure the DebugDiag tool to catch a crash dump: https://blogs.msdn.microsoft.com/parvez/2016/08/06/iis-application-pool-crash-and-debug-diag/ – Jeff Miles Sep 08 '17 at 13:44

score 1 · Answer 4 · answered Feb 23 '17 at 14:29

When I had this problem, I installed 'Remote Tools for Visual Studio 2015' from MSDN. I attached my local VS to the server to debug.

I appreciate that some folks may not have the ability to either install on or access other servers, but I thought I'd throw it out there as an option.

score 1 · Answer 5 · answered Aug 01 '17 at 20:52

I ran into this recently. Our organization restricts the accounts that run application pools to a select list of servers in Active Directory. I found that I had not added one of the machines hosting the application to the "Log On To" list for the account in AD.

score 0 · Answer 6 · answered Oct 06 '20 at 13:47

0

For me the problem was a configuration file that was missing an Element.

answered Oct 06 '20 at 13:47

Jon

881
7
14

IIS7: A process serving application pool 'YYYYY' suffered a fatal communication error with the Windows Process Activation Service

6 Answers6

Linked