Accessing 32 bit COM components in 64 bit IIS

Thanks for your reply David. I appreciate that the problem isn't so
much to do with IIS but your replies in this forum were the only place
I seemed to be able to find any information on the subject.

From the 64 bit Windows documentation I gather the following...

C:\Windows\SysWow64 contains a 32 bit version of regsvr32.exe
C:\Windows\System32 contains a 64 bit version of regsvr32.exe

Just to be sure the component was registered using both the 32 bit
regsrv32.exe program and the 64 bit regsvr32.exe program.

Before the 64 bit registration the error reported was
ASP 0177: COM Error 0x800401f3: This error code means ‘Not
registered'

After the 64 bit registration the error reported was
COM Error 0x800a01ad: This error code means ‘Not all components are
accessible'

Once the 32bit COM component is loaded into DLLHOST.EXE it is then a
32 bit application which may need to load other 32 bit components.
However this should not be a problem as the 32 bit VB application that
does the same thing as the ASP page works fine. The ASP page error
occurs at the point when it tries to load the first 32 bit component.
Is there some sort of ASP setting which enables out of process 32 bit
components perhaps?

David



"David Wang [Msft]" <someone.TakeThisOut@online.microsoft.com> wrote in message news:<#4Az2tXKEHA.3184@TK2MSFTNGP10.phx.gbl>...
 > Welcome to WOW64. You have to be aware of all the rules, or else behavior
 > will look very strange. All of this has NOTHING to do with IIS -- it
 > applies generically to all processes on Windows. IIS is just another
 > process.
 >
 > COM component registration exists in two locations, one for 64bit processes
 > and one for 32bit processes. Where a registration goes depends on the
 > bitness of the process that does the registration. If the registration is
 > done by a 32bit process, like some existing x86 setup.exe, then it is only
 > going to exist in the 32bit location. If the registration is done by a
 > 64bit process, it will exist in the 64bit location and be mirrored to the
 > 32bit location.
 >
 > Thus, it is possible to register a COM component on a 64bit OS and have it
 > only available to 32bit process (like VB) but not 64bit process (like
 > ASP.DLL interpreting ASP pages).
 >
 > Therefore, I have to ask how you registered this COM component -- because if
 > you just ran the x86 setup program, it's likely to only exist for 32bit
 > processes like VB -- ASP runs as a 64bit process, so it's not going to see
 > that component unless you register it in 64bit as well -- and this explains
 > your observation.
 >
 > --
 > //David
 > IIS<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Accessing 32 bit COM components in 64 bit IIS 

I thought I would update this thread with the tiniest extra piece of
info that we've recently uncovered.

Running a dependency walker on the XMLA SDK dll says that there are no
other dependencies though I guess there could still be other COM
dependencies.

Any suggestions would be greatly appreciated.

David

david_hood.TakeThisOut@hotmail.com (David Hood) wrote in message news:<60eec15e.0404261004.613936ea.TakeThisOut@posting.google.com>...
 > Thanks for your reply David. I appreciate that the problem isn't so
 > much to do with IIS but your replies in this forum were the only place
 > I seemed to be able to find any information on the subject.
 >
 > From the 64 bit Windows documentation I gather the following...
 >
 > C:\Windows\SysWow64 contains a 32 bit version of regsvr32.exe
 > C:\Windows\System32 contains a 64 bit version of regsvr32.exe
 >
 > Just to be sure the component was registered using both the 32 bit
 > regsrv32.exe program and the 64 bit regsvr32.exe program.
 >
 > Before the 64 bit registration the error reported was
 > ASP 0177: COM Error 0x800401f3: This error code means ?Not
 > registered'
 >
 > After the 64 bit registration the error reported was
 > COM Error 0x800a01ad: This error code means ?Not all components are
 > accessible'
 >
 > Once the 32bit COM component is loaded into DLLHOST.EXE it is then a
 > 32 bit application which may need to load other 32 bit components.
 > However this should not be a problem as the 32 bit VB application that
 > does the same thing as the ASP page works fine. The ASP page error
 > occurs at the point when it tries to load the first 32 bit component.
 > Is there some sort of ASP setting which enables out of process 32 bit
 > components perhaps?
 >
 > David
 >
 >
 >
 > "David Wang [Msft]" <someone.TakeThisOut@online.microsoft.com> wrote in message news:<#4Az2tXKEHA.3184@TK2MSFTNGP10.phx.gbl>...
  > > Welcome to WOW64. You have to be aware of all the rules, or else behavior
  > > will look very strange. All of this has NOTHING to do with IIS -- it
  > > applies generically to all processes on Windows. IIS is just another
  > > process.
  > >
  > > COM component registration exists in two locations, one for 64bit processes
  > > and one for 32bit processes. Where a registration goes depends on the
  > > bitness of the process that does the registration. If the registration is
  > > done by a 32bit process, like some existing x86 setup.exe, then it is only
  > > going to exist in the 32bit location. If the registration is done by a
  > > 64bit process, it will exist in the 64bit location and be mirrored to the
  > > 32bit location.
  > >
  > > Thus, it is possible to register a COM component on a 64bit OS and have it
  > > only available to 32bit process (like VB) but not 64bit process (like
  > > ASP.DLL interpreting ASP pages).
  > >
  > > Therefore, I have to ask how you registered this COM component -- because if
  > > you just ran the x86 setup program, it's likely to only exist for 32bit
  > > processes like VB -- ASP runs as a 64bit process, so it's not going to see
  > > that component unless you register it in 64bit as well -- and this explains
  > > your observation.
  > >
  > > --
  > > //David
  > > IIS<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Accessing 32 bit COM components in 64 bit IIS 

Hmm, weird. Can you check that all of the COM registrations made it to the
right parts of the registry? I want to distinguish whether your problem has
to do with IIS or COM registration weirdness involving WOW64.

You should be able to reproduce your situation outside of ASP by creating a
simple script on the commandline like:

-- Test.js contents ---
var obj = new ActiveXObject( "YourComponent.ProgId" );

And running it from a 64bit CMD shell window (default behavior). If the
problem is just with COM registration, this should fail just like it does in
your ASP page.

And if you run this script from a 32bit CMD shell window, using "start
%SYSTEMROOT%\SYSWOW64\CMD.EXE" from any commandline, it should work just
like in your VB App.

If this is what you see, then the issue has nothing to do with IIS and
everything to do with the registration of your component... and at this
point, we need to start digging around in the registry. It now becomes VERY
important the bitness of the tools/commands that you run -- you cannot
substitute bitness unless you know it has no effect on what you're looking
at.

What I first want to know is where all DLLs related to the component are
located. Are they inside the System32 directory or not?

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"David Hood" <david_hood DeleteThis @hotmail.com> wrote in message
news:60eec15e.0404261004.613936ea@posting.google.com...
Thanks for your reply David. I appreciate that the problem isn't so
much to do with IIS but your replies in this forum were the only place
I seemed to be able to find any information on the subject.

From the 64 bit Windows documentation I gather the following...

C:\Windows\SysWow64 contains a 32 bit version of regsvr32.exe
C:\Windows\System32 contains a 64 bit version of regsvr32.exe

Just to be sure the component was registered using both the 32 bit
regsrv32.exe program and the 64 bit regsvr32.exe program.

Before the 64 bit registration the error reported was
ASP 0177: COM Error 0x800401f3: This error code means 'Not
registered'

After the 64 bit registration the error reported was
COM Error 0x800a01ad: This error code means 'Not all components are
accessible'

Once the 32bit COM component is loaded into DLLHOST.EXE it is then a
32 bit application which may need to load other 32 bit components.
However this should not be a problem as the 32 bit VB application that
does the same thing as the ASP page works fine. The ASP page error
occurs at the point when it tries to load the first 32 bit component.
Is there some sort of ASP setting which enables out of process 32 bit
components perhaps?

David



"David Wang [Msft]" <someone DeleteThis @online.microsoft.com> wrote in message
news:<#4Az2tXKEHA.3184@TK2MSFTNGP10.phx.gbl>...
 > Welcome to WOW64. You have to be aware of all the rules, or else behavior
 > will look very strange. All of this has NOTHING to do with IIS -- it
 > applies generically to all processes on Windows. IIS is just another
 > process.
 >
 > COM component registration exists in two locations, one for 64bit
processes
 > and one for 32bit processes. Where a registration goes depends on the
 > bitness of the process that does the registration. If the registration is
 > done by a 32bit process, like some existing x86 setup.exe, then it is only
 > going to exist in the 32bit location. If the registration is done by a
 > 64bit process, it will exist in the 64bit location and be mirrored to the
 > 32bit location.
 >
 > Thus, it is possible to register a COM component on a 64bit OS and have it
 > only available to 32bit process (like VB) but not 64bit process (like
 > ASP.DLL interpreting ASP pages).
 >
 > Therefore, I have to ask how you registered this COM component -- because
if
 > you just ran the x86 setup program, it's likely to only exist for 32bit
 > processes like VB -- ASP runs as a 64bit process, so it's not going to see
 > that component unless you register it in 64bit as well -- and this
explains
 > your observation.
 >
 > --
 > //David
 > IIS<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Accessing 32 bit COM components in 64 bit IIS 

I followed your instructions and that is exactly what happens. Under
the 64bit command line I get "Automation server can't create object"
and under the 32bit command line no error is thrown. So, as you say,
the problem must be to do with how the dll is registered.

The exact line in the Test.js file was...
var obj = new ActiveXObject( "MSXmlAnalysisSC.XmlAnalysis" );

The dll is not in the System32 diectory. It is installed under
c:\Program Files\Microsoft XML for Analysis SDK\
Under this directory there is a dll called msxaserv.dll. There is also
a dll under an "isapi" subdirectory called msxisapi.dll.

Both of the directories have been added to the path. The msxaserv.dll
has been registered successfully with both the 32bit and 64bit
regsvr32.

msxisapi.dll does not register under the 32 bit or 64 bit regsvr32
command line and fails with an "entry point was not found" message so
I assume that the it is just msxaserv that is used by the COM objects.
Is there a specific part of the registry I should be looking at to get
further with this?

Your help is much appreciated.

David

"David Wang [Msft]" <someone.TakeThisOut@online.microsoft.com> wrote in message news:<u#onmClLEHA.1032@tk2msftngp13.phx.gbl>...
 > Hmm, weird. Can you check that all of the COM registrations made it to the
 > right parts of the registry? I want to distinguish whether your problem has
 > to do with IIS or COM registration weirdness involving WOW64.
 >
 > You should be able to reproduce your situation outside of ASP by creating a
 > simple script on the commandline like:
 >
 > -- Test.js contents ---
 > var obj = new ActiveXObject( "YourComponent.ProgId" );
 >
 > And running it from a 64bit CMD shell window (default behavior). If the
 > problem is just with COM registration, this should fail just like it does in
 > your ASP page.
 >
 > And if you run this script from a 32bit CMD shell window, using "start
 > %SYSTEMROOT%\SYSWOW64\CMD.EXE" from any commandline, it should work just
 > like in your VB App.
 >
 > If this is what you see, then the issue has nothing to do with IIS and
 > everything to do with the registration of your component... and at this
 > point, we need to start digging around in the registry. It now becomes VERY
 > important the bitness of the tools/commands that you run -- you cannot
 > substitute bitness unless you know it has no effect on what you're looking
 > at.
 >
 > What I first want to know is where all DLLs related to the component are
 > located. Are they inside the System32 directory or not?
 >
 > --
 > //David
 > IIS
 > This posting is provided "AS IS" with no warranties, and confers no rights.
 > //
 > "David Hood" <david_hood.TakeThisOut@hotmail.com> wrote in message
 > news:60eec15e.0404261004.613936ea@posting.google.com...
 > Thanks for your reply David. I appreciate that the problem isn't so
 > much to do with IIS but your replies in this forum were the only place
 > I seemed to be able to find any information on the subject.
 >
 > From the 64 bit Windows documentation I gather the following...
 >
 > C:\Windows\SysWow64 contains a 32 bit version of regsvr32.exe
 > C:\Windows\System32 contains a 64 bit version of regsvr32.exe
 >
 > Just to be sure the component was registered using both the 32 bit
 > regsrv32.exe program and the 64 bit regsvr32.exe program.
 >
 > Before the 64 bit registration the error reported was
 > ASP 0177: COM Error 0x800401f3: This error code means 'Not
 > registered'
 >
 > After the 64 bit registration the error reported was
 > COM Error 0x800a01ad: This error code means 'Not all components are
 > accessible'
 >
 > Once the 32bit COM component is loaded into DLLHOST.EXE it is then a
 > 32 bit application which may need to load other 32 bit components.
 > However this should not be a problem as the 32 bit VB application that
 > does the same thing as the ASP page works fine. The ASP page error
 > occurs at the point when it tries to load the first 32 bit component.
 > Is there some sort of ASP setting which enables out of process 32 bit
 > components perhaps?
 >
 > David
 >
 >
 >
 > "David Wang [Msft]" <someone.TakeThisOut@online.microsoft.com> wrote in message
 > news:<#4Az2tXKEHA.3184@TK2MSFTNGP10.phx.gbl>...
  > > Welcome to WOW64. You have to be aware of all the rules, or else behavior
  > > will look very strange. All of this has NOTHING to do with IIS -- it
  > > applies generically to all processes on Windows. IIS is just another
  > > process.
  > >
  > > COM component registration exists in two locations, one for 64bit
 > processes
  > > and one for 32bit processes. Where a registration goes depends on the
  > > bitness of the process that does the registration. If the registration is
  > > done by a 32bit process, like some existing x86 setup.exe, then it is only
  > > going to exist in the 32bit location. If the registration is done by a
  > > 64bit process, it will exist in the 64bit location and be mirrored to the
  > > 32bit location.
  > >
  > > Thus, it is possible to register a COM component on a 64bit OS and have it
  > > only available to 32bit process (like VB) but not 64bit process (like
  > > ASP.DLL interpreting ASP pages).
  > >
  > > Therefore, I have to ask how you registered this COM component -- because
 > if
  > > you just ran the x86 setup program, it's likely to only exist for 32bit
  > > processes like VB -- ASP runs as a 64bit process, so it's not going to see
  > > that component unless you register it in 64bit as well -- and this
 > explains
  > > your observation.
  > >
  > > --
  > > //David
  > > IIS<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Accessing 32 bit COM components in 64 bit IIS 

I downloaded and looked at this component. It will not work under 64bit
IIS.

It is a 32bit component and is writing its registration info to the Registry
when you call DllRegisterServer via regsvr32.exe. Since it's 32bit code
that is writing to the registry, no matter how you regsvr32 it, it is not
going to be able to write its configuration into the 64bit part of the
Registry -- hence 64bit scripts instantiating this component will never find
it.

However, it is a component that is registered to run "in-process" (i.e.
inside the process that instantiates it), which won't work -- I ported its
32bit registration into the 64bit registration and all I saw was "bad
image" -- meaning the 32bit DLL was being loaded into the 64bit process and
failing.

In WS03SP1, we will be introducing the ability to configure IIS to run under
WOW64 (i.e. 32bit compatibility mode) and launch 32bit w3wp.exe -- which
should resolve this issue since it will be a 32bit ASP, loading the 32bit
component, all into a 32bit w3wp.exe

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"David Hood" <david_hood.RemoveThis@hotmail.com> wrote in message
news:60eec15e.0405040402.7ec5b0af@posting.google.com...
I followed your instructions and that is exactly what happens. Under
the 64bit command line I get "Automation server can't create object"
and under the 32bit command line no error is thrown. So, as you say,
the problem must be to do with how the dll is registered.

The exact line in the Test.js file was...
var obj = new ActiveXObject( "MSXmlAnalysisSC.XmlAnalysis" );

The dll is not in the System32 diectory. It is installed under
c:\Program Files\Microsoft XML for Analysis SDK\
Under this directory there is a dll called msxaserv.dll. There is also
a dll under an "isapi" subdirectory called msxisapi.dll.

Both of the directories have been added to the path. The msxaserv.dll
has been registered successfully with both the 32bit and 64bit
regsvr32.

msxisapi.dll does not register under the 32 bit or 64 bit regsvr32
command line and fails with an "entry point was not found" message so
I assume that the it is just msxaserv that is used by the COM objects.
Is there a specific part of the registry I should be looking at to get
further with this?

Your help is much appreciated.

David

"David Wang [Msft]" <someone.RemoveThis@online.microsoft.com> wrote in message
news:<u#onmClLEHA.1032@tk2msftngp13.phx.gbl>...
 > Hmm, weird. Can you check that all of the COM registrations made it to
the
 > right parts of the registry? I want to distinguish whether your problem
has
 > to do with IIS or COM registration weirdness involving WOW64.
 >
 > You should be able to reproduce your situation outside of ASP by creating
a
 > simple script on the commandline like:
 >
 > -- Test.js contents ---
 > var obj = new ActiveXObject( "YourComponent.ProgId" );
 >
 > And running it from a 64bit CMD shell window (default behavior). If the
 > problem is just with COM registration, this should fail just like it does
in
 > your ASP page.
 >
 > And if you run this script from a 32bit CMD shell window, using "start
 > %SYSTEMROOT%\SYSWOW64\CMD.EXE" from any commandline, it should work just
 > like in your VB App.
 >
 > If this is what you see, then the issue has nothing to do with IIS and
 > everything to do with the registration of your component... and at this
 > point, we need to start digging around in the registry. It now becomes
VERY
 > important the bitness of the tools/commands that you run -- you cannot
 > substitute bitness unless you know it has no effect on what you're looking
 > at.
 >
 > What I first want to know is where all DLLs related to the component are
 > located. Are they inside the System32 directory or not?
 >
 > --
 > //David
 > IIS
 > This posting is provided "AS IS" with no warranties, and confers no
rights.
 > //
 > "David Hood" <david_hood.RemoveThis@hotmail.com> wrote in message
 > news:60eec15e.0404261004.613936ea@posting.google.com...
 > Thanks for your reply David. I appreciate that the problem isn't so
 > much to do with IIS but your replies in this forum were the only place
 > I seemed to be able to find any information on the subject.
 >
 > From the 64 bit Windows documentation I gather the following...
 >
 > C:\Windows\SysWow64 contains a 32 bit version of regsvr32.exe
 > C:\Windows\System32 contains a 64 bit version of regsvr32.exe
 >
 > Just to be sure the component was registered using both the 32 bit
 > regsrv32.exe program and the 64 bit regsvr32.exe program.
 >
 > Before the 64 bit registration the error reported was
 > ASP 0177: COM Error 0x800401f3: This error code means 'Not
 > registered'
 >
 > After the 64 bit registration the error reported was
 > COM Error 0x800a01ad: This error code means 'Not all components are
 > accessible'
 >
 > Once the 32bit COM component is loaded into DLLHOST.EXE it is then a
 > 32 bit application which may need to load other 32 bit components.
 > However this should not be a problem as the 32 bit VB application that
 > does the same thing as the ASP page works fine. The ASP page error
 > occurs at the point when it tries to load the first 32 bit component.
 > Is there some sort of ASP setting which enables out of process 32 bit
 > components perhaps?
 >
 > David
 >
 >
 >
 > "David Wang [Msft]" <someone.RemoveThis@online.microsoft.com> wrote in message
 > news:<#4Az2tXKEHA.3184@TK2MSFTNGP10.phx.gbl>...
  > > Welcome to WOW64. You have to be aware of all the rules, or else
behavior
  > > will look very strange. All of this has NOTHING to do with IIS -- it
  > > applies generically to all processes on Windows. IIS is just another
  > > process.
  > >
  > > COM component registration exists in two locations, one for 64bit
 > processes
  > > and one for 32bit processes. Where a registration goes depends on the
  > > bitness of the process that does the registration. If the registration
is
  > > done by a 32bit process, like some existing x86 setup.exe, then it is
only
  > > going to exist in the 32bit location. If the registration is done by a
  > > 64bit process, it will exist in the 64bit location and be mirrored to
the
  > > 32bit location.
  > >
  > > Thus, it is possible to register a COM component on a 64bit OS and have
it
  > > only available to 32bit process (like VB) but not 64bit process (like
  > > ASP.DLL interpreting ASP pages).
  > >
  > > Therefore, I have to ask how you registered this COM component --
because
 > if
  > > you just ran the x86 setup program, it's likely to only exist for 32bit
  > > processes like VB -- ASP runs as a 64bit process, so it's not going to
see
  > > that component unless you register it in 64bit as well -- and this
 > explains
  > > your observation.
  > >
  > > --
  > > //David
  > > IIS<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Accessing 32 bit COM components in 64 bit IIS