We have an Exchange 2013 organization with two Mailbox servers running on Windows Server 2012 Datacenter in Hyper-V virtual machines. Every so often the following error appears in the Application log on those servers (not simultaneously):

Source: Application error

Event ID: 1000

Message:

 

Faulting application name: w3wp.exe, version: 8.0.9200.16384, time stamp: 0x50108835

Faulting module name: wsmsvc.dll, version: 6.2.9200.16384, time stamp: 0x50108617

Exception code: 0xc0000005

Fault offset: 0x000000000009859a

Faulting process id: 0x4818

Faulting application start time: 0x01cf499932647338

Faulting application path: c:\windows\system32\inetsrv\w3wp.exe

Faulting module path: C:\Windows\system32\wsmsvc.dll

Report Id: 4bbb281d-b8c2-11e3-9425-00155d854004

Faulting package full name:

Faulting package-relative application ID:

In turn, it triggers an alert in the Operation Manager console similar to the following one:

A process serving application pool 'MSExchangePowerShellAppPool' suffered a
fatal communication error with the Windows Process Activation Service. The
process id was '18456'. The data field contains the error number.

The pool mentioned in the message can be any backend Exchange pool.

In fact, we have these errors since the servers were first deployed about an year ago. They appeared on, consequently, Exchange 2013 RTM, CU1, CU2, SP1. They temporarely disappeared after installing CU2, however, they appeared again in a couple of months.

It seems that these IIS aplication pool faults don't affect anything. At least, I can't see that something goes wrong due to them. Therefore, these error messages are just annoying.

Is it possible to prevent the IIS pools from crashing? Or should I just disable the SCOM monitor and forget about it?

• Edited by Evgeniy Lotosh Tuesday, April 01, 2014 11:05 AM

Hi,

I recommend you use the Debug Diagnostics tool to troubleshoot the issue:

How to use the Debug Diagnostics tool

When an IIS process that hosts a Web application stops unexpectedly, the system unloads the process, and all running requests are lost.  To troubleshoot this scenario, you can use the Debug Diagnostic tool.

Disable Health Monitoring for IIS 6.0 and above. To do this, follow these steps: 

1. Open the IIS MMC snap-in.
2. Expand Application Pools.
3. Right-click Application Pools, and then click Properties.
4. Click the Recycling tab, and then click to clear all the Recycle worker process check boxes.
5. Click the Performance tab, and then click to clear the Shutdown worker processes after being idle for (time in minutes) check box.
6. Click the Health tab, click to clear the Enable rapid-fail protection and Enable pinging check boxes, and then click OK.
7. Restart IIS 

Hope this helps!

Thanks.

Nico,

Thank you for the answer, but it seems this instruction has been written for an older version of Windows Server / IIS. In IIS 7 running on Windows Server 2012 everything is quite different. Application pools have no Properties item in their context menu, and the settings I can find are arranged in a different way and have different names and values.

Anyways, the question is not about disabling the monitoring. I can do it in the SCOM console, and it'd be much easier and safer than tinkering with the Exchange-made settings. The question is, what's the cause of the issue and whether it can be safely ingnored.

The Debug Diagnostic tool is of no use to to me. I'm not a web programmer and can't interpret the results pro

I am receiving the same error. It does not seem to effect performance, but I am too curious what the cause is.

• Edited by Dantronik Friday, April 04, 2014 3:22 PM

+ 1 - Seeing this on Hyper-V VM running 2012R2, Exchange 2013, CU8. Semi regular (once every day).

Mailbox server role is doing this, CAS is not. I have 1 DAG.

At this stage I see no real world impact on our environment.