Puneet Gupta

Puneet Gupta

Coder. Works on Azure App Service, Diagnostics, debugging and other cool stuff

DCOM Error 10010 in the Event logs and SLUGGISH server performance

4 minute read

We have come across this specific issue on Windows 2003 (post service pack 1) and Windows XP (post service pack 2) where the machine experiences slow performance and we observe many DCOM 10010 ERRORS in the event logs. If you are running in to this issue, you may see some of the symptoms/errors listed below.

  • Doing anything takes forever. You click Start button and it responds to you after a minute (or may be more than that). Switching windows in the Taskbar takes very long.
  • If you have IIS installed on the server, the IIS related services may not start or may hang while starting. Typically these errors appear when you try to start them.
    • Trying to start the IISADMIN service throws an error - Windows Could not start the IIS Admin Service on Local Computer. For more information, review the system Event log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code –2147221164(0x80040154) or The IIS Admin Service service terminated with service-specific error 2147746132 (0x80040154).
    • If IISADMIN service is started, trying to start the World Wide Web Publishing Service hangs and the service goes into the Starting state and after some time it may throw the error - The World Wide Web Publishing Service service terminated with service-specific error 2148007941 (0x80080005)
  • While expanding COM+ Applications inside component services, you may get the below error
    • An error occurred while processing the last operation
    • Error code 8000FFF - Catastrophic failure
  • You observe many DCOM Errors 10010 in the event viewer (like this)
    • The server {BA126AD1-2166-11D1-B1D0-00805FC1270E} did not register with DCOM within the required timeout
    • The server {8BC3F05E-D86B-11D0-A075-00C04FB68820} did not register with DCOM within the required timeout

The interesting thing to note here is that most of the components which are failing or performing slowly are the basic system components only. The GUID {BA126AD1-2166-11D1-B1D0-00805FC1270E}  is the CLISID (class id) for Network Connection Manager Class and the GUID {8BC3F05E-D86B-11D0-A075-00C04FB68820} is the CLSID for WMI. The one big common thing between all these symptoms is that all the programs which exhibit the above symptoms are dependent on DCOM.

If you end up with the symptoms/errors listed above, one quick thing to check would be the permissions on the HKCR\CLSID registry key. By default this is how the permission on that key should look like.

image

If you are running into this issue, you will see that the USERS group is not listed in the ACL list for this registry key. You might see an account with the name RESTRICTED listed out there. To fix the problem, you can configure the ACLS on the HKCR\CLSID key in the default way. For Windows 2003, this is how the default permissions on the HKCR\CLSID should look like.

  • Administrators – FULL CONTROL
  • Power Users – READ
  • SYSTEM – FULL CONTROL
  • Users – READ

After making the registry change, you have to reboot the machine so that the programs can access the registry during the startup and hence function properly.

At this point, we haven't got a chance to determine the root cause of this problem. In other words, we don't know what particular action ends up removing the USERS group from the HKCR\CLSID registry key and we need your help in determining root cause. If you are able to reproduce this issue at your end, we will like to know the steps you took to reproduce this issue to figure out what CAUSES this and try to avoid it from occurring in the first place. Please feel free to post your comments at the end of this blog to let us know if you have a successful repro of this situation.

PLEASE NOTE : The permissions on the HKCR\CLSID may not be the only cause of the errors. The errors that are listed above are very generic errors and can come in a lot of situations. The purpose of this article is to eliminate one basic cause which we come across a lot of times. If fixing the permissions on the HKCR\CLSID and then rebooting the machine, doesn't fix the issue for you, we recommend you run the Process Monitor tool and look for any kind of registry level or file level access denied’s which are happening on the server.  Otherwise check out the following list of KB articles which may point more specifically to the issue that you are facing.

Updated:

Leave a comment

You may also enjoy