DCOM Server failed to register

Question

Hi, I am getting this error

Source : DCOM
Event_ID: 10010

"The server {6FC4FDAE-96C8-11D3-9F9C-005004053207} did not register with DCOM within the required timeout."

This is for a particular exe which when run as local system works fine but when run under an non- builtin administrator fails. I need the exe to run under the non - built in administrator.

Presently I am getting this issue on a Win 2k3 machine with Citrix.

However I also faced this issue on an XP machine before.

Any tips on solving the issue?

Answer 1

Permissions issues when using DCOM can make you miserable... They fall between the system administrator and the programmer, and until one knows enough about the other's part they can be quite hard to overcome.

As for your particular problem, the cause of this error message is a too long server startup, delaying the call to CoRegisterClassObject till after the timeout expires. I would look for the cause of the problem in your server startup before I'd look into COM. Check any initializations you do (global variables constructors etc.) and make sure no exception is thrown or so. A change of user can cause some directories or registry hives to become inaccessible, possibly breaking the initialization.

What I would do is first monitor the server activity using ProcMon. This would make it easy to find any access denied problems, as well as show you the relevant the stack trace. If a debug is needed, you can have the debugger attached as soon as the exe is launched following these instructions. Finally, if the problem occurs on a machine without VS, you can use WinDBG instead to debug the process.

Answer 2

As I don't completely understand the context... Here are a few tips to help you solve problems... It helps to have admin rights on both originating and target computers....(at least to configure and inspect)

DCOM can be bewildering. When dealing with DCOM across machine boundaries the problem is most likely to be security from Conflicting and/or no Credentials, firewalls, and DCOM settings for the local machine and application. As far as the 80/20 principle goes...here are some simple rules to get you in the ballpark.

First, make security visible: Fire Up SecPol.MSC on your originating machine, locate Local Policies/Audit Policy and turn up auditing on every event type. You'd do well to do it on the target machine.

Crank Up DCOM event logging as well. Follow these directions http://support.microsoft.com/kb/892500

Second, change a default workgroup setting known to stomp all over DCOM.. Insure that Simple File Sharing (also known guest only authentication) is disabled on both originating and target computers. If both are in a domain, then it is likely disabled. Otherwise... secpol.msc\security settings\security options\network access: Sharing as security model for local accounts (set to classic)

Third, get a grasp on the security required...

If both machines are in different domains or one (or both is in a workgroup) understand the required common security; that is, credentials must be common or synchronized on each machine. That is, for the login running the process on the originating machine, identical credentials must exist on the target computer. For both in the same domain, worry not as the domain based credentials for one machine will be the same as the other.

Fourth, get the firewall out of the way if you can.

Temporarily disable it..but only if it is safe. Otherwise, assume for netbios ports and your applications by exename (135/139udp). The ports used are an assumption; i.e. this may not be right.

Fifth, before it gets too complex... Simply attempt to induce the error (run the program) and review the system and security logs on both machines. If it is a security problem it will stick out like a sore thumb and you can adjust accordingly.

If not, dcomcnfg will be your friend. DCOM settings for a particular component resolve in the following precidence: CODE EXECUTED, PROGRAM SETTINGS, and DEFAULT MACHINE SETTINGS. Dcomcnfg will help you resolve the latter two. You can find some more specific (but simplified) directions at http://www.opcfoundation.org/DownloadFile.aspx?RI=326

Followup if you get stuck....

Answer 3

In my case the XP on my machine was was modified by my company's IT guys. So they had by some group policy, denied access to certain DCOM settings even for Administrator Group.

The workaround was to manually register the DCOM servers in a command prompt opened with the credentials of the built-in Administrator account.