Share via

Event ID 10016 - The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID

Question

Tuesday, August 4, 2015 9:07 AM | 7 votes

Hello,

After my Windows 10 upgrade i see this well-known DCOM Event-ID 10016 in the event viewer:

"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 NT AUTHORITY\SYSTEM SID (S-1-5-18) 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."

It is from the Runtimebroker.exe - i know this error was in Windows 8.1 and below, too in the past ->

http://answers.microsoft.com/en-us/windows/forum/windows_8-performance/event-id-10016-the-application-specific-permission/9ff8796f-c352-4da2-9322-5fdf8a11c81e?page=1

But the solutions from there, which worked till Win 8.1, don't work now under Windows 10.

Has anybody a solution for this under Windows 10? I'm not sure if this error has an effect or causes bugs, but the Event Log gets very big because of the many 10016 IDs every time.

Thx in advance for any info or solution in that case.

All replies (54)

Friday, August 21, 2015 5:03 AM ✅Answered | 12 votes

Hello all,

Please take a try with the steps below, to reset the DCOM permission:

The DCOM ACLs are stored in the registry under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole, in the following binary values:

  • DefaultAccessPermission
  • DefaultLaunchPermission
  • MachineAccessRestriction
  • MachineLaunchRestriction

please backup the registry first, then delete all those values listed avove, DCOM will load the default settings if there is no values reference.

Regards

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

Thursday, August 6, 2015 6:12 AM | 1 vote

Hi Sebow,

Event ID 10016 means

A program, the Clsid displayed in the message, tried to start the DCOM server by using the DCOM infrastructure. Based on the security ID (SID), this user does not have the necessary permissions to start the DCOM server.

The below is the Microsoft Article talking about this Event ID :

http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows+Operating+System&ProdVer=5.2&EvtID=10016&EvtSrc=DCOM

User Action

Verify that the user has the appropriate permissions to start the DCOM server.

To assign permissions


  1. Using Regedit, navigate to the following registry value
    HKCR\Clsid\clsid value\localserver32
    The clsid value is the information displayed in the message.
  2. In the right pane, double-click Default. The Edit String dialog box is displayed. Leave this dialog box open.
  3. Click Start, and then click Control Panel.
  4. Double-click Administrative Tools, and then double-click Component
    Services    .
  5. In the Component Services snap-in, expand Computers, expand My
    Computer    , and double-click DCOM Config.
  6. In the right pane, locate the program by using its friendly name.
  7. Right-click the program name, and then select Properties.
  8. On the Security tab, in the Launch and Activation Permissions
    group box, select Customize, and then click Edit.

Add the user to the permissions list, and give the user the appropriate
permissions.

Regards

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

Monday, August 10, 2015 5:19 PM | 6 votes

I have the same errors. It's the runtimebroker service and permissions cannot be changed.

Tuesday, August 11, 2015 3:10 AM | 2 votes

I have this same error logged on my 2 Windows 10 PCs.  I frankly don't know if this RuntimeBroker service is meant to be this way or not.

I found the following thread and these instructions do allow you to change the permissions on RuntimeBroker service.

http://answers.microsoft.com/en-us/windows/forum/windows_8-performance/event-id-10016-the-application-specific-permission/9ff8796f-c352-4da2-9322-5fdf8a11c81e

But, again, should it be changed?  Can someone from Microsoft please chime in regarding this?

I found this on another thread:
The Runtime Broker is responsible for checking if a Metro app is declaring all of its permissions (like accessing your Photos) and informing the user whether or not its being allowed. In particular it is interesting to see how it functions when paired with access to hardware, such as an app’s ability to take webcam snapshots. It's serves as a middleman between your apps and your privacy/security.

Tuesday, August 11, 2015 11:00 PM

I'm running Windows 10 Pro. I cannot change permissions for RunTimeBroker using DCOMCONFIG.

On the Security tab of Properties dialog box for RunTimeBroker, there are 3 groups - Launch and Activation Permissions, Access Permissions and Configuration Permissions. Each has two options: Use Default and Customize. For all three groups, all options are grayed out and unchangeable. I am an administrator on my PC.

Microsoft rep, please intervene.

Wednesday, August 12, 2015 2:24 PM

I found that guide also and used it to add SYSTEM and haven't seen the error since.

Sunday, August 16, 2015 7:04 PM

Well, if I am not mistaken, there is something missing in this advise.

Even an administrator is not able to do your proposed changes in Windows 10 Home. One has to take the ownership of the registry entry to change the mentioned settings in Component Services.

And if I remember correctly one is unable to give ownership back to TrustedInstaller and could instead give it back to SYSTEM after all the changes are done.

It is definitely not sufficient to open the Edit String dialog box and I could make photos or more to prove it.

(Ah, ok, I found the source, this answer was copy-pasted by the Moderator ...)

http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows%20Operating%20System&ProdVer=5.2&EvtID=10016&EvtSrc=DCOM&LCID=1033

Monday, August 17, 2015 1:18 AM | 1 vote

In my case the user is NT AUTHORITY\LOCAL SERVICE SID (S-1-5-19), which means there is no user that I can add using the method described above. Does anybody know how to give permission to the Local Service and, more importantly, is Local Service suppose to initiate this request anyway?

Sunday, August 30, 2015 3:56 PM | 3 votes

I performed the steps of removing these registry entries and it made no difference. The properties on the DCOM config dialog were still grayed-out and disabled.

Saturday, November 7, 2015 11:25 AM | 2 votes

I am having this problem - but with only some non-admin user accounts on my computer.

I deleted the said registry values via Administrative account. On that account the problem does not manifest itself.

However, with non-admin account, the entire Start menu will not open, also none of the Store Apps will launch.

Also, contrary to what you said, new default values are not generated after reboot, but the values DefaultAccessPermission, DefaultLaunchPermission, MachineAccessRestriction and MachineLaunchRestriction remain missing.

Event ID 10016 is logged on Event Viewer upon loggin in as the non-admin:

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 NT AUTHORITY\SYSTEM SID (S-1-5-18) 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.***

Is text "...application container Unavailable SID (Unavailable)..." significant here?
What can you suggest?

I was initially able to fix this problem by "Refresh" function, i.e. effectively re-installing the OS.

The second time this problem appeared only a couple of days later. This time I used a system Restore Point to go back to normally functioning system.

Now the problem has come back again on the non-admin user - only after two days! The admin account works ok. so far.

What causes the system to the system corrupt itself again and again?

Sunday, November 8, 2015 5:32 PM

Does this suggestion work:
https://shauncassells.wordpress.com/2015/09/28/windows-10-event-10016-fix-the-application-specific-permission-settings-do-not-grant-local-activation-permission-for-the-com-server-application-with-clsid-d63b10c5-bb46-4990-a94f-e40b9d520160-and-a/

Hope this helps, Gerry

Wednesday, November 11, 2015 3:22 PM | 4 votes

Having this issue myself. Here's what I've found...

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 NT AUTHORITY\LOCAL SERVICE SID (S-1-5-19) 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.

This happens after upgrading my laptop from Windows 7 64-bit Home to Windows 10 Home. sfc and dism against dowloaded .iso confirm my system files are all ok.

Initially I could not make any changes in Component Services because all was greyed out. I took ownership of the relevant APPID and CLSID registry keys,  granted myself Full Control then switched ownership backed to TrustedInstaller.

This gave me access to Runtimebroker in Component Services. However when trying to edit the Launch and Activation Permissions I get a warning "One or more of the permission entries attached to Registry Value has an unrecognised or application-specific (callback) type and can not be displayed."

I get the choice of removing this unrecognised permission or viewing only (with permission excluded). But what is this permission?

I used Regedit to dump the APPID key which stores the Security Descriptor in binary format in the LaunchPermission value. 

"LaunchPermission"=hex:01,00,14,80,b0,00,00,00,bc,00,00,00,14,00,00,00,30,00,\   00,00,02,00,1c,00,01,00,00,00,11,00,14,00,04,00,00,00,01,01,00,00,00,00,00,\   10,00,10,00,00,02,00,80,00,03,00,00,00,00,00,18,00,0b,00,00,00,01,02,00,00,\   00,00,00,0f,02,00,00,00,01,00,00,00,00,00,14,00,0b,00,00,00,01,01,00,00,00,\   00,00,05,0a,00,00,00,09,00,4c,00,0b,00,00,00,01,01,00,00,00,00,00,05,04,00,\   00,00,61,72,74,78,f8,2e,00,00,00,57,00,49,00,4e,00,3a,00,2f,00,2f,00,49,00,\   53,00,4d,00,55,00,4c,00,54,00,49,00,53,00,45,00,53,00,53,00,49,00,4f,00,4e,\   00,53,00,4b,00,55,00,a2,01,01,00,00,00,00,00,05,12,00,00,00,01,01,00,00,00,\   00,00,05,12,00,00,00

I knocked up a quick bit of c# code to interpret this Security Descriptor. The result was

DACL

3 ACE(s)

AccessAllowed ACE flags: <None>

SID: S-1-15-2-1 [APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES] Access Mask: 00000000000000000000000000001011(0x0000000b)    <Execute><Execute Local><Activate Local>

AccessAllowed ACE flags: <None>

SID: S-1-5-10 [NT AUTHORITY\SELF] Access Mask: 00000000000000000000000000001011(0x0000000b)    <Execute><Execute Local><Activate Local>

AccessAllowedCallback

ACE flags: <None>

SID: S-1-5-4 [NT AUTHORITY\INTERACTIVE]

Access Mask: 00000000000000000000000000001011(0x0000000b) <Execute>Execute Local><Activate Local>

SACL

1 ACE(s) Custom ACE

Type flag is 17

Then repeated for AccessPermission (for the APPID)

"AccessPermission"=hex:01,00,14,80,ec,00,00,00,f8,00,00,00,14,00,00,00,30,00,\   00,00,02,00,1c,00,01,00,00,00,11,00,14,00,04,00,00,00,01,01,00,00,00,00,00,\   10,00,10,00,00,02,00,bc,00,06,00,00,00,00,00,18,00,03,00,00,00,01,02,00,00,\   00,00,00,0f,02,00,00,00,01,00,00,00,00,00,14,00,03,00,00,00,01,01,00,00,00,\   00,00,05,0a,00,00,00,00,00,14,00,03,00,00,00,01,01,00,00,00,00,00,05,12,00,\   00,00,00,00,14,00,03,00,00,00,01,01,00,00,00,00,00,05,13,00,00,00,00,00,14,\   00,03,00,00,00,01,01,00,00,00,00,00,05,14,00,00,00,09,00,4c,00,03,00,00,00,\   01,01,00,00,00,00,00,05,04,00,00,00,61,72,74,78,f8,2e,00,00,00,57,00,49,00,\   4e,00,3a,00,2f,00,2f,00,49,00,53,00,4d,00,55,00,4c,00,54,00,49,00,53,00,45,\   00,53,00,53,00,49,00,4f,00,4e,00,53,00,4b,00,55,00,a2,01,01,00,00,00,00,00,\   05,12,00,00,00,01,01,00,00,00,00,00,05,12,00,00,00

DACL

6 ACE(s)

AccessAllowed

ACE flags: <None>

SID: S-1-15-2-1 [APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES] Access Mask: 00000000000000000000000000000011(0x00000003)    <Execute><Execute Local>

AccessAllowed

ACE flags: <None>

SID: S-1-5-10 [NT AUTHORITY\SELF]

Access Mask: 00000000000000000000000000000011(0x00000003)    <Execute><Execute Local>

AccessAllowed

ACE flags: <None>

SID: S-1-5-18 [NT AUTHORITY\SYSTEM]

Access Mask: 00000000000000000000000000000011(0x00000003)    <Execute><Execute Local>

AccessAllowed

ACE flags: <None>

SID: S-1-5-19 [NT AUTHORITY\LOCAL SERVICE]

Access Mask: 00000000000000000000000000000011(0x00000003)    <Execute><Execute Local>

AccessAllowed

ACE flags: <None>

SID: S-1-5-20 [NT AUTHORITY\NETWORK SERVICE]

Access Mask: 00000000000000000000000000000011(0x00000003)    <Execute><Execute Local>

AccessAllowedCallback

ACE flags: <None>

SID: S-1-5-4 [NT AUTHORITY\INTERACTIVE]

Access Mask: 00000000000000000000000000000011(0x00000003)    <Execute><Execute Local>

SACL

1 ACE(s)

Custom ACE

Type flag is 17

The CUSTOM system ACE seems to be the problem.

First, is this info useful to anybody in Microsoft who is trying to determine how this error occurred?

Second, does anybody know what this mysterious custom ACE is in the SACL is (is it even appropriate to have a SACL for launch permissions?)? Will deleting it have zero impact?

Third, can somebody let me know the correct permissions for launch and access control? Simply add Local Launch and Local Activation for LOCAL SERVICE as per event log message?

Tuesday, November 17, 2015 4:36 PM

Just wanted to say that I followed these steps, purged my logs and rebooted. This fix worked for me.

Hello all,

Please take a try with the steps below, to reset the DCOM permission:

The DCOM ACLs are stored in the registry under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole, in the following binary values:

  • DefaultAccessPermission
  • DefaultLaunchPermission
  • MachineAccessRestriction
  • MachineLaunchRestriction

Thursday, November 26, 2015 12:29 PM

 I don't even have the HKCR\Clsid\clsid value\Localserver32 in my registry. How do I change something that I don't have? I have gone as far as creating said key to no avail. Do I wait until somebody that don't work for MS works it out for them? Since they make so much money creating Windoze software they need to earn it and fix this.

Thursday, December 3, 2015 5:42 PM

Hi 

The clsid value in the case in question is {D63B10C5-BB46-4990-A94F-E40B9D520160} as reported in the first post on this page.

Friday, December 18, 2015 7:36 PM | 1 vote

This did not change anything. The described registry values were not recreated, I still had the same event viewer entries, and Dcomcnfg remained grayed out

Friday, December 18, 2015 7:46 PM | 1 vote

After many weeks of toiling with this issue I discovered a pretty effortless way to fix the issue and created a post about it here: http://www.clintpriest.com/2015/11/fixing-10016-on-windows-10-the-machine-default-permission-settings-do-not-grant-local-activation-permission-for-the-com-server-application-with-clsid/

Did not work for me either

Tuesday, December 29, 2015 6:39 AM | 1 vote

I have the exact same issue. Reinstalled Windows 10 and the issue came back again. This is making me a bit nuts. 

In Details tab of the Event 10016 error the Security UserID=S-1-5-18

Isn't that part of Malwarebytes ID????  

Friday, January 1, 2016 5:51 AM | 1 vote

Microsoft.  Fix this!

glnzglnz ► In the office, Dell Optiplex 7010 with 4GB RAM, Win 7 Pro 32-bit and Office 2010. ► At home, Dell Optiplex 7010 with 16GB RAM dual-booting Win 7 Pro 64-bit and Win 10 Pro 64-bit. ► Also still have Dell Optiplex 755 with 4GB RAM with Win XP Pro SP3 (which still gets updates with the POS hack) and Office 2003.

Friday, January 8, 2016 3:55 AM

Thank you, very much, Mr. Shao. I upgraded my laptop to Windows 10 and then I couldn't log in. I got thrown into a temporary account. I was wondering how long it was going to take me to be able to log in to my laptop.

Tuesday, January 12, 2016 4:03 PM | 1 vote

Hi,

Doe's anybody know why the hell this DCOM problem exist at all? I may do a clean install and the error are soon there. There should be something wrong systematically? Ordinary users wont mess with registry and DCOM permissions. MS should fix this.

BTW: For some reason, I don't see the "DefaultAccessPermission" key at all. Is this normal? I have not deleted those key's yet but I'd like to get some backround information why this kind of error throws up?

rgds Sven

Sunday, February 14, 2016 4:12 AM | 2 votes

Here is a fix that works for Windows 10 and other previous versions.

Fix for Distributed COM RuntimeBroker (Error ID: 10016):

Because DCOM RuntimeBroker in Component Services won’t let you edit the security settings, you need to right click on the task bar Windows icon, click Run and type in regedit, and then press Enter. Do the instructions 1-4 below for each of these registry keys:

HKEY_CLASSES_ROOT\CLSID\D63B10C5-BB46-4990-A94F-E40B9D520160}HKEY_CLASSES_ROOT\CLSID\D63B10C5-BB46-4990-A94F-E40B9D520160}\LocalServer32

  1. Go to each key and back it up by doing a right click on the registry key and click Export and save the file to a documents folder (you should always backup any registry key you change). Now right click on the registry key again and click Permissions > Advanced.

  2. If Administrators has Full Privileges, then go to the next registry key and start with instruction #1 again. Otherwise change ownership to Administrators by clicking Change at the top where is says Owner then click Advanced > Find Now > Administrators > OK > OK > Apply > Yes.  If a message(s) comes up just click OK or Yes until back to the Permissions window.

  3. Click on Administrators and check off Full Control then click OK.

  4. Check "Replace all child objects...." and then Apply.  If a message(s) comes up just click OK or Yes until back to the Permissions window.  Then click OK to close the Permissions window.

  5. When done, reboot.

  6. Go to Control Panel > Administrative Tools > Component Services > Computers (middle window)> My Computer > DCOM Config and then right click on RuntimeBroker and click Properties >  Security.  You’ll see 3 edit buttons.

  7. Make sure Customize is checked and then click on the top Edit under Launch and Activation Permissions and you may see this:

    If you see it click Cancel.

  8. In the Group or user names box highlight each and make sure that Local Launch and Local Activation are checked.  Make sure that you have in the Group or User Names window: All Applications Packages, Self, System, Administrators, and Interactive. If any are missing, then click Add > Advanced > Find Now > [Name]> OK > OK, and make sure that Local Launch and Local Activation are checked.

  9. Now click the middle Edit under Access Permissions (make sure Customize is checked off) then in the Group or user names box highlight each and make sure that Local Access is checked off.  When done click OK. Make sure that you have in the Group or User Names window: All Applications Packages, Self, System, Administrators, Local Network, and Network Service. If any are missing, then click Add > Advanced > Find Now > [Name]> OK > OK, and make sure that Local Access is checked off.

  10. Click the bottom Edit under Configuration Parameters (make sure Customize is checked off) then click Advanced. Each Principal should have Read Access except for Administrators, and TrustedInstaller who should have Full.  If you need to make any changes, highlight the one to change then click Edit, make any changes, and then click OK.   You should have the following principals listed: All Applications Packages, System, Administrators, Users, and TrustedInstaller. If any are missing then click Add > Advanced > Find Now > [Name]> OK > OK (make sure that Read is checked). Then click OK until all the Properties windows are closed. Now close up the Component Services window.

  11. Now go back to the regedit window and change ownership to SYSTEM on the same four keys previously changed. Do this by clicking Change at the top where is says Owner then click Advanced > Find Now > SYSTEM > OK > OK > Apply > Yes. If a message(s) comes up just click OK or Yes until back to the Permissions window and then click OK > OK.

  12. When done changing the owner to SYSTEM on registry keys like you did in #2 then close up regedit.

  13. Best to reboot at this point and then you are done.

Sunday, February 14, 2016 6:35 PM

Thanks for detailed instructions. However,  after editing the 4 registry key as instructed I could not add any additional entries for my computer in the first edit section of the Dcom Config RuntimeBroker Properties Security in the Group or Users Names box: the "add" button is greyed and not accessible even after editing the registry keys and rebooting - only two (All Applications Packages and Self)  of you listed names are included. So I went back and restored the edited registry keys.

Friday, March 25, 2016 8:35 PM | 1 vote

You need to make sure that you have Administrator privileges. Go to Control panel> User Accounts and under your name on the right it should say Administrator. If not have the person with the Administrator privileges change it for you. Also when you made registry changes did you make sure that you not only changed the ownership but also gave Administrators FULL privileges. Also I have since revised the fix saying that you only have to change the CLSID registry key which in this case is D63B10C5-BB46-4990-A94F-E40B9D520160 .

Tuesday, March 29, 2016 1:47 PM

JSiepmann, thanks for instructions but I'm having similar problem as Nevilleo. I'm in Windows 10 Home 64-bit and the lone user, listed as Administrator in User Accounts. I followed steps 1-4 of your instructions and now Administrators shows as the Owner and with Full Control of Permissions for the two registry keys in Registry Editor. After reboot however, at step 6 of your instructions, the buttons and edit boxes of the Security tab in RuntimeBroker Properties of DCOM Config are grayed out and inaccessible to me. Any thoughts on how I can proceed?

Tuesday, March 29, 2016 10:24 PM

JSiepmann, thanks for instructions but I'm having similar problem as Nevilleo. I'm in Windows 10 Home 64-bit and the lone user, listed as Administrator in User Accounts. I followed steps 1-4 of your instructions and now Administrators shows as the Owner and with Full Control of Permissions for the two registry keys in Registry Editor. After reboot however, at step 6 of your instructions, the buttons and edit boxes of the Security tab in RuntimeBroker Properties of DCOM Config are grayed out and inaccessible to me. Any thoughts on how I can proceed?

NEVERMIND: I got it sorted by following similar, but slightly different, advice at http://www.tenforums.com/performance-maintenance/20230-windows-10-event-id-10010-10016-errors-distributedcom-2.html (helpful PowerShell script in post #12 for adding permissions to keys).

Monday, May 2, 2016 1:50 AM

I just started having the same issue and BSOD's that I assume are related.  So there are a lot of instructions about how to give this unknown app permission to own your computer but no one has said what they app is or why I should allow it to access my computer.  I can only assume that the permissions are set as designed so this must be some malware attempting to get into my PC.  

Can anyone provide details about what the app is, why I should try so hard to give it access to my PC?

Sunday, May 22, 2016 6:21 PM

I can get to  the "Add the user..." step. But the "Add..." button is grayed out.

Friday, June 10, 2016 3:17 PM

THANK YOU!!  This worked for me!

Saturday, January 14, 2017 9:51 PM | 1 vote

Are you sure you start the Component Services as Administrator? I have seen many users that missed that step and therefor were unable to change the settings in DCOM Config (greyed out).
I also noted that same step in my own blog at step 17:

FIX: Event 10016 The application-specific permission settings do not grant Lokaal Activation permission for the COM Server application with CLSID

Thursday, March 2, 2017 9:54 AM

Hello, there is no does keys in Windows 10 Home register .... so, should I add them ?

Thursday, March 9, 2017 5:22 PM

This solution did not work on Windows 10 Enterprise [Version 10.0.14393]. After deleting the registry keys mentioned above the error continues. Please make sure that you backup or export those registry keys before trying the solution. It did not work for me.

Tuesday, March 28, 2017 4:17 PM

True. A user must change ownership of the registry key(s) that are referenced from the Com object before changing permissions. Sometimes even requiring a reboot in between. Also, It IS possible to change ownership back to TrustedInstaller but its not intuitive.

Once you have clicked the Change button on the ownership you can type the following in directly on the User or Group selection window

NT Service\TrustedInstaller

and click OK. I believe the capitals are necessary but I can't remember. and there is a space after NT.

Sometimes there are more than one or two Registry keys that need the security changed on before the Component Services snap-in will let you edit the Com object's permissions.

Good luck everyone.

Tuesday, March 28, 2017 4:25 PM

I'm not an expert but did you ever take notice that it may be a windows update causing this? and two days is about right for your machine to have caught up with updates after a restore or refresh.

Otherwise its certain applications being installed that are trying to add application specific permissions to Com objects.

Wednesday, March 29, 2017 6:50 PM

Thanks for detailed instructions. However, 

I have 2 computers with the error, a W7 Ultimate upgraded t W10 pro, on this the fix works!! but a second bought with W10 home, I am not able to change the permissions in Component Services, all greyed out, as are the permission controls for all other components I checked.

Is the fix not possible with home  edition? Also I am not able to change the owner back to TrustedInstaller, it is not recognise  although present in the system. And the reg files don't work either. So the registry entries will have to stay as now are. 

(yes all tools ran as administrator)

but thanks for the detailed explanation , 

Ian 

 

Tuesday, April 25, 2017 7:11 AM

Fixed it for me. Hasn't recreated them yet either.

Wednesday, May 17, 2017 10:45 PM

I am having the same error but when I follow the path in regedit I do not have a localserver32 in tis location

Computer\HKEY_CLASSES_ROOT\CLSID\6B3B8D23-FA8D-40B9-8DBD-B950333E2C52}all I have is Default  key and AppID. Should I delete the clsid location and then reboot letting windows 10 remake it? Making sure I backup the registry first.

Tuesday, June 27, 2017 3:32 AM

Try this simple solution 

http://batcmd.com/windows/10/services/comsysapp/

Friday, June 30, 2017 1:56 PM

Hello,

I see only 3 keys

  • DefaultLaunchPermission
  • MachineAccessRestriction
  • MachineLaunchRestriction

but I don't see DefaultAccessPermission

Should I delete the three I see?

Why can't I see DefaultAccessPermission?

Thanks!

Saturday, September 2, 2017 4:56 PM

Hello:

This did not fix it for me.  I deleted the keys that were present last night and rebooted several times.  I receive the event a few minutes ago and rechecked my Registry and the keys mentioned are not there.

Larry S. Peteet

Saturday, September 16, 2017 12:38 AM | 6 votes

If you deleted the registry keys/values, or you removed the callback permissions, then you made a mistake. Restore the permissions to Microsoft defaults.

Once you are back to the default [error causing] permissions, do the following:

  1. Download the DCOMPermissions.psm1 PowerShell module
  2. Open an administrative command prompt and run these commands:
Import-Module .\DCOMPermissions

Grant-DCOMPermission -ApplicationID "{9CA88EE3-ACB7-47C8-AFC4-AB702511C276}" -Account "SYSTEM" -Type Launch -Permissions LocalLaunch,LocalActivation -OverrideConfigurationPermissions

If you receive no errors, then the change was successful.  No reboot needed.

The command grants SYSTEM permission to launch and activate RuntimeBroker.  The existing permissions and callbacks are preserved, and the registry permissions are not changed from defaults.

-Tony

Monday, October 30, 2017 9:17 PM

October 30, 2017 - Be sure the Component Services Control Panel icon is recognized as a shortcut and must be Checked as "RUN AS ADMINISTRATOR" ...

I found the Jan. 14, 2017 post by Christian Gude "helpful": On my W10-PC the "Control Panel\Administrative Tools\Component Services" icon IS a shortcut and needs to be elevated by selecting the Icon in Control Panel with a right-click mouse; selecting Properties from the "right click" menu; select the Shortcut tab on the Component Services Property page; select  'Advanced..' button at the bottom of the properties page second section; and be sure to fill the Check Box for "Run as Administrator". Select OK to back out of the last step Then choose Component Services; Run As.. to open Component Service.  

Saturday, November 4, 2017 2:25 AM

thank you this works for me! plus it's the easiest to do. tried the manual edit permission method but did not work

Saturday, November 25, 2017 7:13 AM

look at: https://social.technet.microsoft.com/Forums/windows/en-US/3e7d85e3-d0e1-4e79-8141-0bbf8faf3644/windows-10-anniversary-update-the-case-of-the-mysterious-account-sid-causing-the-flood-of-dcom?forum=win10itprosetup

Tuesday, December 5, 2017 1:07 AM

This didn't work for me, have just as many errors as before.

Sunday, January 7, 2018 1:49 PM

Just wanted to say that I followed these steps, purged my logs and rebooted. This fix worked for me.

Hello all,

Please take a try with the steps below, to reset the DCOM permission:

The DCOM ACLs are stored in the registry under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole, in the following binary values:

  • DefaultAccessPermission
  • DefaultLaunchPermission
  • MachineAccessRestriction
  • MachineLaunchRestriction

Just checked my registry for the above values and 'DefaultAccessPermission' is missing altogether! Can I add this back and if so what value do I set?

Monday, January 8, 2018 9:56 PM

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole, in the following binary values:

  • DefaultAccessPermission
  • DefaultLaunchPermission
  • MachineAccessRestriction
  • MachineLaunchRestriction

Just checked my registry for the above values and 'DefaultAccessPermission' is missing altogether! Can I add this back and if so what value do I set?

On my [clean] Windows 10 and Server 2016 systems, this registry value does not exist.  I expect that is the default.

If you are trying to fix the problem in the original post, ignore the "accepted answer", and follow the instructions from Tony MCP's post dated Sep 16, 2017.

-Tony

Wednesday, June 6, 2018 5:27 PM

The command grants SYSTEM permission to launch and activate RuntimeBroker.

Agreed, and certainly understandable from a perspective of "something that's already been able to achieve running as LocalSystem is either to be trusted or at least doesn't hose you any more than you already are."

But what are we doing?  If Windows code executing as LocalSystem was supposed to have permission to invoke RuntimeBroker, why wasn't it already granted such permission?  LocalSystem security context isn't somehow "new" or created by a third-party software installation.  Microsoft already know about it and didn't grant it, so what security hole are we opening, or design decision are we countermanding?

In my case, the persistent DCOM warnings in the event log are citing my user's SID, not LocalSystem.  So while I could grant permission, the nagging question is "if Windows hadn't already granted this, is it because something is attempting to execute from a context which SHOULD be denied?"

Looking for more information to divine between "fix the symptom" versus "fix the problem."

Wednesday, July 11, 2018 8:43 PM

Very helpful.  Thank you.

Tuesday, August 7, 2018 6:56 AM

Im regulary a Linux-user but accidently got some laptops cause of work as teacher,  with this strange system. Also recently "up" - graded an old pc (Dell with AMD 2-core)) not used for many years, to the same struggle. Before this it was a working machine with Win XP,  not any more usuable and will reinstall that XP sp3. (Machine will be used mainly by Young relatives for general surfing and gamings -older games)

I must add a question here, /for what category of people is this "game" named "Win 10" ment.
Ment only for specialists or people with eternal amount of time to solve upcoming problems? With expertise around the system-register..
For people that have /fiber/ Connection, NOT payed 4G (in my country Sweden, around 10 dollars for 1 Gbyte data download) cause of those ever coming enormous updates,  thatt then are failed during installation, and ever repeted, almost blocking the PC)?

Car-producers must recall tousends of cars and/or compensate the customers when things are wrong with the Product and not usuable as was promised, or braking some local laws.
Those producers do NOT offer a payed support, its free.
Why pay for a support when problems are caused by really bad programing.
What will happen if I and tousand other users go to our special Courts for this.
Noone in this big firm or in this forum thought of that?

I will personally soon give in my report to the Swedish ARN.
If this is deleted I and other teachers will find severeal good channels to inform around this in fact global mess.

/ Hans

(sry, not correct English)

Tuesday, August 7, 2018 7:40 AM

I have 2 computers with the error, a W7 Ultimate upgraded t W10 pro, on this the fix works!! but a second bought with W10 home, I am not able to change the permissions in Component Services, all greyed out, as are the permission controls for all other components I checked.

 

All my friends have errors with all their windows-machines.
I gave that productarea up around 1997.
My older Macs and Linux-Machines is doing their job, not blocking me with Always new errors and hangings or huge not necessary downloads.

All this is nothing more than a big mess.

i feel sorrow for all those that believe its good for the humanity.

Thursday, August 9, 2018 10:35 AM

I am getting this on all new machines with a brand new install of Windows 1803.  This is truly unacceptable.  My event logs are not saturated with these garbage errors and someone actually has the audacity to say that it's perfectly fine just ignore them?!?!

If you bought a brand new car and a warning light shows up on the dash, would you be OK with the service department saying "just put some masking tape over it.  Actually, put some electrical tape on it instead since it's black and hides out more of that orangish glow.  It's nothing!"

Truly.

Thursday, August 16, 2018 8:04 PM

I'm having this issue too so I'll join the conversation. While the OP is very old, the information below might be relevant to the update/replacement of the runtimebroker object/functionality in Windows 10.

Looking at the feedback in this thread and Component Services on my own computer, I notice that there are 2 RuntimeBroker objects shown.

Could it be that somewhere down the line of updates or upgrading a new RuntimeBroker object was created and the old one was not properly cleaned/removed ?
Can anyone confirm/verify this on their own computer?
Two RuntimeBroker(s) I see are:
{9CA88EE3-ACB7-47c8-AFC4-AB702511C276} and
{15c20b67-12e7-4bb6-92bb-7aff07997402}

The other RuntimeBroker does not seem to generate similar alerts in the eventlog. I get the feeling the first RuntimeBroker object has been replaced at some point and has been stripped of it's permissions and thus generates these alerts.

Update:

Looking at the two RuntimeBroker objects themselves did not directly reveal anything other than there are 2.
The alerts in the eventlog specify a CLSID, when looking up the CLSIDs for both those RuntimeBroker objects I found:

For the new one:

{2593f8b9-4eaf-457c-b68a-50f6b8ea6b54}
With a value Default named: RunTimeBroker

And the old one:

{D63B10C5-BB46-4990-A94F-E40B9D520160} (which we already knew from the alert).
With a value Default named: PerAppRuntimeBroker

Which lead me back to this article:
https://blogs.windows.com/windowsexperience/2017/06/08/announcing-windows-10-insider-preview-build-16215-pc-build-15222-mobile/

Developer Improvements

Per app Runtime Broker: If you open Task Manager, you will notice UWPs now use per-application instanced Runtime Broker processes, rather than all sharing a single session-wide Runtime Broker. This will help improve resource attribution, resource management, and fault tolerance.

Suggesting this was part of build 16251 which was released to public known as 1709.
The text above about the improvement seems to suggest an improvement and therefore 'replacement' of the code. Which could confirm an overlooked/forgotten removal of the previous RuntimeBroker object.

Saturday, March 7, 2020 1:23 AM

Hello all,

Please take a try with the steps below, to reset the DCOM permission:

The DCOM ACLs are stored in the registry under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole, in the following binary values:

  • DefaultAccessPermission
  • DefaultLaunchPermission
  • MachineAccessRestriction
  • MachineLaunchRestriction

please backup the registry first, then delete all those values listed avove, DCOM will load the default settings if there is no values reference.

Regards

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

Just a BIG HEADS UP - THIS WILL SCREW UP YOUR SYSTEM!!! I am running Win10Pro build 1909.  If you blow away those registry values, they will NOT regenerate and your system will quickly grind to a halt, unrecoverable without reinstalling Windows.  DO NOT DO THIS!