Log Dejargonizer

Windows System Log · Event 10016

Event 10016: DCOM permission error you can almost always ignore

A program asked to start a Windows component and was refused by the permission settings. Microsoft has stated these entries can be safely ignored in the overwhelming majority of cases, and the registry edits people apply to silence them cause more problems than the error does.

Also written as 10016Event ID 10016DistributedCOM 10016

What it means for you

On a personal computer

This looks alarming and almost never is. Windows components ask each other for permissions they do not have, get refused, and quietly succeed a different way. Nothing is broken. Do not follow guides that tell you to take ownership of registry keys to make it stop — that changes system permissions for no benefit.

For an analyst

Filter it out of your dashboards rather than fixing it. It fires most heavily at boot and after feature updates. If you genuinely need to resolve one, translate the CLSID and APPID to a component name first and confirm the component is actually failing — in almost every case it is not.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID 
{2593F8B9-4EAF-457C-B68A-50F6B8EA6B54}
 and APPID 
{15C20B67-12E7-4BB6-92BB-7AFF07997402}
 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.

The fields that decide it

Everything else in the log line is context.

CLSID
The class identifier of the component that was requested. Translate it before doing anything else — the raw value tells you nothing.
APPID
The application identifier of the DCOM server involved.
User / SID
The account the request was made under. NT AUTHORITY\SYSTEM and LOCAL SERVICE are the usual values.
Permission type
Which permission was missing.
  • Local ActivationThe most common. Something tried to start a component locally.
  • Local LaunchSimilar, and equally routine.
  • Remote ActivationRarer, and worth a closer look on a server where remote DCOM matters.

Ordinary reasons this happens

Most of the time it is one of these.

  • Windows components asking for permissions they were never granted, by design. This is the overwhelming majority.
  • Boot-time component activation, which produces a burst of these on every startup.
  • Feature updates changing default permissions on built-in components.
  • Third-party software probing for a component it can operate without.
  • The RuntimeBroker and ShellExperienceHost components, which are responsible for a large share of these entries on desktop Windows.

When it is not ordinary

DCOM used for lateral movement.

What gives it awayRemote Activation failures for unexpected components, from a source address that has no administrative role. This is genuinely rare — the vast majority of 10016 entries are local and routine.

ATT&CK T1021.003

What to do next

  1. Check whether anything is actually broken. If not, the correct action is to ignore it.
  2. If you do investigate, translate the CLSID to a component name before proceeding.
  3. Check whether the permission type is Local or Remote. Remote on a server is the only variant that occasionally matters.
  4. Resist editing registry permissions to silence it. The changes are hard to reverse and Microsoft advises against them.
  5. In a monitoring platform, filter the event out rather than trying to eliminate it at source.

Queries to run

powershell Groups by CLSID so you can see it is a handful of components repeating, not a spreading problem. 
Get-WinEvent -FilterHashtable @{LogName='System'; Id=10016} -MaxEvents 50 | Group-Object { ($_.Message -split 'CLSID')[1] } | Sort-Object Count -Descending | Select-Object Count, Name
powershell Translates a CLSID from the message into a component name. Do this before deciding anything. 
$clsid='{2593F8B9-4EAF-457C-B68A-50F6B8EA6B54}'; Get-ItemProperty "HKLM:\SOFTWARE\Classes\CLSID\$clsid" -ErrorAction SilentlyContinue | Select-Object '(default)'

Common questions

Should I fix DistributedCOM Event 10016?

Almost certainly not. Microsoft's own guidance is that these entries can be safely ignored in most cases — the component that was refused simply activates another way and nothing fails. If nothing on the machine is actually broken, the right response is to ignore the event or filter it from your monitoring.

Is it safe to edit the registry to stop Event 10016?

It is not recommended. The commonly circulated fix involves taking ownership of registry keys and changing DCOM permissions on built-in Windows components, which is hard to reverse, can be undone by the next feature update, and occasionally causes real problems. The error itself causes none.

Why does Event 10016 appear so many times at startup?

Because a number of Windows components activate during boot and request permissions they were never granted. Each refusal writes an entry, and each component then proceeds successfully by another route. A burst at every startup is the normal pattern.

How do I find out which application is causing Event 10016?

Take the CLSID from the message and look it up under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID in the registry, where the default value gives the component name. Do this before making any changes — in most cases you will find it is a built-in Windows component behaving normally.

Read next

Vendor documentation

Last reviewed 28 August 2026