fjuk
asked on
CoCreateInstanceEx hangs with service on Automatic
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?
I agree with yarond, However check this
Article ID: Q165300 in MSDN, this is a accepted bug from Microsoft.
rgds.
Article ID: Q165300 in MSDN, this is a accepted bug from Microsoft.
rgds.
ASKER
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.
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.
ASKER
Adjusted points from 200 to 250
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\SOFTWAR
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...
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\SOFTWAR
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...
ASKER
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.
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.
ASKER
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.
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.
ASKER
Adjusted points from 250 to 300
ASKER
It is not a PDC and not a BDC.
It is a NT Server machine, with NT service pack 6a.
It is a NT Server machine, with NT service pack 6a.
ASKER
It is not a PDC and not a BDC.
It is a NT Server machine, with NT service pack 6a.
It is a NT Server machine, with NT service pack 6a.
ASKER
It is not a PDC and not a BDC.
It is a NT Server machine, with NT service pack 6a.
It is a NT Server machine, with NT service pack 6a.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Moving question to PAQ.
-- I am accepting one of fjuk's comment as an answer --
darinw
Customer Service
-- I am accepting one of fjuk's comment as an answer --
darinw
Customer Service
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.