I’ve just being doing a POC with SharePoint 2013 and I needed to quickly get a ASP.NET app running on IIS on the same machine that hosted SharePoint.
This app had a dependency 32 bit encryption DLL that I could not find a 64bit version of so I needed to run it in 32bit mode and also Classic mode as I didn’t want to mess with web.config changes.
So to get this running quickly I did the following
From a command line
appcmd.exe set apppool "MyAppPool" /enable32BitAppOnWin64:true
appcmd.exe set apppool "MyAppPool" /ManagedPipeLineMode:Classic
appcmd recycle apppool "MyAppPool"
You could easily use the UI to set the two properties Enable 32bit Applications and Managed Pipeline Mode Classic
I’ve done this before so I figured life would be good but no, when browsing the site I got the dreaded 503 Service Unavailable Error.
This generally means the AppPool had a problem starting up and normally its a messed up web.config, section out of place, duplicate handlers, invalid XML, invalid credentials, that kind of thing.
In this case the event logs were clear. IIS was not able to load a 64bit DLL into the 32bit process.
Event Log Error Event ID 2282
The Module DLL 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\isapi\spnativerequestmodule.dll' could not be loaded due to a configuration problem. The current configuration only supports loading images built for a x86 processor architecture. The data field contains the error number. To learn more about this issue, including how to troubleshooting this kind of processor architecture mismatch error, see http://go.microsoft.com/fwlink/?LinkId=29349.
The finger points directly to a new ISAPI module in SharePoint 2013 and its stopping our 32 site from loading. Probably part of the new Request Management piece in SP2013 (http://blogs.technet.com/b/speschka/archive/2012/09/14/working-with-request-manager-in-sharepoint-2013.aspx)
Yeah fine but why the **** is this getting loaded in a non SharePoint site.
In IIS 7.x there are global (i.e. loaded into every AppPool) native ISAPI modules are loaded from the GlobalModules section, however IIS fully supports conditionally loading an ISAPI module depending on if its a 32 or 64 bit, managed or classic pipeline or even specific WebApplication’s
You can check the GlobalModules section in the file ApplicationHost.config in %systemroot%\system32\inetsrv\config
or list them with
appcmd list config /section:globalmodules
<add name="ManagedEngineV4.0_32bit" image="C:\Windows\Microsoft.NET\Framework\v4.0.30319\webengine4.dll" preCondition="integratedMode,runtimeVersionv4.0,bitness32" />
<add name="ManagedEngineV4.0_64bit" image="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\webengine4.dll" preCondition="integratedMode,runtimeVersionv4.0,bitness64" />
If we check the SharePoint module it has no conditions listed, some developer slackness there as the OWSSVR.DLL entry does have some WebApplication preconditions listed.
<add name="SPNativeRequestModule" image="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\isapi\spnativerequestmodule.dll" />
We can apply a quick fix using this command
appcmd.exe set config -section:system.webServer/globalModules /[name='SPNativeRequestModule'].preCondition:integratedMode,bitness64
Or you can manually enter the preCondition entry in the ApplicationHost.config file
<add name="SPNativeRequestModule" image="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\isapi\spnativerequestmodule.dll" preCondition="integratedMode,bitness64" />
With that in place the 32bit Web Application loaded with no other problems.
I’d class this as a bug as it completely breaks 32bit apps for no good reason.