Fix CO_E_FAILEDTOGETSECCTX (0x80010124) Security Context Error

This error code is infuriating because it's vague

You're trying to launch a COM component—maybe a custom app or an internal tool—and you hit CO_E_FAILEDTOGETSECCTX (0x80010124). The message says Unable to obtain server's security context. I've seen this in Windows 10 and 11, usually when a service or app tries to talk to a DCOM server under the wrong account. Let me save you the rabbit hole I went down the first time.

First, the real fix: Grant Launch and Activation permissions

This error almost always means the user account trying to start the COM object doesn't have the right permissions. Here's how to check and fix it:

1. Press Win + R, type dcomcnfg, hit Enter.
2. Navigate to Component Services > Computers > My Computer > DCOM Config.
3. Find the COM object that's failing. You might need to match its CLSID from the error log—look in Event Viewer under Windows Logs > System for a DCOM error with the same CLSID.
4. Right-click that object > Properties > Security tab.
5. Under Launch and Activation Permissions, click Edit.
6. Add the user or group that's running the client app (often NETWORK SERVICE, LOCAL SERVICE, or an explicit domain account). Give them Local Launch and Local Activation permissions at minimum.
7. Apply, OK everything, reboot the server or the app.

That's it. Nine times out of ten, this resolves the 0x80010124 error.

Why does this work?

CO_E_FAILEDTOGETSECCTX translates to the COM runtime couldn't create a security context for the server. In plain English: the client asked the server to start a COM object on its behalf, but the server's security system said "I don't know this user" or "this user isn't allowed to start me." By granting Launch and Activation permissions, you're telling the COM infrastructure yes, this user can start you.

I've also seen this happen when the server-side COM object runs as a specific user (configured in the Identity tab of the COM object's properties) and that user's password has changed or the account is locked out. Check that too if permissions look correct.

Less common causes and variations

If the permission fix doesn't work, look deeper:

• Distributed COM users group missing: The account launching the COM object needs to be in the Distributed COM Users group on the server machine. Add it via Local Users and Groups (lusrmgr.msc).
• Firewall blocking RPC: Windows Firewall can block DCOM traffic. Make sure the Remote Service Management and Remote Event Log Management inbound rules are enabled—these open the RPC endpoints DCOM needs. I've seen this trip up in domain-joined machines with custom firewall policies.
• Permission inheritance issues: Sometimes the COM object's permissions inherit from the machine-wide defaults. Check My Computer > Properties > COM Security tab. If the machine-wide Launch and Activation defaults are too restrictive, they override individual object permissions. I've seen admins tighten the machine defaults not realizing it breaks everything.
• User token size: Rare one, but if the user account is in many AD groups (like 1000+), the security token can overflow. The COM runtime can't build the security context. Reduce group membership or increase the token size via registry—but I'd try the obvious fixes first.

Prevention: Lock down DCOM permissions properly from the start

Here's my opinion: don't just blast open permissions. Create a dedicated service account for the COM server, add it to the Distributed COM Users group, and grant Launch and Activation only to that account and the client accounts that need it. Use Group Policy or local policy to set machine-wide COM security defaults per environment.

Also, log DCOM failures in Event Viewer (Applications and Services Logs > Microsoft > Windows > DCOM). Enable Analytic and Debug logs if you need to trace the exact CLSID and caller. That saves a lot of guessing next time.

One more thing: keep documentation of which COM objects your critical apps use. I can't tell you how many times I've seen teams scramble because no one knew a legacy component depended on a specific permission set. A simple spreadsheet with CLSID, app name, required permissions, and running account would have prevented this error from even showing up.