That was the error message that greeted me in a packet trace this morning while trying to troubleshoot why we couldn't connect over HTTP to SQL Server 2005 Analysis Services (64Bit) over HTTP.
Looking around I saw issues with a file c:\Program causing issues but this wasn't it.
Fired up Filemon from SysInternals (love those guys utilities!) and found that it was loading WOW64 to load the AS2005 ISAPI filter. Don't get me started on how lame it is that AS2005 doesn't integrate with HTTP.SYS to provide XMLA over HTTP support natively instead of using an ISAPI filter. Never the less it seemed a little odd that it was loading into WOW64. Started racking my brains for what I had done on the server to date.
Realized we had installed some ASP.NET code to manage the AS instance. It had problems running under ASP.NET 2.0 so I had loaded it under ASP.NET 1.1. Since ASP.NET 1.1 was only 32-Bit I had to set the Enable32bitAppOnWin64 to true. What I didn't realize when I did this is that this flag controls all worker processes under IIS 6.0. So all of my worker processes were now loading the 32-Bit worker process in Wow64. When it tried to load a 64Bit ISAPI extension in the worker process it complained (as it should) that this wasn't a valid Win32 application.
Long story short. IIS6.0 makes you run either all 64-Bit code or all 32-Bit code. You cannot mix the two.