MSMQ worker issue

Hi VGuo**,**

Has your issue been resolved yet? If it has, please consider accepting the answer as it helps others sharing the same problem benefit too. Thank you :)

VPHAN

VGuo

well from the screenshot, I can see yu are querying the Application log, but Windows Process Activation Service events, including Event ID 5002 for application pool rapid-fail protection, are always written to the System log. You need to change the LogName parameter in your script from Application to System to correctly locate these crashes.

You can update your command to Get-WinEvent -LogName System | Where-Object {$_.TimeCreated.ToString('yyyy/MM/dd HH:mm:ss') -like '2026/05/15 10*'} | Where-Object {$_.Id -eq 5002} to pull the relevant records. If querying the System log still yields nothing, it indicates that your worker processes are hanging indefinitely rather than terminating and triggering an application pool shutdown. In that scenario, you should inspect the HTTP request error logs located at C:\Windows\System32\LogFiles\HTTPERR for 503 Service Unavailable queue-full events. You will also need to capture a manual memory dump of the w3wp.exe processes while they are actively hung so we can analyze the internal thread stacks for deadlocks.

Hope this helps :)

VPHAN

Hi VGuo,

The worker exhaustion you are experiencing daily is typically driven by application-level behaviors rather than file system restrictions, and I strongly advise against altering default access control lists on core operating system folders to try and resolve this. Modifying permissions within the System32 directory introduces unnecessary security risks to your infrastructure and should be reverted to baseline. The specific error indicating no workers are available, especially with a defined pool of five processes, heavily points to Windows Process Activation Service handling your MSMQ requests via IIS application pools.

When all five configured worker processes become unavailable, they are likely hanging due to unhandled application exceptions, thread deadlocks in your worker code, or entering a poison message loop where faulty messages are continually read and rejected but never cleared. You should inspect the Windows Event Viewer under the System logs for WAS-related Event ID 5002, which indicates an application pool is being automatically disabled due to rapid failures. To properly diagnose the internal thread state, generate a memory dump of the associated w3wp.exe process when the issue is actively occurring.

While investigating the worker process health, you can also monitor the default MSMQ storage directory located at C:\Windows\System32\msmq\storage to ensure the default one-gigabyte quota limit is not compounding the message processing failures. Utilize Performance Monitor alongside your application event logs to trace exactly where your code is hanging under load. Finally, ensuring your environment is running the latest Cumulative Update for Windows Server 2016 Datacenter build 14393 remains a necessary step to eliminate any patched regressions regarding the Net.Msmq listener adapter.

Hope this answer brought you some useful information. Should you have any questions, feel free to leave a comment.