Re: Accessing 32 bit COM components in 64 bit IIS
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 05/11/04
- Next message: CJM: "Re: IIS5.1: 404 error when ASP page is called"
- Previous message: David Wang [Msft]: "Re: Need help on windows server 2003"
- In reply to: David Hood: "Re: Accessing 32 bit COM components in 64 bit IIS"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 11 May 2004 03:05:19 -0700
You should look at Windows Server 2003 SP1, which will have the WOW64 change
to allow IIS6 to run 32bit code natively. We've been testing it for a
while, and it works pretty well for apps that follow good rules. I know of
several beta cases where they just moved their huge websites of 32bit ISAPI,
CGIs, and ASP scripts onto a 64bit machine, and it just works after they
flipped the IIS6 flag to run in 32bit mode (and removed a couple of 64bit
DLLs that can't remove themselves).
The most confusing aspect of running 32bit app on a 64bit OS is that you
have to remember that 32bit apps do not know anything about 64bit apps
(remember the Registry is reflected for COM components and Software, the
System32 access is redirected, etc). So, 32bit app runs inside its own
little sandbox and cannot configure the entire system. Native 64bit app is
able to do everything. It's when you try to cross bitness that things do
not work the way you expect -- and if you keep it straight, the behavior
will make sense.
The most amusing thing to me, of course, is seeing that System, System32,
and SYSWOW64 exist on a 64bit platform. That's 16bit, 32bit, and 64bit
stuff all running... and the strange thing being that System32 contains
64bit code while SYSWOW64 contains 32bit code...
-- //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.0405070802.5f8b28c0@posting.google.com... David, Thank you very much for looking into this in such detail. It certainly looks like the jump to 64bit Windows will be interesting for a few products though I guess the same was true of 16 to 32bit jump too. Thanks again, David Hood "David Wang [Msft]" <someone@online.microsoft.com> wrote in message news:<eb6Z3fANEHA.1348@TK2MSFTNGP10.phx.gbl>... > 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
- Next message: CJM: "Re: IIS5.1: 404 error when ASP page is called"
- Previous message: David Wang [Msft]: "Re: Need help on windows server 2003"
- In reply to: David Hood: "Re: Accessing 32 bit COM components in 64 bit IIS"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
