The 30-Second Fix: Restart the COM Infrastructure
What's actually happening here is that the COM runtime's security check failed—your app tried to call a COM interface, but the system's access control decided the caller doesn't have the right to talk to that component. Half the time, the underlying problem is that some COM-related service got stuck or crashed. You'll see this error pop up in Windows Event Viewer under Application or System logs, or as a crash dialog from something like Windows Search, a third-party app, or even the Settings app itself.
Open an admin Command Prompt—hit Win+X, choose Terminal (Admin). Then run:
net stop DcomLaunch && net start DcomLaunch
net stop RpcSs && net start RpcSs
The DcomLaunch service is the DCOM Server Process Launcher. It's the one that spawns COM server processes. If it's hung, any COM call that requires a new activation will fail with this exact error. RpcSs is the Remote Procedure Call service—COM lives on top of RPC. Restarting both in that order flushes stuck activation requests. This takes ten seconds. If your error goes away, you're done. If not, move on.
The 5-Minute Fix: Adjust DCOM Permissions
If restarting services didn't help, the issue is almost certainly a permissions mismatch in the Component Services console. A COM server was registered with specific launch and access permissions, and your app (or the user context it runs under) doesn't match those entries.
Press Win+R, type dcomcnfg and hit Enter. This opens the Component Services snap-in. Expand Component Services → Computers → My Computer → DCOM Config. You'll see a long list of COM components. The one causing the trouble might not be obvious—look for the application that threw the error and figure out which COM object it's trying to activate. Common culprits: Microsoft Windows Search, Shell Windows Runtime, or any third-party COM server.
Right-click the problematic component, choose Properties. Go to the Security tab. You'll see three sections: Launch and Activation Permissions, Access Permissions, and Configuration Permissions. For each, select Customize and click Edit.
For the user account that's failing (could be NETWORK SERVICE, LOCAL SERVICE, or a specific user), add them explicitly with Allow checked for Local Launch, Local Activation, Remote Launch, and Remote Activation if needed. Also grant them Local Access and Remote Access in the Access Permissions section.
The reason this works: COM checks two levels of ACLs—the launch permission (can you start the COM server?) and the access permission (can you talk to it once it's running?). If either check fails, AccessCheck returns false, and you get 0x8001012A. Adding the user to both security descriptors fixes it.
After making changes, restart the failing app or service. Don't bother restarting the whole machine—COM caches permissions in the runtime, and the next activation attempt will re-evaluate.
The 15+ Minute Fix: Registry ACL Repair
Sometimes the Component Services console won't save your changes—it'll show an error like "Access Denied" or the permissions revert after a reboot. That means the underlying registry key for the COM component's security descriptor has corrupted or missing ACLs. This is rare but real. I've seen it after a botched update or a registry cleaner that went too far.
You need to find the COM CLSID first. Go back to Component Services, right-click the problematic component, Properties, and look at the General tab. The CLSID is a GUID like {00000000-0000-0000-0000-000000000000}. Write it down.
Open Regedit as administrator. Navigate to:
HKEY_CLASSES_ROOT\CLSID\{your-clsid}
Right-click that key, choose Permissions. You'll see the current ACL list. If it's empty or missing SYSTEM, Administrators, or the user that needs access, click Add and add them. For SYSTEM and Administrators, grant Full Control. For the service user (like NETWORK SERVICE), grant Read.
But the real fix often involves a second key:
HKEY_CLASSES_ROOT\AppID\{your-appid-guid}
The AppID is listed on the same Properties page in Component Services. That key holds the AccessPermission and LaunchPermission binary values. If those values are corrupt or missing, COM ignores your dcomcnfg settings entirely—it falls back to the registry values. Delete those values (or the whole AppID key) and re-create them by going back to Component Services and setting permissions again. COM will regenerate the binary blobs.
After that, restart the DcomLaunch and RpcSs services again (yes, the first fix). Then test your app. This sequence—registry ACLs, then service restart—is the nuclear option. It's saved me twice when nothing else worked.
When to Skip These Steps
If the error happens with a specific third-party app (like a printer driver or antivirus), first try reinstalling that app. The COM component might be registered incorrectly. Also check Windows Update—a known issue in Win10 21H2 caused this error for some Shell COM objects, fixed in KB5010415.
If you're a developer and you wrote the COM component yourself, the issue is likely that you called CoInitializeSecurity with a restrictive ACL, or you forgot to set EOAC_DYNAMIC_CLOAKING in your client's activation context. That's a code fix, not a registry one.