Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

CoCreateInstanceEx hangs with service on Automatic

Posted on 2000-03-22
14
Medium Priority
?
498 Views
Last Modified: 2011-10-03
I have a DCOM system service connecting to another machine's DCOM server using CoCreateInstanceEx. When the service is started manually, it works just fine, however, when it is set to "Automatic", it just hangs on the CoCreateInstanceEx call when the machine is rebooted. The service is dependent on the RPCSS service, so that's not the problem. I've tried to add a Sleep for four minutes a the first thing done in WinMain, and also to attach the Visual Studio debugger during that time, but that does not help. What could be the problem?
0
Comment
Question by:fjuk
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
14 Comments
 
LVL 1

Expert Comment

by:yarond
ID: 2658339
Maybe the COM object your're using is interactive or requires a logon user?
Try running it under a specific account istead of the system account, or try to (security-wise unhealthy) have your service logon to the computer when initialized.
0
 
LVL 1

Expert Comment

by:rskathait
ID: 2659511
I agree with yarond, However check this
Article ID: Q165300 in MSDN, this is a accepted bug from Microsoft.

rgds.
0
 

Author Comment

by:fjuk
ID: 2660067
I'm running WinNT 4.0 so the Q165300 didn't really apply, but I added a wait for RPCSS anyway, and it was already started. Both the client and the server are running as specified accounts.

I've observed one strange thing: if I restart the client machine (without stopping the hanging CoCreateInstanceEx call), the server finally gets into the COM object constructor, but that seems to happen when the hanging thread is killed. The destructor is not entered until after a few minutes, when the client machine has already restarted (ping timeout, I guess).

It does not matter if the hanging call is made before or after I log in on the server (I have quite a long wait for another service, so I can log in before the call is made).

I have tested it after completely unregister the DCOM server, and I got the same result, so it should have nothing to do with the server application.

Running under the system account made no difference. Pulling the network plug before the call also made no difference, so it should have nothing to do with the server side.
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 

Author Comment

by:fjuk
ID: 2663477
Adjusted points from 200 to 250
0
 
LVL 1

Expert Comment

by:clarka
ID: 2680842
I have had similar problems with CoCreateInstanceEx blocking when I created network failures.  I implemented a tcp/ip ping from the client to the server machine to make sure I could talk to it before I called CoCreateInstanceEx.  
This may not be your problem, but here are some more thoughts:  

When DCOM tries to connect to another box it will try all of the protocols listed in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\DCOM Protocols key, in that order.
Make sure ncacn_ip_tcp is listed first, and reboot after the change because this key is only read at startup.

If you don’t register the service on the box your trying to talk to, but register it as a com object does it get launched when you reboot the other box?

Are these two pc on the same domain?
Are these two pc in a workgroup.
Are one of these pc a PDC or BDC?

AC...
0
 

Author Comment

by:fjuk
ID: 2686513
Thanks,

I've now checked that the "DCOM Protocols" setting was correct.
I tried to use the client machine also as server machine (but still specifying the machine name), but nothing changed. Unregistering the proxy dll didn't change anything, either. Thus it shouldn't matter if the machines are on the same domain or not.

Adding a ping *should* not help, since I have tested with a delay of several minutes before I did the connection, and I can ping the server machine manually from the client machine.
0
 

Author Comment

by:fjuk
ID: 2686515
Thanks,

I've now checked that the "DCOM Protocols" setting was correct.
I tried to use the client machine also as server machine (but still specifying the machine name), but nothing changed. Unregistering the proxy dll didn't change anything, either. Thus it shouldn't matter if the machines are on the same domain or not.

Adding a ping *should* not help, since I have tested with a delay of several minutes before I did the connection, and I can ping the server machine manually from the client machine.
0
 

Author Comment

by:fjuk
ID: 2686600
Adjusted points from 250 to 300
0
 

Author Comment

by:fjuk
ID: 2686658
It is not a PDC and not a BDC.
It is a NT Server machine, with NT service pack 6a.
0
 

Author Comment

by:fjuk
ID: 2686678
It is not a PDC and not a BDC.
It is a NT Server machine, with NT service pack 6a.
0
 

Author Comment

by:fjuk
ID: 2686787
It is not a PDC and not a BDC.
It is a NT Server machine, with NT service pack 6a.
0
 
LVL 1

Expert Comment

by:clarka
ID: 2687283
There are security issues involved when you try to make a dcom call, so it does matter if you are on the same domain or not. I did not say a dcom call from one domain to another would not work, it will.  The security must be setup correctly to allow it.  I have rolled out a product that does an NT Service to NT Service DCOM call and it works with no issues.
0
 

Accepted Solution

by:
fjuk earned 1200 total points
ID: 2703076
I just thought that if I'd limit everything configured to one single machine (no references to outside domains), there should be no dependency on the other domain (since I even tested unplugging the machine, the problem wasn't even related to the domain the machine is in).

In fact, I recently found the problem, by using a utility for configuring service dependencies recommended by a colleague (http://www.nttools-online.de/english/srvmgr.htm), adding almost all services as dependencies and removing them one at a time, until only the RPCSS service and the NT LM Security Support Provider were left. The second one was the problem, it seems (the first one was already included)! I'm not sure if waiting for that service just delays the start of the service, but it seems likely that this service affects DCOM security.
0
 
LVL 3

Expert Comment

by:darinw
ID: 2771873
Moving question to PAQ.

-- I am accepting one of fjuk's comment as an answer --

darinw
Customer Service
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Unlike C#, C++ doesn't have native support for sealing classes (so they cannot be sub-classed). At the cost of a virtual base class pointer it is possible to implement a pseudo sealing mechanism The trick is to virtually inherit from a base class…
Written by John Humphreys C++ Threading and the POSIX Library This article will cover the basic information that you need to know in order to make use of the POSIX threading library available for C and C++ on UNIX and most Linux systems.   [s…
The viewer will learn how to pass data into a function in C++. This is one step further in using functions. Instead of only printing text onto the console, the function will be able to perform calculations with argumentents given by the user.
The viewer will learn how to clear a vector as well as how to detect empty vectors in C++.

671 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question