Re: 64 bit C# trying to call a 32 bit CPP ATL Service
Inline
Willy.
"Scott Norberg" <SNORBERG@NorSoftConsulting.com> wrote in message
news:BF0363CF-E617-4044-99B2-66F11229B557@microsoft.com...
Since my last post I have created a 64 bit (managed) CPP exe that does a
CoCreateInstanceEx to my CPP ATL service (different process), currently
running on the same machine, and I get the same results as with the C# 64
bit process. So it is something more basic then creating the RCW for .net.
Everything is running on Vista 64bit/SP1 using VS2008 for everything.
Same here.
I am not sure what "Virtualized mode" would be in this environment.
Virtualized mode is for backward compatibility, this is the mode that turns
on filesystem and registry reflection, it's only applicable for 32-bit
processes running under Wow64. Virtualization is turned off when the loader
loads an image (exe) that contains a manifest, VS2008 creates such manifest
for all 32-bit targets (managed unmanaged), so your ATL server runs as a
non-virtualized 32-bit process. You can check this with taskman, select
processes and view the virtualization column.
I can see several possible points where this could fail. My first
candidate would be the registry reflection. The 32 bit service would
register under the WOW6432Node. I haven't been able to verify if the 64
CoCreateInstanceEx is smart enough to check that node if it doesn't find
the server in the standard registry, or if somehow the 32 bit server gets
registered under the standard registry keys, by some OS magic.
The 64-bit client side (no matter managed or unmanaged) searches the 64-bit
registry (HKCR\CLSID\{class uuid}) for launch/activation request, typelib
marshaling etc... The server's class factory uses the 32-bit registry to
create the instance of the class.
So you need to make sure that the server is correctly registered for 64 bit,
you can do this by running procmon.exe from sysinternal or by running
regedit and search your class in HKCR\CLSID\{class uuid}.
Anyway if the registry was not kept up to date as the server registers and
de-registers itself you would/could get a 80040154.
"Willy Denoyette [MVP]" <willy.denoyette@telenet.be> wrote in message
news:%23xqrfVhqIHA.4912@TK2MSFTNGP05.phx.gbl...
This should work (works for me), or there is something wrong with the
server registration on a 64-bit OS, or you have a problem related to
registry virtualization on this OS.
What OS version are you running this on?
What version of VS are you using to build the C# client (or the version
of the C# compiler), are you sure that the client isn't running in the
"Virtualized" mode?.
Willy.
"Scott Norberg" <SNORBERG@NorSoftConsulting.com> wrote in message
news:00A027F7-2E09-4A6C-B254-50C3B4F3F0D4@microsoft.com...
Your #3 is exactly the situation we have. The C# program is a separate
process using a CCW to call into a ATL SERVICE, which is DCOM and should
satisfy #3. But this still does NOT work.
"Jialiang Ge [MSFT]" <jialge@online.microsoft.com> wrote in message
news:zjpUWXcqIHA.1784@TK2MSFTNGHUB02.phx.gbl...
Hello Scott,
From your post, my understanding on this issue is: you wonder how to
use a
64bit C# client consume a 32bit ALT service. If I'm off base, please
feel
free to let me know.
Based on my experience, this is a very common question when developers
migrate applications from 32bit platform to 64bit. The answer that
64bit
process cannot load a 32bit module into its process space, and vice
versa,
applies to all the Windows applications, besides this COM scenario.
From
your issue description, I see the ALT service is configured as a
in-process
component. "In-process" means that the 32bit component will be loaded
into
the process space of the client application (64bit). 32bit components
are
registered to HKEY_CLASSES_ROOT\WOW64\CLSID in a 64bit system while
64bit
components are registered to HKEY_CLASSES_ROOT\CLSID. Because our 64bit
client cannot find the component with CLSID or ProgID under
HKEY_CLASSES_ROOT\CLSID registry key, the error 0154(Class not
registered)
is thrown.
To workaround this 32bit versus 64bit conflict, we have three choices:
1. As you've already tried, we can compile the client application to
target
x86 platform that is compatible with the COM component. The problem of
this
workaround is that none 64bit client can consume the component.
2. We build a 64bit version of the ATL service, apart from the 32bit
one.
Then register both on the 64bit machine. In this way, all clients
(regardless of whether 32bit or 64bit) can consume the component.
3. We configure the 32bit ATL service as out-of-process component (e.g.
DCOM), so that the 64bit client process can access the 32-bit DLL
across a
process boundary when the 32-bit DLL is loaded into a separate 32-bit
surrogate process space.
I'd also suggest you read
http://dnjonline.com/article.aspx?ID=jun07_access3264, and the articles
in
its "References" section. They describe the 64-bit versus 32-bit issue
in
very detail.
Let me know if you have any other questions or concerns.
Regards,
Jialiang Ge (jialge@online.microsoft.com, remove 'online.')
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments
and
suggestions about how we can improve the support we provide to you.
Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@microsoft.com.
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent
issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each
follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach
the
most efficient resolution. The offering is not appropriate for
situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are
best
handled working with a dedicated Microsoft Support Engineer by
contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.