DCOM interoperability between Windows XP and Windows 7

Question

I am facing a rather strange and very specific DCOM related problem and I am hoping someone might have encountered it and solved it.

I am trying to instantiate a COM object in an EXE server on a Windows 7 machine (call it W7). The client resides on a Windows XP machine (call it WXP). On WXP the logged-in user is a domain user. On W7 the user is a local user. I have (afaik) correctly set all the DCOM rights, authentication and account privileges. There is no firewall involved.

All I get is that the COM EXE server process is started on W7, with the username I expect, but does not seem to even reach its WinMain function and remains hanging and never dies unless I kill it. I can attach a remote debugger (Visual Studio 2010) to it which will warn me that the process might be deadlocked, and when I break it, it stops in a message queue loop (GetMessage/Dispatch).

The client gets a (seemingly valid) pointer but any attempt to use it, results in E_ACCESSDENIED.

If anything from the scenario above is changed, the instantiation of the COM object succeeds and the object behaves correctly.

I know the chance is slight to find an answer but any tip is extremely welcome.

Thanks.

score 2 · Accepted Answer · answered Jul 20 '12 at 21:37

2

DCOM client and server either needs to be both the same local administrator on workgroup, or domain users on the same domain.

You can use this test app to check if your two machines are configured correctly: http://support.microsoft.com/kb/259011 This way you make sure that your machine's permission and firewall are setup properly first without your own code.

answered Jul 20 '12 at 21:37

yuklai

1,595
1
14
26

Thanks for the reply. I will try it soon and post the results. The confusing thing is that the opposite situation - in which the client is on W7 (not in domain) and the server is on WXP (in domain) - works! It works with local WXP credentials (out of domain) but also with domain credentials. – racanu Jul 21 '12 at 06:51
I took a quick look at the article and I notice that the client does not take credentials (i.e. username/password). This makes me think that it does not supply any AuthInfo in CoInitializeSecurity, which means it connects anonymously to the server. I haven't configured my server for such a situation. I will do it, for the sake of the experiment, but I don't think it will be an acceptable solution for production code. – racanu Jul 21 '12 at 07:01
I have found this article that I had originally missed, that gave me some ideas I might try: http://stackoverflow.com/questions/6123301/how-does-impersonation-in-dcom-work – racanu Jul 21 '12 at 07:11
Vista went through some major security feature changes, but I'm surprised that the reverse setup in your first comment works. I'm probably missing some history here myself. Have you tried using dcomcfng to verify what security settings are currently setup on your server? – yuklai Jul 21 '12 at 16:15
Yes. I added the user that I use on W7 to instantiate the COM server (let's call it srvuser) to the local Distributed COM Users group and then I gave this group full Local and Remote Launch and Activation rights. I also gave the group 'Log on as batch' rights in the Local Security Policy. On the client, I use the credentials of srvuser in CoInitializeSecurity. When the interactive user on the client is a domain user, I get the failure I've described. If the interactive user on the client is a local user, the connection works. I can't imagine what can cause this. – racanu Jul 21 '12 at 20:51

score 1 · Answer 2 · edited May 23 '17 at 10:30

Answering my own question...

It turns out that in the client CoInitializeSecurity didn't have all credentials it needed after all... It was called too early, before the credentials were known.

I discovered this after using CoSetProxyBlanket (as described here: How does impersonation in DCOM work?) on each component I was instantiating. Every component on which I called CoSetProxyBlanket was correctly working. This triggered me to go and double check the CoInitializeSecurity.

It remains strange that the reverse connection (from W7 to WXP) worked, but this is another research I need to do. The current question can be closed.

DCOM interoperability between Windows XP and Windows 7

2 Answers2