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

[Batu69]

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.

 

Article source

[Pete 12]

This works indeed , on Win10 also...............