Event ID 10016 is a DistributedCOM (DCOM) error in the Windows System log that means an account was denied Local Activation permission for a COM server, named by its CLSID and APPID. It's one of the most common entries in Event Viewer, and it looks alarming, but Microsoft's own documentation says these events are usually expected and by design. In most cases they don't affect functionality and can be safely ignored. This guide explains what the message means field by field, why Windows logs it even when nothing is broken, how to quiet the noise, and the narrow cases where 10016 actually points to a real problem worth fixing.
Key takeaways
- Event ID 10016 is a DistributedCOM error in the System log about a denied Local Activation permission for a COM server.
- Microsoft states these events are usually expected and by design, and the recommended action is to safely ignore them.
- The message names the component by CLSID, the DCOM app by APPID, and the account (SID) that was denied.
- You can suppress 10016 from view with an Event Viewer filter using the CLSID, APPID, and SID.
- Editing DCOM permissions can stop the logging but Microsoft advises against it, since it can break Windows components.
Quick explanation
In simple terms
Event 10016 is Windows saying a program wasn't granted permission to start a background COM component. It looks like an error, but it's usually harmless and by design.
Technical definition
Event ID 10016 is a Microsoft-Windows-DistributedCOM error in the System log indicating that application-specific or machine-default permissions did not grant Local Activation to a principal for a COM server identified by CLSID and APPID, typically for a local call over LRPC.
Analogy
Think of a building where a worker tries a side door that's locked, then walks to the main door and gets in fine. The locked-door attempt gets written in the log, but the worker still did their job. The 10016 is that logged side-door attempt.
Definition
Event ID 10016 is a DistributedCOM (DCOM) error in the Windows System log. It records that an account was denied Local Activation permission for a COM server, identified by its CLSID and APPID. Microsoft states these events are usually expected and by design.
Event ID 10016 is a DistributedCOM (DCOM) error logged in the Windows System event log by the Microsoft-Windows-DistributedCOM source. Its message reads that the application-specific, or machine-default, permission settings don't grant Local Activation permission for a COM server application, named by a CLSID and an APPID, to a given user or SID.
DCOM, the Distributed Component Object Model, lets software components start and talk to each other, locally or across a network. When a Windows component tries to activate a COM server it isn't granted permission for, COM logs a 10016. The event names the component (CLSID), the DCOM application (APPID), and the account that was denied, and it usually notes the call came from LocalHost using LRPC.
Here's the part most guides bury. Per Microsoft's own documentation, these 10016 events are recorded when Microsoft components try to access DCOM components without the required permissions, and this is expected and by design. The code tries one set of permissions first, and if that fails it retries with another set that works. The failed first try is what gets logged, even though the operation then succeeds.
Because of that, Microsoft's recommended action is to safely ignore these events: they don't adversely affect functionality. You can suppress them from view, and you can change DCOM permissions, but Microsoft advises against editing permissions because it can cause unintended side effects.
Why it matters
Core concepts
What DCOM and COM activation are
COM lets software components interact; DCOM extends that across processes and machines, and activation starts a component.
COM, the Component Object Model, is Windows' system for building software components that talk to each other. DCOM, Distributed COM, extends that so components can start and communicate across processes and even across the network.
Activation is the act of getting a component running so a caller can use it. When a client asks for a COM object, Windows may have to start (launch) and activate the matching COM server. That start step is controlled by launch and activation permissions, and it's where a 10016 denial happens.
Example
A Windows component asks for a background service like RuntimeBroker, which must be activated to respond.
Why it matters — 10016 is an activation-permission event, so understanding activation is the key to reading it.
Local Activation and the permission types
DCOM permissions split into Local/Remote Launch, Local/Remote Activation, and Local/Remote Access Calls.
DCOM breaks permissions into launch and access, and each is split by distance. Launch and activation cover four rights: Local Launch, Remote Launch, Local Activation, and Remote Activation. Access covers Local and Remote Access Calls. A local call arrives over LRPC; a remote one over network RPC.
Event 10016 is specifically a Local Activation denial. The account tried to activate a COM server locally, over LRPC, and the permissions didn't grant that right. That narrow scope is why it rarely matters: it's a local, by-design retry pattern, not a remote breach.
Example
The event says Local Activation was not granted 'from address LocalHost (Using LRPC)'.
Why it matters — Knowing it's Local Activation, not remote access, tells you the event is low-risk by nature.
Reading the CLSID, APPID, and SID
The event names the component (CLSID), the DCOM application (APPID), and the denied account (SID).
Three identifiers carry the useful detail. The CLSID is the class ID of the COM component. The APPID is the DCOM application it belongs to. The user and SID is the account that was denied, often NT AUTHORITY\SYSTEM (S-1-5-18) or LOCAL SERVICE (S-1-5-19), sometimes a signed-in user.
In Microsoft's suppression example, these map to event data fields: param4 is the CLSID, param5 is the APPID, and param8 is the SID. You look the CLSID or APPID up in the registry or Component Services to find the friendly component name, which is how you identify the culprit when you need to.
Example
CLSID {D63B10C5-...} and APPID {9CA88EE3-...} denied to NT AUTHORITY\SYSTEM (S-1-5-18).
Why it matters — These IDs are how you identify the exact component, whether to ignore it or to act.
Why Windows logs it even when nothing breaks
COM's design tries one permission set first, logs the failure, then retries with a set that works.
Microsoft documents the cause plainly: 10016 is recorded when Microsoft components try to access DCOM components without the required permissions, and it's expected and by design. The code first tries one set of parameters, and if that fails it tries again with another. It doesn't skip the first attempt because sometimes that attempt succeeds, and when it does, it's preferable.
So the denied first attempt is logged, then the operation completes on the retry. COM records these permission failures by default, which is why a healthy machine still shows a steady trickle of 10016 errors, often right after boot.
Example
After sign-in, several 10016 errors appear for shell components, yet the desktop works normally.
Why it matters — This is the crux: the error is a logged side effect of a retry, not a sign of a real failure.
The two message variants
10016 comes as 'application-specific' or 'machine-default' permission wording, pointing to different ACLs.
The 10016 text comes in two forms. Application-specific permission settings means the COM app's own launch and activation ACL didn't grant the right. Machine-default permission settings means the computer-wide default ACL didn't grant it.
DCOM checks two levels: computer-wide limits and per-application settings. The wording tells you which ACL was in play. In both cases the practical answer is usually the same, ignore it, but the variant hints at where a permission would be changed if you ever needed to.
Example
'The machine-default permission settings do not grant Local Activation permission...' points to the computer-wide ACL.
Why it matters — The wording tells you whether the app-level or computer-wide ACL was involved.
Microsoft's recommended action: ignore it
Microsoft's documented guidance is to safely ignore 10016, since it doesn't affect functionality.
Microsoft's KB is explicit: these events can be safely ignored because they don't adversely affect functionality and are by design, and that's the recommended action. If the noise is a problem, advanced users can suppress the events from view with an Event Viewer filter.
You can also modify DCOM permissions to stop the logging, but Microsoft recommends against it, for two reasons: the errors don't affect functionality, and changing permissions can have unintended side effects. In short, the safest fix is usually no fix.
Example
An admin adds a custom-view filter to hide known 10016 entries rather than editing permissions.
Why it matters — Following Microsoft's guidance prevents risky changes that can break Windows components.
How it works
A component requests a COM server
A Windows component or app asks to use a COM object. If the matching COM server isn't already running, Windows needs to activate it, which triggers a permission check.
Request
Example — The shell asks for a packaged background component after sign-in.
DCOM checks Local Activation permission
DCOM evaluates the request against the computer-wide default ACL and the application-specific launch and activation ACL. For a local call, that's the Local Activation right, checked for the calling account.
Check ACL
Example — The account is checked for Local Activation on the target CLSID and APPID.
The first attempt is denied
By design, the code first tries with one set of parameters that the account may not have. If Local Activation isn't granted, that attempt is denied.
Denied
Example — SYSTEM or LOCAL SERVICE isn't granted Local Activation for this specific COM app.
Windows logs a 10016 error
COM records the denied attempt as Event ID 10016 in the System log, noting the CLSID, APPID, the account and SID, and that the call came from LocalHost over LRPC.
Log 10016
Example — A DistributedCOM 10016 error appears in the System log with the component's IDs.
The code retries and succeeds
The code tries again with a different set of parameters that does work, so the activation succeeds. The component runs, and functionality is not affected.
Retry OK
Example — The component activates on the second attempt and the app keeps working.
You decide: ignore, suppress, or investigate
In most cases you ignore it, as Microsoft recommends. If the noise bothers you, suppress it with a filter. Only investigate permissions when a specific app actually fails to start.
Triage
Example — An admin confirms nothing is broken and adds the event to a suppression filter.
Use cases
Triaging the event and deciding to ignore it
Helpdesk, Windows adminsConfirm the event is the by-design DCOM pattern and, in most cases, take no action.
A tech sees repeated 10016 for SYSTEM on shell components, confirms nothing is broken, and closes the ticket as expected behavior.
Benefit — Saves hours of chasing a fix that Microsoft says isn't needed.
Reducing Event Viewer noise
Admins, MSPsSuppress known 10016 entries with a custom Event Viewer filter using CLSID, APPID, and SID.
An MSP deploys a filter that hides the standard boot-time 10016 events across client machines.
Benefit — Keeps the System log readable so real errors stand out.
Identifying the COM component
Windows adminsLook up the CLSID or APPID in the registry or Component Services to name the component.
An admin resolves an APPID to RuntimeBroker and confirms it's benign.
Benefit — Turns an opaque GUID into a recognizable app so you can judge whether it matters.
Diagnosing a genuine activation failure
Windows admins, app supportUse 10016 as a clue when a specific app truly can't start, correlating time and CLSID/APPID.
A line-of-business app fails to launch, and a time-correlated 10016 names its COM server.
Benefit — Points to the exact component and account involved in a real failure.
Fixing permissions in the rare necessary case
Experienced adminsWhen an app genuinely needs the right, grant Local Activation in Component Services for that APPID.
After confirming a real failure, an admin grants Local Activation to the required account for that APPID.
Benefit — Resolves a real, confirmed activation failure for one specific application.
Benefits
Precise identification
The event names the exact component (CLSID), DCOM app (APPID), and account (SID) involved.
You can trace CLSID/APPID straight to a specific COM server.
Clear scope: local activation only
It tells you the denial was Local Activation over LRPC, not a remote access breach.
'From address LocalHost (Using LRPC)' confirms a local, low-risk context.
Low operational burden
Because it's by design and doesn't affect functionality, it usually needs no action at all.
Microsoft's recommended action is simply to ignore it.
Well documented
Microsoft publishes the cause and the recommended response, so triage is quick and consistent.
The KB spells out that the events are expected and can be safely ignored.
Suppressible without risk
You can hide the noise with an Event Viewer filter, no permission changes required.
A custom-view XML filter removes known 10016 entries from view.
Limitations
It looks like a failure but usually isn't
HighThe event is logged as an Error, so it reads as a problem, yet Microsoft says it's expected and doesn't affect functionality. The alarming wording drives unnecessary fixes.
Workaround — Confirm against Microsoft's guidance that it's by design before acting.
It doesn't show the successful retry
MediumThe event records only the denied first attempt, not the retry that succeeds, so it gives an incomplete picture of what actually happened.
Workaround — Check whether the related app or component actually works before treating it as a failure.
GUIDs aren't human-readable
LowThe CLSID and APPID are raw GUIDs. Identifying the component means looking them up in the registry or Component Services, which adds friction to triage.
Workaround — Resolve the CLSID/APPID to a friendly name via Component Services before deciding.
The Security tab is often greyed out
MediumIf you try to change permissions in Component Services, the Security tab is frequently disabled because Windows or TrustedInstaller owns the CLSID and AppID keys.
Workaround — Ownership of the registry keys must be taken first, which Microsoft still advises against doing.
Editing permissions can backfire
MediumChanging DCOM permissions to silence the log can have unintended side effects and break Windows components, which is why Microsoft recommends against it.
Workaround — Prefer ignoring or suppressing the events over changing permissions.
Architecture
There's no big system to draw here, just the DCOM activation path and where the permission check sits. A caller requests a COM object, the RPCSS and DCOMLaunch services handle activation, and DCOM checks the account against the computer-wide and application-specific ACLs. A denied Local Activation on that path is what produces a 10016. Seeing the path makes it clear the event is a checkpoint log, not a crash.
Caller (Windows component or app)
Requests a COM object, which may require activating a COM server.
The shell or a service asks for a packaged background component.
RPCSS / DCOMLaunch services
Manage COM object activation and the launch of COM servers.
DCOMLaunch starts the COM server if it isn't already running.
Permission check (two ACLs)
Evaluates the account against computer-wide default limits and the app-specific launch/activation ACL.
Local Activation is checked for SYSTEM against the target APPID.
CLSID and APPID
Identify the COM class and the DCOM application involved in the request.
CLSID {D63B10C5-...}, APPID {9CA88EE3-...}.
System event log
Records the denied Local Activation as Event ID 10016 by default.
A DistributedCOM 10016 error with the account SID and component IDs.
Data flow
A caller requests a COM object. RPCSS and DCOMLaunch attempt activation. DCOM checks the account against the computer-wide default ACL and the application-specific launch and activation ACL. If Local Activation isn't granted on the first, by-design attempt, DCOM logs a 10016 with the CLSID, APPID, and SID, then the code retries with parameters that succeed. The component runs; the log entry remains.
Integrations: Component Services MMC (dcomcnfg / comexp.msc), Windows Registry (CLSID and AppID keys), Event Viewer custom views and filters, Group Policy (DCOM machine access/launch restrictions), SIEM and log collection (for noise tuning)
Architecture limitations
Examples
Boot-time 10016 for SYSTEM or LOCAL SERVICE
After every restart, several 10016 errors appear for NT AUTHORITY\SYSTEM or LOCAL SERVICE on shell components.
This is the classic by-design case. The message shows Local Activation denied for a CLSID and APPID to a system account, from LocalHost over LRPC. The desktop and apps work normally. Per Microsoft, these are expected and safe to ignore.
10016 after IIS or app-pool restarts
On a server running IIS, DistributedCOM 10016 errors appear each time IIS or its app pools restart.
The APPID often resolves to a component like RuntimeBroker. The server runs fine otherwise. This is the same by-design pattern: a denied first attempt is logged, then the code succeeds on retry. No fix is required.
A real app that won't start
A specific application fails to launch, and a time-correlated 10016 names its COM server and account.
This is the rare case that matters. When a genuine failure lines up with a 10016 for that app's CLSID/APPID and account, the missing Local Activation right may be the cause. Here, granting the permission for that one APPID can be justified, done carefully.
Comparisons
10016 vs the DCOM hardening events vs 10036, 10037, 10038 (DCOM hardening, CVE-2021-26414)
10016 is a Local Activation permission denial and is usually benign. The hardening events 10036, 10037, and 10038 are about authentication level, not activation permission. They came from CVE-2021-26414 and KB5004442, which enforced a minimum authentication level for DCOM activation, on by default since June 2022 and mandatory since March 2023.
| Criterion | 10016 vs the DCOM hardening events | 10036, 10037, 10038 (DCOM hardening, CVE-2021-26414) |
|---|---|---|
| What's denied | Local Activation permission | Insufficient activation authentication level |
| Event IDs | 10016 | 10036 (server), 10037/10038 (client) |
| Typical action | Usually ignore | Update the app to meet the required auth level |
When to choose — If you see 10036/10037/10038, that's the hardening issue and needs a real fix; 10016 usually doesn't.
10016 vs 10009 vs 10009 (DCOM was unable to communicate)
10016 is a local activation permission log, usually benign. Event 10009, 'DCOM was unable to communicate with the computer... using any of the configured protocols,' is a remote connectivity failure, often a firewall, name resolution, or the remote host being down. That one usually points to a real problem.
| Criterion | 10016 vs 10009 | 10009 (DCOM was unable to communicate) |
|---|---|---|
| Scope | Local activation (LRPC) | Remote DCOM communication |
| Severity | Usually benign | Often a real connectivity issue |
When to choose — Treat 10009 as a network or host problem to investigate; treat 10016 as by-design noise.
Application-specific vs machine-default 10016 vs The two 10016 message variants
The same event ID appears in two forms. 'Application-specific permission settings' points to a COM app's own launch/activation ACL. 'Machine-default permission settings' points to the computer-wide default ACL. The wording tells you which ACL was checked.
| Criterion | Application-specific vs machine-default 10016 | The two 10016 message variants |
|---|---|---|
| ACL involved | Per-application (APPID) ACL | Computer-wide default ACL |
| Where you'd change it | That app in DCOM Config | COM Security limits for the computer |
When to choose — Read the wording to know which ACL is in play, though both usually just get ignored.
Myths, corrected
Myth
Event 10016 is breaking my PC or causing crashes.
Correction
Microsoft states these events are by design and don't adversely affect functionality. The operation succeeds on retry, so 10016 is almost never the cause of crashes, freezes, or slowness. Look elsewhere for those.
Why it happens: It's logged as an Error and appears in bursts, so it looks like the culprit for other problems.
Myth
You must fix every 10016 by editing DCOM permissions.
Correction
Microsoft's recommended action is to ignore these events. Editing DCOM permissions to silence them is discouraged because it can have unintended side effects and break Windows components. The safest response is usually no change.
Why it happens: Countless blog posts walk through registry and DCOM permission edits, implying a fix is required.
Myth
10016 is the DCOM hardening (CVE-2021-26414) error.
Correction
No. The DCOM hardening from CVE-2021-26414 and KB5004442 logs different events, 10036, 10037, and 10038, which are about authentication level. 10016 is a separate, older activation permission event.
Why it happens: Both involve DCOM activation, so the two very different issues get conflated.
Myth
The greyed-out Security tab is a bug.
Correction
It's expected. The CLSID and AppID registry keys are owned by Windows or TrustedInstaller, so the Security tab is disabled until you take ownership. Even then, Microsoft advises against changing these permissions.
Why it happens: People assume disabled controls mean a broken system rather than a deliberate ownership lock.
Practical implications
For admins
In most cases, ignore 10016, as Microsoft recommends. If the noise hides real errors, build an Event Viewer custom-view filter using the CLSID, APPID, and SID. Only touch DCOM permissions when a specific app genuinely fails and you've confirmed the cause.
For MSPs
Educate clients that these are benign so they don't panic at red errors. Standardize a suppression filter to cut ticket noise, and avoid mass-editing DCOM permissions across fleets, which risks breaking components.
For business
Event 10016 is not a security incident by itself and rarely needs action. The main cost is wasted support time, so the practical win is documenting it as expected and moving on.
For security
Treat 10016 as by-design noise, but stay aware that a flood tied to an unusual account or a non-Microsoft component could be worth a look. Also keep it distinct from the DCOM hardening events, which do need attention.
For end users
Invisible. End users don't see 10016, and it doesn't affect how their apps behave.
Cost impact
Direct cost is essentially zero, since the event is benign and native. The real cost is analyst and helpdesk time spent investigating or 'fixing' something that didn't need it.
Operational impact
The main impact is log noise. Manage it by filtering the known events rather than changing permissions, which keeps the System log useful without risking stability.
Decision guide
Use when
- A specific app truly fails to start and a 10016 lines up with its CLSID/APPID and account
- You're auditing or hardening and want to identify a particular COM component
- Log noise is hiding real errors and you want to suppress the known events
- You need to explain to a client or user why the red errors are harmless
Avoid when
- Nothing is actually broken and the app or component works fine
- The event is for SYSTEM or LOCAL SERVICE on standard Windows components
- You'd be mass-editing DCOM permissions just to clean up the log
- You're blaming 10016 for crashes or slowness without other evidence
Requirements
- Administrator rights to view Component Services and the registry
- The CLSID, APPID, and SID from the event to identify the component
- Ownership of the CLSID/AppID keys if you ever edit permissions (not recommended)
- Confirmation that a real failure exists before changing anything
Alternatives
- Ignore the event, per Microsoft's recommended action
- Suppress it from view with an Event Viewer custom-view filter
- Contact the application vendor if a specific app repeatedly fails
Related terms
DistributedCOM (DCOM)
The Windows technology that lets COM components start and communicate across processes and machines.
Local Activation
The DCOM right to activate a COM server locally; the specific permission a 10016 says was denied.
CLSID
The class identifier (GUID) of a COM component, shown in the 10016 message as param4.
APPID
The application identifier (GUID) of a DCOM application, shown in the 10016 message as param5.
Component Services
The MMC snap-in (dcomcnfg / comexp.msc) used to view and configure DCOM launch and activation permissions.
DCOM hardening (CVE-2021-26414)
The KB5004442 change enforcing a minimum activation authentication level, which logs events 10036, 10037, and 10038, not 10016.
Frequently asked questions
What is Event ID 10016?
Event ID 10016 is a DistributedCOM (DCOM) error in the Windows System log. It records that an account was denied Local Activation permission for a COM server, identified by a CLSID and an APPID. Microsoft says these events are usually expected and by design.
Is Event ID 10016 a problem I should worry about?
Usually not. Microsoft states these events don't adversely affect functionality and are by design, and the recommended action is to safely ignore them. They rarely cause crashes or performance issues.
What causes Event ID 10016?
It's logged when Microsoft components try to access DCOM components without the required permissions. By design, the code tries one permission set first, logs the failure, then retries with another set that works, so the denied first attempt is recorded even though the task succeeds.
How do I fix Event ID 10016?
In most cases you don't need to. Microsoft recommends ignoring it. If the noise bothers you, suppress the events with an Event Viewer filter. You can change DCOM permissions in Component Services, but Microsoft advises against it because it can break Windows components.
What are the CLSID and APPID in the event?
The CLSID is the class ID of the COM component, and the APPID is the DCOM application it belongs to. You can look either one up in the registry or Component Services to find the friendly component name and identify what triggered the event.
Can I hide or suppress 10016 events?
Yes. Advanced users can create an Event Viewer custom view and edit its XML query to suppress specific 10016 events by CLSID (param4), APPID (param5), and SID (param8). This hides the noise without changing any permissions.
Is 10016 the same as the DCOM hardening error?
No. The DCOM hardening from CVE-2021-26414 and KB5004442 logs events 10036, 10037, and 10038, which are about authentication level. Event 10016 is a separate, older activation permission event and is usually benign.
Why is the Security tab greyed out in Component Services?
Because the CLSID and AppID registry keys are owned by Windows or TrustedInstaller. You'd have to take ownership of those keys before the Security tab becomes editable, and Microsoft still recommends against changing these permissions.
Conclusion
Event ID 10016 is a DistributedCOM error in the System log that records a denied Local Activation permission for a COM server, named by its CLSID and APPID. Microsoft documents it as expected and by design: the code tries one permission set, logs the failure, then retries with one that works, so the operation succeeds even though an error is written.
The practical answer is usually to do nothing, which is Microsoft's own recommendation. If the noise is a problem, suppress the known events with an Event Viewer filter rather than editing DCOM permissions, since those changes can break Windows components. Save real investigation for the rare case where a specific app genuinely fails and a 10016 points to the cause. And don't confuse it with the DCOM hardening events, 10036, 10037, and 10038, which do need attention.
Main takeaway
If you're seeing 10036, 10037, or 10038 instead, read up on the DCOM hardening changes from CVE-2021-26414 and KB5004442. To cut log noise cleanly, a short how-to on building Event Viewer custom-view suppression filters is the natural next step.
