This article explains how to run 32-bit IIS 6.0 on 64-bit Server 2003: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/iis/13f991a5-45eb-496c-8618-2179c3753bb0.mspx.

How can the same be accomplished with IIS 7.0 on 64-bit Server 2008?


Given the brief question, I don't know if this is exactly what you want to do, but you can run 32-bit ISAPI extensions (such as PHP, Rewrite, custom extensions, etc) in an AppPool in IIS 7 and 7.5.

For the full rundown, see this article here, the important part being:

...go into your IIS 7 manager console, find the application pool your app is running in, right-click on it, go to Advanced Settings, and change the Enable 32-bit Applications setting to true... Now restart IIS (either via the snap-in or the command line w/net stop w3svc & net start w3svc) and you’re good to go


Or see this. There's no need to run aspnet_regiis anymore, and you can switch between 32-bit and 64-bit per application pool instead of globally. It's a big improvement.


For those of you who still cannot find a proper way to use a 32-bit DLL under a native 64-bit IIS Application Pool, either by tweaking the registry, or by trying how to deal with the "COM+ Components Services", and if you absolutely need to run the IIS Application Pool in 64-bit" (so turning "Enable 32-bit Applications OFF") : I have found a perfectly working solution : "Encapsulating" the 32-bit component into a new COM object as described on this page did the job perfectly, and I think that a lot of you will be interested to solve the problem this way ;) http://www.chestysoft.com/component-services.asp

In my case, that allowed me to use the "XStandard.Zip" free Component from XStandard, which is sadly only available as a 32-bit ASP component, and that have an "InProcServer32" Key in the registry apparently preventing it to work by tweaking the registry, as described here : https://techtalk.gfi.com/32bit-object-64bit-environment/

In this post, a lot of comments reported that "InProcServer32-IDs are not reflected because Microsoft assumes that these are only InProc-Calls and not Out-Of-Proc-Calls". And that was my case too, leading me to the situation where the registry tweaking solution described in the previous post was not working in my case, as other users.

Hoping having saved some days... or nights !

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.