Go Premium for a chance to win a PS4. Enter to Win

x
?
Solved

CoCreateInstanceEx hangs with service on Automatic

Posted on 2000-03-22
14
Medium Priority
?
506 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
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
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 

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

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

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

IntroductionThis article is the second in a three part article series on the Visual Studio 2008 Debugger.  It provides tips in setting and using breakpoints. If not familiar with this debugger, you can find a basic introduction in the EE article loc…
Many modern programming languages support the concept of a property -- a class member that combines characteristics of both a data member and a method.  These are sometimes called "smart fields" because you can add logic that is applied automaticall…
The goal of the video will be to teach the user the concept of local variables and scope. An example of a locally defined variable will be given as well as an explanation of what scope is in C++. The local variable and concept of scope will be relat…
The viewer will learn additional member functions of the vector class. Specifically, the capacity and swap member functions will be introduced.

879 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