Fix for Event ID error 10016: DCOM server not having Local Activation permissions for PCNAME\Username SID

Recently, on my Windows 8.1 PC, out of nowhere, I started getting errors in the Event Log after installing updates on a Patch Tuesday. The error was related to Distributed COM (DCOM):

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {9E175B6D-F52A-11D8-B9A5-505054503030} and APPID {9E175B9C-F52A-11D8-B9A5-505054503030} to the user PCNAME\Username SID S-1-5-21-81864976-3388411891-1937036257-1001 from address LocalHost (Using LRPC) running in the application container Unavailable SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394). This security permission can be modified using the Component Services administrative tool.

Such a complicated error might make inexperienced users throw up in frustration. They are unfamiliar with this terminology. Plus, troubleshooting DCOM errors is a pain so I ignored it at first but the event log was full of them as it occurred every hour or so. Determined to fix it, I decided to investigate.

For those of you who don't know, COM is Microsoft's old object-oriented inter-process communication technology. A COM server is an executable (EXE or DLL) that implements a set of COM objects. Many Windows components are implemented as COM objects and follow standard COM rules to communicate with one another. COM servers are registered in the Registry and have a Class ID (CLSID) and an APPID.

The first step to troubleshoot this error was finding out which DCOM component the CLSID and APPID were related to. So fire up the Registry Editor and go to this Registry key:

HKEY_CLASSES_ROOT\CLSID\{9E175B6D-F52A-11D8-B9A5-505054503030}

This Registry key also points to the same AppID as the error message which is {9E175B9C-F52A-11D8-B9A5-505054503030}. So, next go to

HKCR\APPID\{9E175B9C-F52A-11D8-B9A5-505054503030}

This told me that the component was WSearch (a Windows Search COM object).

The next step was to assign to this CLSID/AppID, the correct local activation permissions that it wanted - of my user Security ID (SID) and the app SID. To do that, Windows provides a Component Services tool which lets the user modify launch and activation permissions, access permissions and configuration permissions on COM servers.

Open Administrative Tools -> Component Services. Expand Component Services -> Computer -> My Computer -> DCOM Config. Locate 'WSearch' and right click it -> Properties. Go to the "Security" tab.

Upon doing this, I saw that everything was greyed-out (disabled) on the Security tab for this COM object so I needed to give my user account full permissions in the Registry first. I opened Regedit again and went to the same key

HKEY_CLASSES_ROOT\AppID\{9E175B9C-F52A-11D8-B9A5-505054503030}

and changed the permissions. First you must take ownership (check 'Replace owner on subcontainers and objects'), and then add your username and give it Full Control. Afterwards, you can change the ownership back to the original account(NT Service\TrustedInstaller).

Taking ownership and giving admin permissions is extremely easy with Winaero's RegOwnershipEx app.

Now I re-opened the Component Services (Dcomcnfg.exe) and went to WSearch properties, Security tab and was now able to edit the Security permissions on Launch and Activation Permissions, which are shown like this:

Through the security group Everyone, my user account already has Local Activation permissions, but there are also 3 other SIDs shown which aren't known user accounts or groups as their icon indicates. They are Application SIDs and refer to Applications. The Event log error also said "... running in the application container Unavailable SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394).

Now the Windows object picker UI does not seem to let you add application SIDs for security principal objects. So after clicking Add, I clicked Advanced... and then Find Now. This will list all the objects. But most of them were account SIDs. I noticed "ALL APPLICATION PACKAGES" which as the name implies is probably a group for all application packages, so I selected it. Click OK everywhere to add it and then give it Local Launch and Local Activation permissions.

Now upon clicking OK and closing the Component Services UI, the error is gone from the Event Log which means the WSearch COM component now has the correct local launch and activation permissions.

I wrote this article as general guide to help anyone else troubleshoot DCOM errors in their Event Log in a similar way. I am still concerned why Windows does not have a tool yet to easily restore the correct permissions to COM objects in case they get messed up.

Support us

Winaero greatly relies on your support. You can help the site keep bringing you interesting and useful content and software by using these options:

If you like this article, please share it using the buttons below. It won't take a lot from you, but it will help us grow. Thanks for your support!

Author: Gaurav Kale

Gaurav is a software enthusiast from India and Classic Shell tester & UX consultant. He started with Windows 95 and is good at software usability testing. He firmly believes that user experience is just as important as software code quality and architecture for software to be successful.

6 thoughts on “Fix for Event ID error 10016: DCOM server not having Local Activation permissions for PCNAME\Username SID”

  1. Thanks for this useful guide, Sergey.

    I have a question (just to be sure doing it the right way) : when changing the ownership back to the original account (NT Service\TrustedInstaller), should I also check ‘Replace owner on subcontainers and objects’ ?

  2. Thank you for this guide.
    I have a enhancement for this. To find out which user belongs to the SID you can use the following Powershell Script:
    $objSID = New-Object System.Security.Principal.SecurityIdentifier `
    (“S-1-5-21-1454471165-1004335555-1606985555-5555”)
    $objUser = $objSID.Translate( [System.Security.Principal.NTAccount])
    $objUser.Value

    Kind Regards
    Randy

    1. You can also simply do
      Get-ADUser S-1-5-21-1454471165-1004335555-1606985555-5555

      Thanks for article! Always ignored these as per M$ article but glad I can resolve these now

  3. You usually only see error 10016 on a computer upgraded to Windows 10 and not on clean installs. It seems to be an inherited setting that the installer doesn’t overwrite.

Leave a Reply

Your email address will not be published.

Exit mobile version
Using Telegram? Subscribe to the blog channel!
Hello. Add your message here.