Re: Accessing 32 bit COM components in 64 bit IIS

From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 05/07/04 

Date: Fri, 7 May 2004 00:47:20 -0700

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@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@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@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@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

Relevant Pages

  • Re: How to get Perlscript in ASP / IIS to execute command line system calls
    ... Perlscript is running inside of an ASP webpage, ... in the way and works with the DOS command interpreter without problems. ... Obviously there is no problem with perl calling DOS commands via ... ASP (and IIS) are "locked down" for security purposes. ...
    (comp.lang.perl.misc)
  • Re: Setting up a Timer in an ActiveX DLL
    ... Sounds like you need to think about logically separating the data processing ... This cannot be done on a timer inside IIS because ASP executes in the ... IIS server to achieve it via your ASP code. ... your DLL would be executing on multiple threads within IIS. ...
    (microsoft.public.vb.com)
  • Re: Accessing 32 bit COM components in 64 bit IIS
    ... and under the 32bit command line no error is thrown. ... The dll is not in the System32 diectory. ... > to do with IIS or COM registration weirdness involving WOW64. ... > your ASP page. ...
    (microsoft.public.inetserver.iis)
  • RE: ActiveX Too Many Files error from IIS
    ... I have seen this before and the issue was that the program (DLL or ASP page) ... was opening files to read from (config files) and were not closing them when ... > restarting IIS, but this does not solve the problem. ...
    (microsoft.public.inetserver.iis)
  • Re: Using CSocket calls in COM+ DLL blocking IIS 6.0
    ... Then IIS spawns a separate DllHost to host your app. ... Note you didn't solve anything here, only ensured that others' web apps running on the same server won't be affected. ... Since you have many DLLs with this problem, ... IIS creates a threadpool (in ASP or ASPX), and if you think you 'solve' a problem by putting delays at another thread, the aspx or asp might have executed and STILL needs to be blocked, because otherwise, you would have a orphan threading, still doing work, like waiting for data etc... ...
    (microsoft.public.vc.atl)