So i took a support call from a customer of mine today who ran into problems installing West Wind Web Connection on a 64 bit machine. West Wind Web Connection works through a 32 bit ISAPI extension and sure enough a standard configuration will not allow this ISAPI extension to run. Any attempt to access a 32 bit extension in a 64 bit environment results in a 500 server error and this message

%1 is not a valid Win32 application

Conveniently IE6 (on the server) will hide this message (anything shorter than 512 bytes get overridden by IE's default error message) so you may not actually see the *actual* error message.

You can get around this limitation by forcing IIS to create Application Pools in 32 bit mode by using a Metabase key available on 64 bit machines. You can run the following from a Command Prompt:

cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 true

Note that this will affect EVERY IIS application on the Web Server so this is unfortunately an all or nothing option only. This option is widely known and published in Microsoft KB articles and what not.

However, even with that switch set my customer still was unable to run his application. Instead we got:

Service Unavailable

on any page - even static pages in the site.

Service unavailable is familiar - it occurs when IIS itself is running but when an Application Pool is not starting up properly. After getting on the machine and digging through the IIS configuration settings indeed I found that immediately after hitting a page that the Application Pool was being shut down and showing an Unidentified Error.

So my next thought was that it might be an ISAPI Filter causing this issue and a quick look at the ISAPI Filter page indeed showed the ASP.NET 2.0 filter as enabled and 'stopped'. No doubt this is what was causing the problem. The issue is that the ASP.NET filter is now 64 bit in a 32 bit app which causes the failure.

To fix this you can either remove the filter altogether or - probably safer if you use ASP.NET - to re-register ASP.NET for the appropriate framework version (32 bit or 64 bit).

To set up ASP.NET for 32 bit:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>aspnet_iisreg -i

To set up ASP.NET for 64 bit:

C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727>aspnet_iisreg -i

So in our case I reregistered the app with the 32 bit version and the customer was on his way.

Long Term Solution - .NET Module

A few months ago I wrote a bit about the process of creating a managed module to replace the ISAPI extension for West Wind Web Connection and although it's been on my radar to check out this managed module under 64 bit I hadn't had a chance to try it under 64 bit. So today I finally got the chance to give it a shot. Basically this HttpHandler implementation duplicates the ISAPI functionality and adds a number of cool features that would have been painful to do in C++ code.

I wasn't sure what to expect but I was totally stoked to see that the HttpHandler worked out of the box first try in 64 bit mode! No changes, no failures - and running through a whole suite of request scenarios without any issues. That's pretty impressive given that I didn't spend any time specifically checking for 64 bit issues.

The handler works both with file based messaging mode, WCF and even with COM calling a 32 bit COM server (out of process).

Now I don't think it'd be quite so straight forward with more complex types of applications (that actually deal with a variety of type information) but still I think that this is really quite impressive to be able to have the same code without recompilation run both 64 bit and 32 bit. Of course that's always been one of the promises of .NET but seeing it in action like this really pushes that point home.