Share via


DisturbedCOM server permission issues.

Question

Thursday, February 22, 2018 7:48 PM

For the last 2 to 4 months I keep seeing this error in my windows event viewer. I have found several guides that explain how to fix it and it's a permissions issue that started in the Windows 10 Creators update. While I have no problem logging in as the actual administrator account on my Windows 10 Pro 64-bit machine. I was wondering if anyone at Microsoft has taken the time to fix this error instead of leaving it to the user to fix it themselves. And since it's a bug in the creator's update, is Microsoft planning to push a patch out for this bug and if not, how can I go about fixing this error?

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID 
{D63B10C5-BB46-4990-A94F-E40B9D520160}
 and APPID 
{9CA88EE3-ACB7-47C8-AFC4-AB702511C276}
 to the user THEWHITEYETI\Josh SID (S-1-5-21-3039536190-1026040076-826494673-1001) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

All replies (12)

Friday, February 23, 2018 8:10 AM

Hi,

According to Microsoft13, this issue occurs because certain processes do not have permissions to the DCOM components that are mentioned in the event logs.

You can prevent the events from being logged, using these instructions to grant permission to the DCOM components that have specific CLSIDs and APPIDs: the steps in the link below.

http://www.itexperience.net/2017/01/13/event-id-10016-fix-the-application-specific-permission-settings-do-not-grant-local-activation-permission-for-the-com-server-application-with-clsid/

I always meet the event id in event viewer. Although these event logs can be safely ignored. I’m afraid that what we're going to do now is manually giving it permission.

Also try the built-in "Feedback" tool to submit the issue on your side to help improve future releases.

Hope it will be helpful to you

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].


Friday, February 23, 2018 8:57 PM

This is a serious issue for me. I initially had unexpected freeze ups. Now I have complete shutdowns. No warning, no bluescreen. 


Friday, February 23, 2018 9:08 PM

Does Microsoft even know this is a real issue and are they planning to push a patch for it? 


Wednesday, March 7, 2018 7:37 AM

Hi,

Yes, this is a known issue and please see following contents to know details:

These 10016 events are recorded when Microsoft components tries to access DCOM components without the required permissions. In this case, this is expected and by design.

A coding pattern has been implemented where the code first tries to access the DCOM components with one set of parameters. If the first attempt is unsuccessful, it tries again with another set of parameters. The reason why it does not skip the first attempt is because there are scenarios where it can succeed. In those scenarios, that is preferable.

These events can be safely ignored because they do not adversely affect functionality and are by design.

To prevent the events from being logged, follow these steps to grant permission to the DCOM components that have specific CLSIDs and APPIDs.

Note You can find the CLSID and APPID in the event log entry.

  1. Start Registry Editor (regedit).

  2. Locate the following registry subkey:

    HKEY_CLASSES_ROOT\CLSID\<Target AppID>

  3. Right-click the subkey, and then click Permissions.

  4. Click Advanced.

  5. Click Add.

  6. Click** Select a principal.**

  7. In the Select User or Group dialog box, enter the appropriate administrators group in the Enter the object name to select box. For example, enter <ComputerName>\Administrators.

  8. Click OK.

  9. On the Security tab, grant Full Control, and then click OK.

  10. Exit Registry Editor.

  11. Start DCOM Config (dcomcnfg).

  12. Expand Component Services >** Computers** >** My Computer **> DCOM Config.

  13. Right-click the application that corresponds to the AppID that's recorded in the event log, and then select Properties.

  14. Select the Security tab.

  15. In the Launch and Activation Permissions area, select the Customize option, and then select Edit.

  16. Under Group or user names, select Add.

  17. Enter the group or user name that's recorded in the event log.

  18. Click OK.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].


Wednesday, March 7, 2018 7:39 AM

Do I have to <g class="gr_ gr_57 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling multiReplace" data-gr-id="57" id="57">login</g> to the admin account to fix this issue? And is Microsoft gonna deploy a patch at some point soon? 


Wednesday, March 7, 2018 7:52 AM

I recommend that we just ignore since it will not affect your daily using of this computer. For your current situation, this is expected and by design.

See the cause for this issue: 

"A coding pattern has been implemented where the code first tries to access the DCOM components with one set of parameters. If the first attempt is unsuccessful, it tries again with another set of parameters. The reason why it does not skip the first attempt is because there are scenarios where it can succeed. In those scenarios, that is preferable.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].


Wednesday, March 7, 2018 8:06 AM

I think it's somehow affecting my audio gear to a degree. I am not too sure.


Wednesday, March 7, 2018 8:53 AM

Hi, 

The appID in your event stands for Runtimebroker, please know that Runtime Broker is an official Microsoft core process that debuted in Windows 8 and continues in Windows 10. It is used to determine whether universal apps you got from the Windows Store–which were called Metro apps in Windows 8–are declaring all of their permissions, like being able to access your location or microphone. Though it runs in the background all the time, you will likely see its activity rise when you launch a universal app. You can think of it like a middleman hooking your universal apps with the trust and privacy settings you’ve configured.

It will not affect your audio performance. 

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].


Thursday, July 12, 2018 2:27 AM

It can be safely ignored?Well why is it a critical alert in the system logs? What does CRITICAL mean?

I guess it is ONLY critical for 1% of users so screw them?

Like the other users my machine is not stable with poor performance. This may be a cause. Given that this issue is CRITICAL I'm focusing on it as a possible cause.

Patches? Well clearly not so far. The patch is a giant finger ;)


Saturday, November 3, 2018 10:02 PM

I can more or less confirm that you're correct about that assumption. The 'Unknown Account' seems persistent, adding itself back if removed from registry permissions, and I'm willing to bet my mistake was removing this account from the DCOM configuration for the component's launch/activation permissions. 

I currently have no sound whatsoever. I'm attempting to fight with this issue now... I'm not the type to resort to a system restore over something seemingly minor (though maybe not so minor). But yes, what little information I've gathered so far, Runtime Broker is linked to far more than just that one simple CLSID and AppID... and whatever I've done has caused multiple other AppID's to fail when attempting to register themselves with the DCOM server. 

Not only that, but the corrective action to restart the service is even more peculiar... as the services are all already running... 

If you want to alleviate this error in your event logs, it's best to simply turn off the listener for it... there are instructions on how to do this through the registry, probably in this same thread. 


Tuesday, November 27, 2018 3:55 PM

I find it funny that M$ says you should use regedit to fix things.....

This happens on Server 2016 also.  REGEDIT is NEVER a fix....... Fix Windows!

If I need regedit, I go back to Linux


Tuesday, February 19, 2019 12:47 AM

Actually none of that works!  It can't be found in the registry as you claim, and the dcomcnfg program will not allow edits even when launched as administrator !!!!!

Please provide working fixes in the future, or at least how to accomplish what you offer as a fix.