DCOM event 10016: Local Activation permission warning explained

Applies to: Windows 11, Windows 10 and Windows Server. You only need admin rights for the advanced section.

What the message means

You’ll find it in Event Viewer under Windows Logs > System, logged as a Warning or Error with source DistributedCOM and event ID 10016. The full text names a CLSID and an APPID (long codes in braces), a user or SID such as NT AUTHORITY\SYSTEM, LOCAL SERVICE or your own account, and says the address is LocalHost (Using LRPC).

DCOM (Distributed Component Object Model) lets programs start and talk to shared Windows components. Each component has a list of accounts allowed to launch or activate it. Event 10016 means an account asked to activate a component it doesn’t have permission for, so that one request was refused.

Is it safe to ignore?

For the usual cases, yes. Microsoft’s troubleshooting article explains that Windows components first try to access some DCOM components with one set of parameters, and retry with another if that’s refused. The first attempt is kept because it works in some situations. The refused attempt is what gets logged.

Microsoft’s guidance is that the events don’t affect functionality and that changing the permissions isn’t recommended because it can have unintended side effects. Many PCs log several 10016 events at every start-up, for example from ShellExperienceHost or RuntimeBroker, with nothing wrong.

Event 10016 is not a cause of crashes, freezes or blue screens on its own. If you’re looking for the reason behind one of those, check the other errors logged at the same time instead.

How to see which component it is

If you want to know what the event refers to:

1. Open the event in Event Viewer and copy the CLSID and APPID values.
2. Press Windows + R, type regedit and press Enter.
3. Go to HKEY_CLASSES_ROOT\CLSID\{CLSID} (paste your value). The (Default) value usually shows the component’s name.
4. Or check HKEY_CLASSES_ROOT\AppID\{APPID} for the application name.

Only look; don’t change anything here unless you have a specific reason. If the component belongs to Windows itself (names such as RuntimeBroker, ShellServiceHost, Immersive Shell or PerAppRuntimeBroker), it’s the by-design case. If it belongs to a third-party program, that program’s vendor is the right place to ask.

Hide event 10016 in Event Viewer

Microsoft’s workaround is a filter, not a fix: it simply hides the events from your view.

1. Open Event Viewer (right-click Start and select it).
2. Select Action > Create Custom View.
3. Open the XML tab, tick Edit query manually and confirm with Yes.
4. Replace the text with the query below, select OK and give the view a name such as System without 10016.

<QueryList>
  <Query Id="0" Path="System">
    <Select Path="System">*</Select>
    <Suppress Path="System">*[System[(EventID=10016)]]</Suppress>
  </Query>
</QueryList>

The new view appears under Custom Views. It shows the whole System log except event 10016. Microsoft’s own example is narrower and hides only specific CLSID, APPID and SID combinations, which is the better choice if you want to keep seeing 10016 events from other components.

Granting the permission (advanced, not recommended)

Many forum guides tell you to take ownership of the component’s registry key and add Local Activation for the account in Component Services (dcomcnfg). It does stop that particular event, but Microsoft advises against it: these keys are owned by TrustedInstaller for a reason, the change can have side effects, and Windows updates may reset it.

If a specific program genuinely fails because of a DCOM permission, follow that program’s vendor instructions, make a restore point first, and note what you change so you can undo it. There’s no benefit in doing this just to clear the log.

When to look further

• A program or feature actually doesn’t work, and the 10016 event appears exactly when you try to use it.
• The CLSID belongs to a third-party app that recently installed or updated.
• The events come with other errors, such as services failing to start. See Diagnostics Policy Service is not running or Please wait for the System Event Notification Service if those match what you see.

In those cases, repairing system files is a safe first step: run sfc /scannow in Terminal (Admin). Permission errors on folders are a different problem; see You don’t currently have permission to access this folder.

Related guides

• The Diagnostics Policy Service is not running: how to fix it
• Please wait for the System Event Notification Service: how to fix it
• You don’t currently have permission to access this folder
• System Volume Information access denied: what to do

Official sources: for more detail, see this Microsoft page:

• Microsoft Learn: DCOM event ID 10016 is logged in Windows

Frequently asked questions

Why do I see dozens of these after every start-up?

Several Windows components start at sign-in and each one makes the first, refused attempt before succeeding. That’s expected and doesn’t slow the PC down in any noticeable way.

Is event 10016 a sign of malware?

No. It’s a normal Windows event. If you’re worried about malware, run a full scan, but don’t treat these events as evidence.

Will a Windows update fix it?

Not usually, because it isn’t a fault. Microsoft treats it as by design.

Does it matter whether it’s a Warning or an Error?

No. Different Windows versions log the same event at different levels; the guidance is the same.