Sometimes, we may see below DCOM 10009 errors in our system event, or we may receive the exception code 0x800706ba in our DCOM client application:
Event Type: ErrorEvent Source: DCOM|Event Category: NoneEvent ID: 10009Date: 2010-2-22Time: 10:02:07User: N/AComputer: <Computer Name>Description: DCOM was unable to communicate with the computer <Target Computer Name> using any of the configured protocols.
Simply speaking, DCOM 10009 indicates that the DCOM client located on this <Computer Name> can’t communicate with the DCOM|COM+ server located on that <Target Computer Name>.
When a client calls CoGetClassObject or CoCreateInstance (CreateObject or new in VB) to activate a component, the COM runtime contacts its local SCM COM activator (RPCSS service) in order to launch the corresponding COM server that will host the desired component.
If the component is remote, the local RPCSS service will forward the request to the RPCSS service of the remote machine.
However, if the RPCSS service of remote target server is not available, DCOM 10009 will be logged locally to notify administrator. The typical call stack is as follows:ChildEBP RetAddr
006df364 757f8b72 ADVAPI32!ReportEventW-> then DCOM 10009 is logged.
006df3a0 757f6542 rpcss!LogRemoteSideUnavailable+0x63 ->here we don’t found the server.
006df40c 757f6781 rpcss!CRemoteMachine::Activate+0x294
006df648 757f6861 rpcss!RemoteActivationCall+0xf2
006df664 757edb5c rpcss!ActivateRemote+0x8e
006df6c0 757d629c rpcss!Activation+0x343
006df718 757d7680 rpcss!ActivateFromProperties+0x1c2
006df724 757d76c0 rpcss!CScmActivator::CreateInstance+0xd……
Totally speaking, the reason why DCOM 10009 is logged is that: local RPCSS service can’t reach the remote RPCSS service of remote target server. There are many possibilities which can cause this issue.
Even though the TCP connection to remote server has no any problem, but if the communication of RPC authentication gets problem, we may get the error status code like 0x80070721 which means “A security package specific error occurred” during the communication of RPC authentication, DCOM 10009 will also be logged on the client side.
The target DCOM |COM+ service failed to be activated due to permission issue. Under this kind of situation, DCOM 10027 will be logged on the server side at the same time.
As I mentioned above, there are many possibilities which can cause DCOM 10009 being logged. Some scenarios are normal while others are abnormal. We should deal with the DCOM 10009 in different ways.
1) Ping <remote server> & IP Address of remote server to make sure network traffic is fine.
2) Telnet <remote server> 135 to make sure the Port 135 is not blocked by firewall.
3) If we have configured dynamic port for RPC communication, we can check what status the port resources are on both servers using below command:
if all dynamic ports are used , or only few left, you can consider expanding the dynamic port.How to configure RPC dynamic port allocation to work with firewalls
DCOM port range configuration problems
4) If all above tests are fine, we can use DTCPing tool to verify if the DCOM communication between two servers is fine.How to troubleshoot connectivity issues in MS DTC by using the DTCPing toolhttp://support.microsoft.com/kb/918331/en-us
Note: DTCPing tool is not specific for troubleshooting MSDTC issue, it can be used to troubleshooting all DCOM communication issues.
Grant the specific account mentioned in DCOM event 10027 with corresponding permission through “Component Services MMC”
FIX: You cannot obtain detailed error information about DCOM 10009 errors in Windows Server 2003 http://support.microsoft.com/kb/910695
Winston from APGC DSI Team
Awesome Article .....
Thanks for sharing this and in such a gud language ,
My event is logged because we removed the server from our rack. How do I stop this event from logging?
you need to find out the process who is always trying to send out DCOM request where the target server doesn't exists any more, and stop it. This could be implemented by the configuration of that application, I think.
We have these DCOM 10009 Events filling up event logs after removing a server from the network. What we did was added another server by the same name. Expectation is that the new server (with same name as old) should be looked up.
But we continue to get the events. So how should I be fixing this error? I guess I'll need to find the application that seems to be making calls to the non-existant server name.
Aamer, right. You need to find out which application raised the call on this machine. You can check with application team, or run Network Monitor and Process Monitor, look at which process keeps sending failured RPC requests.
All my DCOM error messages are coming from Non-windows machines, anyone have this problem: All events are logged on the domain controller:
It could be caused that there is a kind of monitoring tool which scans those unreachable machines among this domain. you need to capture network traffic when the issue happens for further clarification, or TTT trace for deep analysis if needed to find out which process is sending out such DCOM request.
Many thanks for sharing knowledge in down to earth explanation!!
Good point to start. In my case, pinging to the IP address and name resolution were ok. When I tried to connect to the services console on the remote, access was denied...
And then I found the issue:
There was a HOST(A) record on the DNS, but the actual computer had a different name. I removed the bogus record from the DNS and now there is no more errors.
The target PC had a bogus A record in DNS that would respond to ping, but obviously was not the correct PC (this corrected two of the 10009 errors). Not sure why the DNS got the incorrect records. Thank you for the ideas on where to start looking for this - it was a little frustrating.
I had this on a SBS 2011 domain. After upgrading the workstations to Windows 7 and renaming them, the DNS records got mixed up. DNS records of the old workstations were still present. But the new workstations were given IP addresses that had been used by the old DNS records.
So, the IP addresses of some of the workstations were correlated to the incorrect (old) host names.
The resolution was to delete the incorrect DNS records and reload the zone.
The clue to it being a DNS problem was that DCOM was trying to connect to workstations that had been removed from the network. Those removed workstations still had DNS entries at the time.
سلام شارژ اینترنت پر سرعت من که از "آسیاتک" دفتر شعبه آمل آدرس جدید میدان ۱۷ شهریور تغدیه می شود تمام شده و حالا که برای ورود به سیستم AsiaTech QuickTask اقدام کردم ارور زیر دریافت کردم:
Important server error
بروز خطا در سیستم لطفا پس از کنترل اطلاعات مجددا سعی کنید
There is a problem with the resource you are looking for, and it cannot be displayed.
آدرس صفحه حاوی ارور:
Why my Translate Microsoft don't exist in all blogs msdn?
I am getting this event but the server it's trying to communicate with does not exit on the network anymore, and I also don't know why is it trying to communicate with it.