64 bit issues

Sep 23, 2008 at 4:18 PM
Edited Sep 23, 2008 at 4:18 PM

It appears that for 64 bit systems the Explorer OM is not supported

D:\>BtsControl FullStopApp -ApplicationName:AppName
Microsoft (R) BizTalk Application Deployment Utility Version
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

Information: Completely stopping BizTalk application "AppName", configuration database (server="DDB", database="BizTalkMgmtDb")...
Error: Explorer OM is not supported in a 64bit process.

Command failed with 1 errors, 0 warnings.

May 27, 2009 at 10:37 PM

I apologize for not responding sooner; I did not have access to a 64bit BizTalk 2006 environment until just now. 

This is a particularly fascinating find of yours, because it is not actually a shortcoming with my little tool but rather it highlights an interesting "feature" of 64bit windows.  It has a quick solution, but I want to share with you the steps I took to find the solution so that you can do the same:

I was able to reproduce this exact same error, so I started by looking for the DLL that contains the Explorer OM, namely "Microsoft.BizTalk.ExplorerOM, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35".  I found this under C:\Program Files (x86)\Microsoft BizTalk Server 2006\Developer Tools\Microsoft.BizTalk.ExplorerOM.dll .  It was the EXACT same version as the one used on 32-bit systems (I could tell this by using Red Gate's (Roeder's) .NET Reflector). 

I knew that btstask.exe (at least on the 32-bit systems) used this same assembly in order to iterate over the BizTalk object space, so I tried running btstask.exe on the 64-bit system:

"btstask listapps"

I got the expected output.  Hmm.  How is it doing this without calling the Explorer OM?  I opened btstask.exe into Reflector and saw that it, too, was the exact same version as the one used on 32-bit systems.  It referenced the same Explorer OM dll and had the same function constructor in the BtsCatalogExplorer class (the one that gives us that error message):

if (IntPtr.Size != 4) { throw new BtsException(Resources.IDS_ERR_64BIT_NOT_SUPPORTED); }

OK, so if ExplorerOM DLL and btstask.exe are the same on the 64-bit system as on the 32-bit system, how is it that it functions properly and my btscontrol.exe fails?  Well, note the error message we got: "not supported in a 64bit process". 

On a hunch, I opened taskmanager and saw that wherever there is a process running in a 32-bit process space, there is a *32 next to the image name.  For example, "VMwareService.exe *32".  Since ExplorerOM is not the original executable that starts the process, perhaps btstask.exe is being started in a 32-bit process?  But btstask.exe runs and terminates so quickly, how could I get it to show up long enough to tell? 

I ran

btstask exportapp -ApplicationName:"BizTalk Application 1" 

Sure enough, it shows up just long enough in TaskManager for me to see "btstask.exe *32". 

So it IS running in a 32-bit process and that is how it is still able to use the Explorer OM DLL!  But what makes it run as a 32-bit process?  I checked all through the registry for references to btstask.exe.  None matched what I was looking for.  Then I did a Google Search and stumbled upon this article (among others): http://www.request-response.com/blog/PermaLink,guid,34966ef8-3142-46b2-84e0-372b5c36ddcc.aspx author: Matevz Gacnik.  

In a nutshell, if you want to force a .NET executable to run as either 32-bit or 64-bit, you have two options:

(1) you can change the project setting in VS2005/8 from compiling to "ANY" to compiling explicitly to x86 or to 64bit.  A pain if you don't have the source code ;)

(2) you can run corflags.exe on the executable to set the 64bit flag.  Corflags is a little utility found in the .NET 2.0 SDK.  On a 32bit system, you can find it under "c:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\" or on Windows XP you can just go to Start Menu -> Programs -> Microsoft .NET Framework SDK v2.0 -> SDK Command Prompt.

I did #2:

corflags "Y:\Program Files (x86)\Microsoft BizTalk Server 2006\BTSControl.exe" /32bit+

(the Y: drive shows that I was executing this command from my 32-bit WinXP machine on to file located on a mapped drive to C$ of the Windows Server 2003 64-bit machine).

Note that this actually alters the executable image itself.  The proof of that is I copied this now-modified btscontrol.exe to another 64-bit server and it ran flawlessly.

So, now, why is this "feature" so important to know about?  Well, there are a lot of applications and programs that ONLY run under 32-bit process space.  If you have any ASP.NET 1.1 apps that you migrate to 64-bit, for example, you have to explicitly run a certain Microsoft-supplied vbscript to force IIS to run in 32bit and then you have to reinstall ASP.NET 1.1.  I am not going to include the details here, just know that it is a KB article that is referenced many times out on the Internet. 

Another for instance: ODBC Manager doesn't work right for the Oracle ODBC adapter for BizTalk.  You have to install the ODBC drivers for x32.  I don't know all the details on this, I only know that we couldn't get the Oracle ODBC adapter to work until we installed the 32bit version of the ODBC manager/driver (this was all Windows 2003 R2 x64).

Enough babbling, point is that you can make btscontrol.exe and many of your other apps work by forcing them to run in a 32-bit process space.  Hope someone finds this useful.

Thanks for your feedback, enhancements are being considered.

Subcutaneous D


Jun 17, 2009 at 12:16 PM

Hi Please help.

I am getting the following error when trying to browse ESB.Portal on ESB 1.0


Event Type: Error
Event Source: Microsoft.Practices.ESB
Event Category: None
Event ID: 6010
Date:  2009/06/17
Time:  12:25:14 PM
User:  N/A
Explorer OM is not supported in a 64bit process.

Source: Microsoft.Practices.ESB.BizTalkOperations.BizTalkQuery

Method: Void .ctor()

Error Source: Microsoft.BizTalk.ExplorerOM

Error TargetSite: Void .ctor() 

Error StackTrace:    at Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer..ctor()
   at Microsoft.Practices.ESB.BizTalkOperations.BizTalkQuery..ctor()


When I try to run the following:
C:\>CorFlags.exe "C:\Program Files (x86)\Microsoft BizTalk Server 2006\BTSTask.exe" /32BIT+ /Force

I get this error:
Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  2.0.50727.42 Copyright (c) Microsoft Corporation.  All rights reserved.

corflags : warning CF011 : The specified file is strong name signed.  Using /Force will invalidate the signature of this image and will require the assembly tobe resigned.

Jul 24, 2009 at 1:32 PM

@wonder: I'm going to go out on a limb here since I have not directly worked with the ESB portal.  I am going to assume that when you say you are "trying to browse ESB.Portal on ESB 1.0", that you mean to say you are trying to browse some particular website that came with the BizTalk ESB using Internet Explorer, Firefox, or [insert your preferred browser here].  OK, this is a fair issue, and I think that perhaps my explanation above could stand some further clarification.

To all: when using the Microsoft.BizTalk.ExplorerOM.dll from ANY application, whether it be BTSControl, BTSTask, ESB.Portal, etc. etc., what is important is the CALLER.  The originating or initial executable that first creates the Windows process is the key here.  If this very first executable does not start in a 32-bit process space, then when it goes to load the Microsoft.BizTalk.ExplorerOM.dll and tries to create an instance of the BTSCatalogExplorer class, the constructor for that class detects that it is not being called from a 32-bit process space and it throws this lovely error that we are all familiar with ("Explorer OM is not supported in a 64bit process").

So, wonder, ask yourself: what is the originating or initial executable that is trying to load the Microsoft.BizTalk.ExplorerOM.dll?  Is it the ESB.Portal?  No, it is the Internet Explorer executable!  iexplore.exe or firefox.exe needs to be constrained to start/run in a 32-bit process space.  Yes, you heard me right.

OK, assuming that is what we want to do....:wait, really?  You want me to run corflags on iexplore.exe?!" 

Actually, no.  You don't need to run corflags.  It turns out that Microsoft had enough foresight to see that there might be a need for running Internet Explorer in a 32-bit process space.  So that is why there are two binary versions of the same executable on your 64-bit Windows machine: C:\Program Files (x86)\Internet Explorer\iexplore.exe and C:\Program Files\Internet Explorer\iexplore.exe.  Try it yourself if you are not convinced: double-click to run each executable with Windows Task Manager open and you will see that one runs with the *32 next to its image name and the other one does not.

Cool beans.  Thank you, wonder, for bringing this to my attention. 

P.S.  One small detail worth mentioning: if you look at the file properties on the iexplore.exe file (in Windows Explorer), there is NOTHING in all those file properties that indicates that it is for 32-bit or 64-bit; file versions are exactly the same, etc.  Is there some way to find out if an executable has been modified by corflags?  I will leave that as an exercise for the astute reader :)