How to troubleshoot DCOM 10009 error logged in system event?



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:        Error
Event Source:    DCOM|
Event Category:                None
Event ID:              10009
Date:                     2010-2-22
Time:                     10:02:07
User:                     N/A
Computer:          <Computer Name>
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>.

How this happens:


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

Why this happens:


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.

  • Scenario 1:
     The remote target server happens to be offline for a short time, for example, just for maintenance.
  • Scenario 2:
    Both servers are online. However, there RPC communication issue exists between these two servers, for example:  server name resolvation failure, port resources for RPC communication exhaustion, firewall configuration.
  • Scenario 3:

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.

  • Scenario 4:

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.


How to troubleshoot:


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.

  • ·         For scenario 1
    if DCOM 10009 is logged during the period of maintenance of   remote target server, it’s an expected behaviour because the remote target server is offline. We can verify it by ping <remote server>
  • ·         For Scenario 2
    If the remote target server is online while DCOM 10009 is still logged, then we can perform below tests:

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:

netstat –anb

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 tool

Note: DTCPing tool is not specific for troubleshooting MSDTC issue, it can be used to troubleshooting all DCOM communication issues.

    • For scenario 3:
      Need capture more resources like Network traffic, or even iDNA trace to further investigate how this failu
      re happens.
    • For scenario 4:

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

Winston from APGC DSI Team 

Comments (21)

  1. Ritesh says:

    Awesome Article …..

    Thanks for sharing this and in such a gud language ,

    Keep posting

  2. Hayden Hancock says:

    My event is logged because we removed the server from our rack. How do I stop this event from logging?

  3. Winston says:

    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.

  4. Aamer says:

    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.

  5. 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.

  6. Brian says:

    All my DCOM error messages are coming from Non-windows machines, anyone have this problem: All events are logged on the domain controller:

  7. Winston from DSI team says:

    To Brian:

    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.

  8. Danie de Wet says:

    Many thanks for sharing knowledge in down to earth explanation!!

  9. Salomon says:

    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.


  10. Eric Mack says:

    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.

  11. Scott5297 says:

    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.

  12. شبکه سیویل ایران says:

    سلام شارژ اینترنت پر سرعت من که از "آسیاتک‏"‏ دفتر شعبه آمل آدرس جدید میدان ۱۷ شهریور تغدیه می شود تمام شده و حالا که برای ورود به سیستم AsiaTech QuickTask اقدام کردم ارور زیر دریافت کردم:

    Important server error

    بروز خطا در سیستم لطفا پس از کنترل اطلاعات مجددا سعی کنید

    There is a problem with the resource you are looking for, and it cannot be displayed.

    آدرس صفحه حاوی ارور:…/quicktask_main_page.asp

  13. mazandaran says:

    Why my Translate Microsoft don't exist in all blogs msdn?

  14. MJ Almassud says:


    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.

    any ideas?

  15. Winston He says:

    @MJ Almassud

    There must be an process or service which is sending DCOM call to the non-existing machine, so you need to find out that process name. Regarding how to find out the exact process , you can get help from Microsoft support.

  16. Asiatech says:

    <a href=''>پنل کاربری آسیاتک</a>

  17. Frank says:

    Problem is that it is trying to connect to itself with the wrong dns name.

    How to fix this?

  18. Turbocutt says:

    Hello guys,

    I have a same issue "DCOM was unable to communicate with the computer "Computer_name" using any of the configured protocol" I'm working on a Citrix XenApp 6.5 farm application. Anyone experiencing the same issue, please help :), all services needed is up and running, i know its more of a Citrix issue but just to share and seek some help.

  19. jerald white says:

    I have a DCOM problem and the event code is 10016. What does the code mean and how to troubleshoot the problem?

  20. Jens says:

    Hello all, i was having this error – DCOM trying to contact a non-existent server – more specifically, a server that i used temporarily for a swing migration of SBS.
    I couldn’t find the server name anywhere in the registry or otherwise – that is until i stumbled upon it in “Active Directory Certificate Services” > “Issued Certificates”. I revoked the certifiacate and the error is gone.

Skip to main content