If you're running on IIS 7 and a 64 bit operating system you might run into the following error using ASP classic or ASP.NET with COM interop. In classic ASP applications the error will show up as:

ActiveX component can't create object   (Error 429)

(actually without error handling the error just shows up as 500 error page)

In my case the code that's been giving me problems has been a FoxPro COM object I'd been using to serve banner ads to some of my pages. The code basically looks up banners from a database table and displays them at random. The ASP classic code that uses it looks like this:

				<%

				Set banner = Server.CreateObject("wwBanner.aspBanner")
banner.BannerFile = "wwsitebanners"
Response.Write(banner.GetBanner(-1))
%>

Originally this code had no specific error checking as above so the ASP pages just failed with 500 error pages from the Web server. To find out what the problem is this code is more useful at least for debugging:

				<%

				ON ERROR RESUME NEXT
Set banner = Server.CreateObject("wwBanner.aspBanner")

Response.Write(err.Number & " - " & err.Description)

banner.BannerFile = "wwsitebanners"
Response.Write(banner.GetBanner(-1))
%>

which results in:

429 - ActiveX component can't create object

which at least gives you a slight clue.

In ASP.NET invoking the same COM object with code like this:

				<%

				dynamic banner = wwUtils.CreateComInstance("wwBanner.aspBanner") as dynamic;
banner.cBANNERFILE = "wwsitebanners";
Response.Write(banner.getBanner(-1));
 %>

results in:

Retrieving the COM class factory for component with CLSID {B5DCBB81-D5F5-11D2-B85E-00600889F23B} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).

The class is in fact registered though and the COM server loads fine from a command prompt or other COM client.

This error can be caused by a COM server that doesn't load. It looks like a COM registration error. There are a number of traditional reasons why this error can crop up of course.

• The server isn't registered (run regserver32 to register a DLL server or /regserver on an EXE server)
• Access permissions aren't set on the COM server (Web account has to be able to read the DLL ie. Network service)
• The COM server fails to load during initialization ie. failing during startup

One thing I always do to check for COM errors fire up the server in a COM client outside of IIS and ensure that it works there first - it's almost always easier to debug a server outside of the Web environment. In my case I tried the server in Visual FoxPro on the server with:

loBanners = CREATEOBJECT("wwBanner.aspBanner")
loBanners.cBannerFile = "wwsitebanners"
? loBanners.GetBanner(-1)

and it worked just fine. If you don't have a full dev environment on the server you can also use VBScript do the same thing and run the .vbs file from the command prompt:

				Set banner = Server.CreateObject("wwBanner.aspBanner")
banner.BannerFile = "wwsitebanners"
MsgBox(banner.getBanner(-1))

Since this both works it tells me the server is registered and working properly. This leaves startup failures or permissions as the problem. I double checked permissions for the Application Pool and the permissions of the folder where the DLL lives and both are properly set to allow access by the Application Pool impersonated user. Just to be sure I assigned an Admin user to the Application Pool but still no go.

So now what?

64 bit Servers Ahoy

A couple of weeks back I had set up a few of my Application pools to 64 bit mode. My server is Server 2008 64 bit and by default Application Pools run 64 bit. Originally when I installed the server I set up most of my Application Pools to 32 bit mainly for backwards compatibility. But as more of my code migrates to 64 bit OS's I figured it'd be a good idea to see how well code runs under 64 bit code. The transition has been mostly painless.

Until today when I noticed the problem with the code above when scrolling to my IIS logs and noticing a lot of 500 errors on many of my ASP classic pages. The code in question in most of these pages deals with this single simple COM object.

It took a while to figure out that the problem is caused by the Application Pool running in 64 bit mode. The issue is that 32 bit COM objects (ie. my old Visual FoxPro COM component) cannot be loaded in a 64 bit Application Pool. The ASP pages using this COM component broke on the day I switched my main Application Pool into 64 bit mode but I didn't find the problem until I searched my logs for errors by pure chance.

To fix this is easy enough once you know what the problem is by switching the Application Pool to Enable 32-bit Applications:

Once this is done the COM objects started working correctly again.

64 bit ASP and ASP.NET with DCOM Servers

This is kind of off topic, but incidentally it's possible to load 32 bit DCOM (out of process) servers from ASP.NET and ASP classic even if those applications run in 64 bit application pools. In fact, in West Wind Web Connection I use this capability to run a 64 bit ASP.NET handler that talks to a 32 bit FoxPro COM server which allows West Wind Web Connection to run in native 64 bit mode without custom configuration (which is actually quite useful). It's probably not a common usage scenario but it's good to know that you can actually access 32 bit COM objects this way from ASP.NET. For West Wind Web Connection this works out well as the DCOM interface only makes one non-chatty call to the backend server that handles all the rest of the request processing.

Application Pool Isolation is your Friend

For me the recent incident of failure in the classic ASP pages has just been another reminder to be very careful with moving applications to 64 bit operation. There are many little traps when switching to 64 bit that are very difficult to track and test for. I described one issue I had a couple of months ago where one of the default ASP.NET filters was loading the wrong version (32bit instead of 64bit) which was extremely difficult to track down and was caused by a very sneaky configuration switch error (basically 3 different entries for the same ISAPI filter all with different bitness settings). It took me almost a full day to track this down).

Recently I've been taken to isolate individual applications into separate Application Pools rather than my past practice of combining many apps into shared AppPools. This is a good practice assuming you have enough memory to make this work. Application Pool isolate provides more modularity and allows me to selectively move applications to 64 bit. The error above came about precisely because I moved one of my most populous app pools to 64 bit and forgot about the minimal COM object use in some of my old pages. It's easy to forget.

To 64bit or Not

Is it worth it to move to 64 bit? Currently I'd say -not really. In my - admittedly limited - testing I don't see any significant performance increases. In fact 64 bit apps just seem to consume considerably more memory (30-50% more in my pools on average) and performance is minimally improved (less than 5% at the very best) in the load testing I've performed on a couple of sites in both modes. The only real incentive for 64 bit would be applications that require huge data spaces that exceed the 32 bit 4 gigabyte memory limit. However I have a hard time imagining an application that needs 4 gigs of memory in a single Application Pool :-). Curious to hear other opinions on benefits of 64 bit operation.