IIS Worker Process crashing our PBX

[TCF]

Today all of our phones slowly crashed, I noticed every extension dialing a *30 as it went down. Some people got disconnected from their active calls while some didn't.

Looking on the PBX I saw that there was 98% CPU Utilization from IIS Worker Process and after killing the process everything immediately started working again.

I reviewed the event log saw the 2 following entries with a Warning that seems to have appeared every day.

1. A worker process '####' serving application pool '3CXApplicationPool01' failed to stop a listener channel for protocol 'http' in the allotted time. The data field contains the error number.
2. A process serving application pool '3CXApplicationPool01' exceeded time limits during shut down. (Source WAS)

Any idea of what would cause this / a fix, or where to begin?

 

[NickD_3CX]

Do you have any Bridge connections on this installation?
Also what phones do you have, what firmware are they on and are you using custom templates?

What about the server specs?

 

[TCF]

I do not have any bridge connections. I only run 2 models of phones, Yealink T42G and Yealink T19P. We also have some cisco SPA-112 Sip Adapters. I am using custom templates with minimal changes, like 12-hr Time, and web panel password adjusted so all the phones have the same webpage login.

We are running the following FW. (I'm upgrading all of our phones to the newest FW right now.)

T19P - 53.80.0.60 , 53.80.0.70
T42G - 29.73.0.50 , 29.73.0.55 , 29.73.0.70

The server is a Dell PowerEdge R320 running Windows Server 2012 r2
Intel Xeon E5-2403 v2 1.8Ghz
16GB Memory

The Server is dedicated to 3CX and is not running anything else besides being a DNS Server for our Phones. The phones are all on their own isolated network with the PBX.

 

[NickD_3CX]

I would check the IIS logs on the 3CX server and see if there are any requests from IPs that are getting 407 in return or 404.

I think the logs usually are located in c:\inetpub\

 

[TCF]

I didn't see anything suspicious in the logs you mentioned, there are no 404 or 407 errors. If it happens again I'll try to get into IIS and see if I can find the culprit. As far as the Event Viewer errors, I'm just stumped.