Event ID/Source search
Keyword searchExample: Windows cannot unload your registry file
Event ID: 10009 Source: DCOM
|Maintenance: Recommended maintenance tasks for Windows servers|
DCOM was unable to communicate with the computer <computer name> using any of the configured protocols.
|English: This information is only available to subscribers. An example of English, please!|
|Concepts to understand:|
What is DCOM?
|Our approach: This information is only available to subscribers. An example of Our approach|
Service: MSSQL$BKUPEXEC, OS: Windows SBS 2008 SP2, Software: Backup Exec 2010
Just removed Library Validation Code value from registry.
I was getting this once or twice a minute. The cause was the server running Spiceworks Network Monitor and one of the servers in the lest to be monitored had been decommissioned. Resolution was to remove the device from the monitor.
EV100587 (How to troubleshoot DCOM 10009 error logged in system event?) blog article from Microsoft's Development team provides details on why is this event recorded and how to troubleshoot it.
For me, this was an issue with an improperly decommissioned CA server. The solution is to go into the ADSIEdit and delete the old CA server from the various Public Key Services.
We tracked this error back to a pair of scheduled discovery tasks for N-Able (a remote management and monitoring software). The jobs ran at 10 am and 4 pm and would fill the system log for about twenty minutes. We removed the discovery jobs and the problem and error messages have gone.
I integrated a NAS (Synology DS1513+) into our domain on SBS 2011. The message started appearing right after that every 30 minutes, 6 times in a row each.
The domain server tried to apply group policies to the NAS (which it could not handle, since it's OS - SAMBA - seems to not support it).
Moving the "Computer" (the NAS entry) from the MyBusniess Computers list in the AD to the Computers list right "under" the domain fixed the issue.
This error appear if installed ESET Remote Administrator Server. Please, try this solution - Run ESET Remote Administrator Maintenance Tool - Next - Next - Stop ERA Server Service.
I was getting this error after SBS2003 to SBS2008 migration. Follwed the advice by Adam Lewandowski (see below), however I was still getting it for 1 specific machine. After trying to ping the machine I noticed it was responding even though it was no longer attached to the network.
Issue turned out to be caused by an old DNS entry which was pointing to the machine even though it was no longer present, same IP address was also being assigned to another machine still on the network. Deleted the DNS record for old machine which resolved the issue.
Removing old entries in the DNS helped me getting rid of this event. I also enabled dynamic updates for the DNS-Zones, which was disabled by default on our SBS 2008.
There was a computer in our DNS we didn't use. It had the same ip address assigned as another computer that was being used. So the server tried to contact the computer with a wrong name and the result of this was the error. It showed up like 6 times in a row. After removing this Record from the DNS the error didn't show up anymore.
On SBS 2008 it is a common message after install/upgrade, and is related to flawed firewall policies. See ME957713.
I had this error along with the event id 10006 from DCOM (also an error). I removed HP software and the errors stopped.
On SBS 2003 Premium (ISA), this event is logged when the message tracking tool of System Manager for Exchange 2003 attempts to track messages outside the SBS domain.
T940601 says that the network might not be configured properly and that one should check the list of RPC protocol sequences in the registry.
ME245197 indicates that to connect to a DCOM server on Windows 2000 and Windows XP, there must be at least one common connection-oriented protocol between the client and DCOM server. The solution is to make sure that connection-oriented protocols are in the DCOM protocols tab. Remove any of the Datagram protocols from DCOM protocols tab. See the article for more details.
If the computer listed in the event is running Cisco Call Manager see EV100093 (DCOM Unable to Communicate with Cisco CallManager).
I was experiencing random connection problems on the clients such as slow or no connections to mapped network shares. Event id 10009 kept being recorded in the domain controller logs. It turned out that the culprit was a defective server network card. I was able to isolate the problem because the server was freshly connected to the network just as the first log entries were made. The defective server had no workload by itself, just a blank Windows 2008 R2. I still have to review what kind of traffic the defective server sent into the net to block it. Unplugged the server problem was instantly gone.
In my case, it turned out that this was caused by a Brother printer. I removed the printers and the ports and the problem was solved.
The first obvious thing to check is your name resolution (such as DNS).
I had this happen to a few of my workstations. In my case the only fix was to change the RpcSs key :
Windows Registry Editor Version 5.00
Note: Please backup the registry before making any changes to it.
I also had to remove the kernel and hal switches from the boot.ini (and reboot) and make sure the machine is pulling from an accurate AD Time source (make sure you PDC times are sync-ed).
In my case, it was caused by an HP 1012 printer that was pointed to a computer no longer in the organization. Removing the printer removed the problem.
I second what Rafa C said (see the comment below). We had a XP PC with an attached HP Laserjet P1505 printer. Was logging DCOM 10009 events every few seconds. Removing and replacing the drivers with the latest version stopped it.
I was receiving this on an SBS 2008 server. See T774368.
As per Microsoft, make sure that connection-oriented protocols are in the DCOM protocols tab. Remove any of the Datagram protocols from DCOM protocols tab.
1. Bring up the Component Services Administrative tool. On the Start menu, point to Programs, Administrative Tools, and then click Component Services.
2. In the console tree of the Component Services Administrative tool, right-click the computer on which you want to configure the protocol, to bring up the context menu.
3. Click the Properties menu to bring up Computer Properties dialog box.
4. Click the Default Protocols tab.
5. If you have any of the Datagram protocols (UDP/IP or IPX) protocols listed here, click to select, and then click Remove.
6. If you do not have any of the connection-oriented protocols in the list, click Add to bring up Select DCOM protocol and endpoint dialog box.
7. Choose Connection-oriented TCP/IP Protocol as the protocol sequence, and then click OK.
8. Add any or all of the connection-oriented protocols to the default protocols this way.
9. Move Connection-oriented TCP/IP Protocol to the top of the list.
10. Restart the computer for the changes to take effect.
also Check the network connections. Check the Registry under HKEY Local Machine/Software/Microsoft/RPC/DCOM Protocols for the list of RPC protocol sequences.
I had this on Windows 2008 Server, one of the techs who was logged in and managing Hyper-V had listed a server that existed in a different domain. Removing the server from the Hyper-V MMC resolved the issue.
Government IT Guy
The problem, for us, was related to Dell IT Assistant. The DCOM errors would flood the Event Viewer during the scheduled "Discover" period. when IT Assistant wouldn't find a computer listed at the IP address, it would generate a DCOM error.
In my case, I had a script system that would fire once every 24 hours that was consolidating, emailing event log reports and then deleting the application and system event logs (utilizing WMIC calls to ClearEventLog). We recently decommissioned a server and that is when the subject event started happening, once every 24 hours. When I deleted the non-existent server from my script system, the event no longer occurred.
On a Win2K Dell server running Dell's IT Assistant the error was caused by a user ID in the Discovery configuration. After the user's password had expired, the errors would occur every time discovery was run. I corrected the problem by replacing the User credentials with an administrative id with a static password.
This event occurred in conjunction with EventID 0 from source IT Assistant.
In my case on a Small Business Server 2003 R2 SP2 with ISA Server 2004 apart from receiving this event, when I used WMI tools from the server, I would receive the error: "RPC Server unavailable Code 0x800706BA". See ISA Server Management -> Firewall Policy (Task) -> Edit System Policy -> Authentication Services, and uncheck "Enforce strict RPC compliance". Now WMI can use the correct authentication.
In our case, we found the problem to be the HP Laserjet 1012 printer driver. After uninstalling the driver, the errors stopped. We have two systems with the same print driver and both had the same errors. On the unit with Windows XP the error was devastating. The other PC had Windows 2000 and was not adversely affected by the faulty driver.
In my case, one problem was a printer port (tcp) which pointed to an IP address which did not exist anymore. After removing the printer port, some events disappeared. The secong problem was that a client in my anti-virus program did not exist anymore. After removing this client, this event no longer appeared.
According to ME821546, this problem has been identified as an issue that affects Visual Basic 6.0 n-Tier applications that are using COM+ packages that have been exported as an "Application Proxy" and installed on a client "Citrix" server. The "Authenticated Users" group must be given the "Impersonate a client after authentication" user right. This can be achieved in Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment.
Without the right the "Services.exe" process (which runs the COM+/DCOM sub system) will start to eat up Non-Paged Pool memory until it is gone, causing the Server to quit responding. This error is logged to the system event log.
To resolve this issue, identify the user account that is used to run the AFS Packages, and then assign the "Impersonate a client after authentication" user right to that user account. To do this, follow these steps:
1. Click Start, point to Programs, point to Administrative Tools, and then click Local Security Policy.
2. Expand Local Policies, and then click User Rights Assignment.
3. In the right pane, double-click Impersonate a client after authentication.
4. In the Local Security Policy Setting dialog box, click Add.
5. In the Select Users or Group dialog box, click the user account that you want to add, click Add, and then click OK. (Adding the user group "Authenticated Users" fixed our issue.
6. Click OK.
The network connections might not be configured properly. Check the network connections. Check the "HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Rpc/DCOM_Protocols" registry entry for the list of Remote Procedure Call (RPC) service protocol sequences.
In my case, this started happening after installing HP Insight Manager. The Autodiscovery included dhcp clients in the network so I changed this in the autodiscovery IP address range and removed all workstations from the HP Insight database as I will only be monitoring servers/printers/switches.
The culprit, in my case, was Microsoft SQL Server Management Studio. Any registration of an unreachable SQL Server (in my Registered Servers) produced two of these events on startup. Deleted the dead server registrations and have had no occurrences of this event since.
My issue was related to a mapped printer to a no longer existing PC. I removed the printer object and the errors have ceased.
A Windows XP PC had been renamed. Re-installing Symantec Client Security v2.05 fixed the problem.
In my case, this event occurred after adding a HP laserjet printer. The solution provided by HP's website did not work. This problem was caused by the "System Restore" feature. Disabling it solved the problem.
This error can occur when an IISRESET command is issued without the "/" character in front of an option.
See ME910695 for a hotfix applicable to Microsoft COM+ 1.5, when used with Microsoft Windows Server 2003.
If Distributed Component Object Model (DCOM) calls are made between two COM+ server applications on two different computers under heavy load, the COM+ applications may consume all available client ports between 1024 and 5000 and cause high CPU utilization. Under these conditions, this event might be logged. See ME290512 to fix this problem.
In my case, this error occurred after renaming an HP ProLiant server. The error message referred to the old name, which was no longer on the network. At every 1, 10, and 40 minutes past each hour, the event would be logged. I finally diagnosed it by shutting down the HP Insight Agents, at which time it stopped. A reinstall of the HP Insight Management Agents and deletion of the hostGUID key under HKLM\Software\Compaq Insight Agent resolved the issue.
The user is working at a new location. Event 10009 popped up every 5 seconds at the new office. He had a Lexmark X5 printer mapped to another user's PC from the old workplace. When we removed the printer and the driver (in the Server menu right click in Printer and Faxes and select Server, then the Drivers tab), the error went away.
After a few days of repetitive DCOM 10009 errors, we found the client machine was infected with a virus. After removal, lower RPC connections were made by the client and no more errors 10009 returned. Just try a simple virus scan first if anything.
I found this event after installing Windows 2003 SP1 and updates. My websites were getting an "access denied" error message when opening a remote activated DCOM component in the web browser. Eventualy, I found that the premissions on the server object were changed in DCOMcnfg. I changed it back to Local and Remote Execution and Activation and the problem was solved.
See ME305030, ME823159, and ME884564 for information on how to fix this problem.
From a newsgroup post: "With some help from Filemon from Sysinternals, I spotted that EMSMTA was being called immediately before the log file was being written to. Smells suspiciously that Exchange is where I need to point the blow torch. After that focus it only took a few minutes of drilling down through every leaf and examining every property panel to discover that Exchange IM was set to use the absent anubis (the <computer name> in the event message in my case) as its proxy". Filemon and Regmon have both been replaced by Process Monitor (see TB896645 for download).
If you are having problems deploying Client Exec clients, read EV100092 - "Veritas Support Document ID: 184799" for information on fixing the problem.
The network connections might not be configured properly. See MSW2KDB for additional information on this event.
In my case, this error was not DCOM related at all, but was instead a switch/cabling problem. One of the four teamed HP NICS on the server was plugged into a misconfigured port on the switch. If a connection used the NIC connected to the bad port, it produced DCOM errors until the cached ARP entries for that NIC timed out. Reconfiguring the port on the switch fixed the problem.
In my case, the error was occurring with high frequency on a Windows Server 2003 Standard running SMS 2003. I looked in the event log and found that the errors began when I installed Microsoft SMS Client Health Tool. I removed that program and the errors ceased to appear.
In my case, this problem occurred between two Windows 2000 Professional SP4 workstations and an HP Print Server Appliance 4200, which is joined to a Windows 2000 AD Domain. HP LaserJet 1320 Toolbox miss-registered itself during standard install, caused two DCOM errors every 35 seconds.
To fix the problem, at a command window from the directory \windows\system32 run the command:
If the problem persists then run the following command:
See EV100091 - "HP LaserJet and LaserJet AiO Printers - DCOM Error Message" for additional information on this problem.
In my case, the problem was caused by a connection problem between a DC and Exchange server. The problem was solved by setting the registry key MaxTokenSize to 12000 decimal in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters.
I encountered this event during various updates and deployments of Hummingbird DM 5.1.x.x. The symptom is that after a patch, update or installing a custom deployment package, this error will occur roughly every 10 seconds in the system event log. One fix for this issue is to check the cluster settings for Hummingbird. Under the registry key HKLM\Software\Hummingbird\Clusters, check the values of “Server List". In my case, a recent install had inserted a bogus character. This meant that the program would poll a server that didn't exist. After clearing extraneous entries, the DCOM error went away.
If a Windows XP SP2 computer is involved, modify the firewall settings to allow for DCOM access. Refer to article ME840634 for details on this issue.
I had this error on a Windows XP SP2 machine after I installed the driver and tool package for the connected printer HP1320n. The installation package includes a tool named HP Toolbox or alike. I found the error with "Process Explorer" from Sysinternals. A process named HPBPro.exe cause high system load, up to 100% every few minutes. I searched on Google and found that I am not the only one who had this problem. After I uninstalled the HP Printer Driver and Toolbox, I got rid of this annoying error. See EV100090 - "HP Forum - HPBPRO.EXE killing my server" for further information on this issue.
From a newsgroup post: "When I use the Message Tracking Center in Exchange I see all handled messages. When I double click on a message, I see all the message events and the tree. DCOM then tries to connect to the sever where the message has been transferred to, like the SMTP server from you ISP. But the server does not accept this kind of traffic, like RCP". This results in the event 10009 being logged. I think that in this particular case event 10009 can be ignored. I encountered this event with Message Tracking on SBS 2000. See EV100089 for the original post.
This error is also related with a DCOM/COM+ bug not releasing (consuming) TCP ports between 1024 and 5000 range under heavy load. This problem was first corrected in Win2k SP 2. More information can be found in ME290512.
As per Microsoft: "Component Services Administrative tool or DCOMCNFG incorrectly allows you to add Datagram User Datagram Protocol/Internet Protocol (UDP/IP) and Datagram Internet packet exchange (IPX) protocols to the Default Protocols tab. Windows 2000 does not support any datagram protocols. " See the links below for more details.
|Private comment: Subscribers only. See example of private comment|
|Links: EventID 0 from source IT ASSISTANT|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
|Custom search for *****: Google - Bing - Microsoft - Yahoo|
Send comments or solutions
- Notify me when updated