The fix for us was to manually edit the system.webServer/handlers
in the IIS configuration editor and replace .NET 2 ISAPI module with .NET 4 ISAPI module.
applicationHost.config Before (system.webServer/handlers
)
<add name="AboMapperCustom-396397" path="*" verb="*" modules="IsapiModule" scriptProcessor="C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" requireAccess="None" preCondition="classicMode,runtimeVersionv2.0,bitness64" responseBufferLimit="0" />
applicationHost.config After (system.webServer/handlers
)
<add name="AboMapperCustom-356384" path="*" verb="*" modules="IsapiModule" scriptProcessor="c:\windows\microsoft.net\framework64\v4.0.30319\aspnet_isapi.dll" requireAccess="None" responseBufferLimit="0" />
Essentially it was running the application through the wrong ISAPI module - even though we specified it properly in the App Pool.
We also had to enable the .NET 4 ISAPI module - it had been turned off by a previous admin.
Alternate Solution - Application Pool Misconfigured
We also see this same error when a .NET 2.0 Application (Classic mode) is serving up .NET 4 (Integrated mode) content. Switching the Application Pool from v2.0 to v4.0 fixed the issue. This same issue could also be from Application Pools v1.1 misclassified as v2.0.