Troubleshooting IIS Event ID 5139

I was recently working on an upgrade to a website that involved changing the Application Pools from 32-bit to 64-bit. The servers hosted several websites and they all ran in 32-bit mode. Several days later I noticed the System log was full of the following errors for one of the websites that I didn’t update.

Troubleshooting IIS Event ID 5139

Log Name: System
Source: Microsoft-Windows-WAS
Date: 5/9/2014 8:11:57 AM
Event ID: 5139
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: 
Description:
A listener channel for protocol 'http' in worker process '%' serving application pool '%' reported a listener channel failure. The data field contains the error number.

I did some searching on the error and did not find much help. TechNet contains the following article for troubleshooting IIS Event ID 5139. But the solution proposed (restarting IIS and WAS) is not very helpful.

My Application log showed the following errors that seem to coincide with the WAS errors in the System log. CompDyn.dll is the Dynamic Compression Native Module

Log Name: Application
 Source: Microsoft-Windows-IIS-W3SVC-WP
 Date: 5/9/2014 8:12:08 AM
 Event ID: 2280
 Task Category: None
 Level: Error
 Keywords: Classic
 User: N/A
 Computer:
 Description:
 The Module DLL C:\Windows\System32\inetsrv\compdyn.dll failed to load. The data is the error.

Root Cause

The error seems to be caused by the Dynamic Compression module, but why? The primary change I had made, was changing the other website’s application pool to 64-bit. When I stopped the 64-bit application pool, the other application pool was able to load compdyn.dll. As soon as I started the 64-bit application pool, the 32-bit pool started failing. Alternatively, when I set the 64-bit application pool back to 32-bit, there error’s cleared.

What I’m suspecting is happening is that when the Dynamic Compression module gets loaded into a 64-bit application pool it’s unable to load in a 32-bit application pool. Process Explorer shows that the DLL is loaded by each w3wp.exe process, which should mean that there’s isolation between them. But there’s obviously some kind of impact between the two worker processes.

One aspect that may be relevant is that this server had used Web Deploy to migration configuration changes to it in the past.

How to Resolve

I’ve never found Dynamic Compression to offer that much value, so I chose to just remove the Module. I first tried to remove it using the UI, but it did not actually get removed from the <globalModules> section. These are the steps I followed to resolve.

1. Open applicationhost.config
2. Find the <globalModules> section
3. Remove <add name=”DynamicCompressionModule” image=”%windir%\System32\inetsrv\compdyn.dll” />
4. Save applicationhost.config
5. The change should take affect right away, IIS Reset is not needed.

Alternative Solutions

• You could also resolve this problem by running all of your application pools in either all 32-bit or all 64-bit mode.
• I think you may be able to also resolve this by uninstalling the Dynamic Compression module and then reinstalling. I haven’t tested this but it my be an option.