I installed .Net 1.1 recently(I have .net 2,3.5 and 4 on my system previously) on my machine.
All of a sudden I am unable to access my applications from IIS. VS build in webservier is working fine. But IIS its giving the following error.
Calling LoadLibraryEx on ISAPI filter "C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_filter.dll" failed
In searching about this problem a lot of solutions pointed at using aspnet_regiis –r from the Framework64 directory, but that did not fix my problem.
Then I found this article which fixed my problem.
Even changing app pool to use 32 bit is not worked for me.
2nd option which requires changing isapi settings worked.
Enabling 32 bit code is a quick fix solution to this problem, but not an ideal one.
In this IIS trying to load a 32 bit DLL in a 64 bit install, especially even if the application pool is configured to not allow 32 bit code at all.
Go to Default Web Site (or any other root Web Site) and go to the ISAPI filter list:
Here is the list
Notice that there are 3 entries for ASP.NET 4.0 in this list. Only two of them however are specifically scoped to the specifically to 32 bit or 64 bit. As you can see the 64 bit filter correctly points at the Framework64 folder to load the dll, while both the 32 bit and the ‘generic’ entry point at the plain Framework 32 bit folder.
Go the Web Site root and use the Configuration Editor option in the Management Group.
Drill into System.webServer/isapiFilters
and then click on the Collection’s … button on the right. You should now see a display like this:
These entries correspond to these raw ApplicationHost.config entries(above diusplayed entries):
<filter name="ASP.Net_4.0" path="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_filter.dll" enableCache="true" preCondition="runtimeVersionv4.0" />
<filter name="ASP.Net_4.0_64bit" path="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_filter.dll" enableCache="true" preCondition="runtimeVersionv4.0,bitness64" />
<filter name="ASP.Net_4.0_32bit" path="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_filter.dll" enableCache="true" preCondition="runtimeVersionv4.0,bitness32" />
The key attribute we’re concerned with here is the preCondition and the bitness subvalue. Notice that the ‘generic’ version – which comes first in the filter list – has no bitness assigned to it, so it defaults to 32 bit and the 32 bit dll path. And this is where our problem comes from.
The simple solution to fix the startup problem is to remove the generic entry from this list here or in the filters list shown earlier and leave only the bitness specific versions active.
The preCondition attribute acts as a filter and as you can see here it filters the list by runtime version and bitness value. This is something to keep an eye out in general – if a bitness values are missing it’s easy to run into conflicts like this with any settings that are global and especially those that load modules and handlers and other executable code. On 64 bit systems it’s a good idea to explicitly set the bitness of all entries or remove the non-specific versions and add bit specific entries.
I just made enabled to false for the erred configuration.
This solves the problem.
aspnet_regiis –r from the Framework64 directory, did not fix this extra entry in the filters list – it adds the required 32 bit and 64 bit entries, but it doesn’t remove the errand un-bitness set entry.
