If the Event Viewer displays an error message—The application-specific permission settings do not grant Local Activation permission for the COM Server application, or The machine-default permission settings do not grant Local Activation for the COM Server application— then this article will help you.
It comes with a DCOM Event ID 10016, and this error appears mainly after upgrading the operating system. Although this error doesn’t affect the user experience of the regular Windows 10 user, some of you might want to know why this happens and what you can do about it.
These 10016 events are recorded when Microsoft components try to access DCOM components without the required permissions. These events can usually be safely ignored because they do not adversely affect functionality and are by design.
The whole error message looks like this-
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {C2F03A33-21F5-47FA-B4BB-156362A2F239} and APPID {316CDED5-E4AE-4B15-9113-7055D84DCC97} 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.
For your information, the CLSID and APPID can be different on your computer as they represent a component service on your computer. Regarding the solution, it is already mentioned in the error message. You need to modify the security permission from an administrative tool in Windows 10.
What is DCOM Config in Windows?
DCOM (Distributed Component Object Model) is a Microsoft technology that enables communication and data exchange between software components distributed across networked computers. It is typically used to change the security and communication settings for DCOM applications. For example, you can use DCOM Config to specify which users and groups have access to a particular DCOM application or to change the port number used for communication between the DCOM application and other computers.
The application-specific permission settings do not grant Local Activation
To fix The application-specific (or machine-default), permission settings do not grant Local Activation error in Windows 11/10, follow these steps-
- Identify and confirm CLSID and APPID
- Change ownership of CLSID key from Registry Editor
- Modify security permission from Component Services
Read on to learn the steps in detail.
You need to identify the CLSID and APPID. As they can be different on your computer, this is very important to recognize them. Otherwise, you won’t be able to get rid of this Event Viewer error message. According to the error mentioned above, the CLSID is {C2F03A33-21F5-47FA-B4BB-156362A2F239}, and the APPID is {316CDED5-E4AE-4B15-9113-7055D84DCC97}. There is another item called SID, but that is not necessary at this moment.
Now you need to find the component that is creating the issue. For that, open up the Registry Editor on your computer. To do so, press Win+R, type regedit, and the Enter button. After that, navigate to this path-
HKEY_Classes_Root\CLSID\<Enter-your-CLSID>
Do not forget to replace the Enter-your-ClSID with the original CLSID you got in the error message. After getting it, you should find the APPID on your right-hand side. Make sure this APPID and the previous APPID (that is mentioned in the error message) are the same. After confirming, right-click on the CLSID on your left-hand side, and select the Permissions option.
Then, click the Advanced button.
By default, this key is owned by TrustedInstaller, but you need to change the owner to Administrator. For that, click the Change button in the Advanced Security Settings window > write down “Administrator” > click the Check Names button > click the OK button.
Also, you need to select the Replace owner on subcontainers and objects check-box.
After doing that, select Administrators from the Group or user names list, and make a tick in the Allow/Full Control checkbox. Now save your settings.
Also, you need to check the Default – Data name. In this example, the Default Data name is Immersive Shell. It should be different if the CLSID and APPID are different in your error message.
After that, you also need to take ownership of the APPID. For that, navigate to this path in the Registry Editor-
HKEY_Local_Machine\Software\Classes\AppID\your-APPID
You need to do the same as above to change the ownership of that Registry key.
In case you are facing any problem changing the ownership of the Registry key, you can check out our free tool called RegOwnit, which lets you do it with a click.
After completing these steps, you need to open the Component Services. You can search for it in the Taskbar box and click the corresponding result. After opening Component Services, go here-
Component Services > Computer > My Computer > DCOM Config > Immersive Shell
Based on this example, the CLSID matches this Immersive Shell component service. You need to find the Default – Data name that you got from the Registry Editor. After recognizing, right-click on the component service and select Properties. Here you should find the Application ID or APPID that you can confirm again.
Next, go to the Security tab. Here you can find three labels, including Launch and Activation Permissions. Click the corresponding Edit button.
If you get any warning message, click the Cancel button and go ahead. You need to follow the same steps as above to add two accounts-
- SYSTEM
- LOCAL SERVICE
After adding them, select one at a time, and give both local Launch and Local Activation permissions.
Save the changes, and you won’t get the same issue in the Event Viewer again.
Whether you get the issue with RuntimeBroker, Immersive Shell, or any other process, the solution is the same for all of them.
Is there an alternative to DCOM CONFIG?
No, there is no direct alternative to DCOM CONFIG. However, you can achieve a similar result using the Registry or the command line utility DCOMCNFG. You can use the latter to configure DCOM settings from a script or command prompt executed from Windows Terminal or PowerShell.
