Re: 64 bit C# trying to call a 32 bit CPP ATL Service
- From: Scott <snorberg@xxxxxxxxxxxxxxxxx>
- Date: Fri, 2 May 2008 06:02:01 -0700
A lot has happened with this issue. I opened a case, SRX080430600180, to get
this answered quicker.
Working with the Microsoft tech on a live session we could easily duplicate
the error from both a 64/cpp and a 64/.net client to the 32 bit atl service.
After a lot of dumping and tracing we decided to create a 64 bit ps.dll for
the 32 bit service. This changed the error from 80040154 to E_NOINTERFACE
(80004002).
We took several more dumps and traces, then I didn't hear from anyone for a
day or so. In the mean time I installed the 2003/sp1 platform SDK, AND
wouldn't you know that seemed to fix the whole thing. Now both the .net and
cpp 64 bit clients can communicate with the 32 bit service, WITHOUT the 64
bit ps.dll we created for the service.
Now this leaves open several questions about how this is supposed to work. I
asked the Microsoft tech, on my case, about Microsoft documentation about how
this is supposed to work and evidently there isn't any, which I think is
really bad!
The ability for a 64 bit client to communicate with a 32 bit service is an
ESSENTIAL migration tool. Without this ability I, and presumably many others,
would have to convert all of their applications to 64 bit before being able
to deploy any of them. This was a major issue for me. All I am saying here is
that I think Microsoft needs to produce some documentation on how this is
supposed to work and what the system requirements are for this to work.
If this is a "It just works" thing, which it obviously isn't, then this is a
bug in Vista which needs to be addressed. If there are other requirements for
this to work, which there seems to be, then the requirements need to be
documented.
In any case I still do not know what the correct way to deploy this is. For
example, do I need to create 64 bit ps.dlls for my 32 bit ATL services? Am I
going to have similar issues with 32 bit clients trying to communicate with
my 64 bit services? Is the 2003 platform SDK required for this to work?
I think it is Microsoft's responsibility to provide answers to these
questions.
--
Scott
"Willy Denoyette [MVP]" wrote:
Inline.
Willy.
"Scott Norberg" <SNORBERG@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:BF0363CF-E617-4044-99B2-66F11229B557@xxxxxxxxxxxxxxxx
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@xxxxxxxxxx> wrote in message
news:%23xqrfVhqIHA.4912@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:00A027F7-2E09-4A6C-B254-50C3B4F3F0D4@xxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:zjpUWXcqIHA.1784@xxxxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxx, 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@xxxxxxxxxxxxxx
==================================================
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.
- Prev by Date: Re: Can event sink accept a return value?
- Next by Date: what's the "default method" of a IDispatch ?
- Previous by thread: Can event sink accept a return value?
- Next by thread: what's the "default method" of a IDispatch ?
- Index(es):
Relevant Pages
|
