Windows become a zombie

The DCOM events described fall into two categories that are handled differently.

1. Event ID 10016: application-specific permission settings

For the CLSID/APPID pair that logs an event stating that NT AUTHORITY\LOCAL SERVICE does not have Local Activation permission:

• These 10016 events are expected and by design for many Microsoft components.
• The code pattern intentionally attempts activation with parameters that may fail first, then retries with parameters that succeed.
• Because of this pattern, the event is logged even though functionality continues normally.
• Microsoft explicitly states that these events do not adversely affect functionality and can be safely ignored.

So for the 10016-type error, this is almost certainly a symptom of normal behavior, not the root cause of the “zombie” state.

If the noise in Event Viewer is a concern, the events can be filtered out instead of changing DCOM permissions. The recommended approach is:

• In Event Viewer, create a custom view and manually edit the XML query to exclude the specific 10016 events using their parameters (param4 = CLSID, param5 = APPID, param8 = SID), as documented.
• Avoid changing DCOM permissions on these system components, because that can have unintended side effects and is not recommended.

2. Event ID 10010/10001: server did not register with DCOM within the required timeout

The events where a server “did not register with DCOM within the required timeout” indicate that a COM server process did not complete initialization in time. In the scenario described, this involves Microsoft.AAD.BrokerPlugin and likely other authentication-related components.

These events can be symptoms of a deeper problem in the OS or user profile rather than the root cause themselves. Common underlying issues include:

• Damaged or misconfigured modern app infrastructure (Store, inbox apps, AAD broker, etc.).
• Broken permissions or policies applied via Group Policy that affect COM/DCOM, app packages, or authentication components.
• Corrupted local Group Policy or registry-based policy remnants that keep reapplying bad settings.

When these components fail to initialize, the result can match the described behavior:

• Microsoft Store fails to open or load content.
• Office 365 and other Microsoft apps cannot authenticate (because the AAD broker and related background tasks are not functioning correctly).

3. Advanced troubleshooting steps

Given that standard troubleshooters and basic DCOM permission checks did not help, focus on policy/permissions and app infrastructure rather than the 10016 events themselves.

A. Treat 10016 as noise, not cause

• Do not attempt to “fix” the 10016 event by editing DCOM permissions on system components.
• Either ignore it or filter it out in Event Viewer as recommended.

DCOM event ID 10016 is logged in Windows explains that these events are by design and should be ignored rather than remediated.

B. Check for DCOM hardening-related events (10036/10037/10038)

• On newer builds, DCOM hardening (CVE-2021-26414) can expose real compatibility issues.
• Look in the System log for Event IDs 10036, 10037, or 10038:
  • 10036: server-side policy blocking low authentication level.
  • 10037/10038: client-side apps using too-low authentication level.
• If these appear around the time of the failures, they can identify a specific client application that is not compliant and causing DCOM activation problems.

If such events exist, the fix is to raise the client’s activation authentication level to at least RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in that application (usually requires vendor update or configuration change).

C. Investigate Group Policy and local policy corruption

If the environment uses Group Policy heavily (common in enterprise), misapplied or conflicting policies can break modern apps and authentication components.

Recommended approach from the modern apps troubleshooting guidance:

1. Compare with a known-good system
   • Use a reference machine in an OU with minimal or no policies applied.
   • Gradually apply the same GPOs that affect the problematic machine until the issue reproduces.
   • This helps identify which policy (or combination) breaks Store/AAD broker/Office authentication.
2. Be aware of “Not configured” vs. explicit disable
   • Moving a computer out of an OU does not automatically reset all permissions or settings.
   • A setting that was explicitly enabled remains in effect until explicitly disabled; “Not configured” does not revert it.
3. Temporarily reset local Group Policy as a diagnostic step
   • On the affected machine, from an elevated Command Prompt:

          RD /S /Q "%WinDir%\System32\GroupPolicyUsers" && RD /S /Q "%WinDir%\System32\GroupPolicy"
          gpupdate /force
     

   • Restart the computer.
   • This resets local Group Policy to default values and can help determine whether local policy corruption is contributing to the problem.
   • Note: This does not remove domain GPOs; it only clears local policy. Domain policies will reapply.

If the issue disappears after clearing local policy (and before domain GPOs reapply), local policy corruption was likely involved.

D. Check for broader DCOM/COM security misconfiguration

If certificate enrollment, WMI, or other DCOM-dependent services are also failing, verify that COM security limits have not been altered in a way that blocks required system groups.

For example, for certificate services the guidance is:

• Open Component Services → Computers → My Computer → Properties → COM Security.
• Under Access Permissions → Edit Limits, and Launch and Activation Permissions → Edit Limits, ensure that required groups (such as Certificate Service DCOM Access in that scenario) have Local/Remote Access and Local/Remote Activation as appropriate.

In the described case, similar misconfigurations could affect AAD broker or Store-related components. If a security hardening change removed necessary access for system identities (LOCAL SERVICE, NETWORK SERVICE, SYSTEM), DCOM activation could fail.

E. Avoid disabling DCOM or globally altering DCOM behavior

• Disabling DCOM or broadly changing DCOM defaults is not recommended.
• Doing so can break COM objects, COM+, certificate auto-enrollment, WMI, and many built-in and third-party components.
• The documented guidance is clear that disabling DCOM can cause loss of OS functionality and should only be considered after extensive testing, and even then is usually not workable in most environments.

4. Interpreting the “zombie” state

Given the context:

• The 10016 events are normal and not the cause.
• The “did not register with DCOM within the required timeout” events for Microsoft.AAD.BrokerPlugin and similar components are symptoms that those components cannot initialize, often due to policy, permissions, or app infrastructure corruption.
• The resulting state where Store and Office cannot authenticate is consistent with a broken modern app/authentication stack rather than a low-level DCOM failure.

A practical path forward is:

1. Ignore/filter 10016 events.
2. Check for 10036/10037/10038 DCOM hardening events and remediate any non-compliant client apps.
3. Systematically validate Group Policy and local policy using the reset method and OU-based testing.
4. Verify COM Security limits in Component Services for system identities.
5. If policies and COM security are clean but the problem persists, consider rebuilding the user profile or performing an in-place repair of Windows, as the modern app infrastructure may be corrupted beyond simple repair.

References:

• DCOM event ID 10016 is logged in Windows
• KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414)
• How to disable DCOM support in Windows
• Modern, Inbox, and Microsoft Store Apps troubleshooting guidance
• Error 0x800706ba "The RPC Server is unavailable" when you enroll a certificate
• Troubleshooting issues with system resources