CO_E_NO_SECCTX_IN_ACTIVATE 0x8000402B Fix for COM+ Apps

What Actually Triggers 0x8000402B

You'll see this error when a COM+ component calls IObjectControl::Activate() or Deactivate() and tries to check the caller's security token — but there isn't one. COM+ expects a security context to be present during those lifecycle methods. If something clears it or never sets it, you get 0x8000402B (CO_E_NO_SECCTX_IN_ACTIVATE).

I've seen this most often in two places: custom .NET COM+ components running under IIS, and legacy VB6 COM+ apps that were moved to a newer server. One client had a loan processing app that worked fine for years until they upgraded from Windows Server 2012 to 2019 — then every second transaction threw this error.

Cause #1: Missing or Misconfigured Security Role in COM+ Application

This is number one by far. The COM+ component's security settings require impersonation, but the role isn't set up right. When IObjectControl fires, COM+ tries to grab the security context for the calling user — if that user isn't in a role, or roles are disabled, the context comes back empty.

Here's what to check:

1. Open Component Services (run dcomcnfg).
2. Go to Component Services > Computers > My Computer > COM+ Applications.
3. Right-click your app and select Properties.
4. Go to the Security tab.
5. Make sure Enforce access checks for this application is checked.
6. Then go to the Roles folder. If there are no roles defined, the security context can't be resolved. Add at least one role (like Users).
7. Go to the Components folder, find your component, right-click, Properties > Security, and make sure the role is allowed.

The kicker: if your app was installed through a script, roles might be missing entirely. I had a client whose deployment script skipped role creation — every component silently failed until we added them back. After that, the error disappeared.

Cause #2: Impersonation Level Set to Anonymous or None

Even if roles are correct, COM+ needs an impersonation level of at least Impersonate to build a security context. If the calling process (like IIS or a Windows service) passes Anonymous or Identify, COM+ can't create the context in IObjectControl.

Fix this in two places:

• In IIS (if your COM+ is called from ASP.NET): Open IIS Manager, select your application pool, go to Advanced Settings > Process Model > Identity. Set it to ApplicationPoolIdentity or a specific domain account. Then in your web.config, add <identity impersonate="true" userName="yourdomain\user" password="pass" />.
• In Component Services: Right-click your app, Properties > Security. Under Impersonation level, choose Impersonate (or Delegate if needed).

One trick: when IIS calls COM+, the identity running the app pool must match what COM+ expects. I had a case where the app pool ran as NetworkService, but COM+ required a domain account. Changed it to the domain account and the error vanished.

Cause #3: The Component Itself Is Calling Security Functions Outside IObjectControl

Sometimes the error is in the code. A developer might call CoGetCallContext, ISecurityProperty, or IServerSecurity inside IObjectControl_Activate or _Deactivate — but those methods run before the security context is fully set. COM+ doesn't guarantee a security context there.

Fix: Move any security context calls out of IObjectControl. Instead, do them inside the actual method calls (like DoSomething()). For example, in VB6 or .NET COM+:

' BAD: In IObjectControl_Activate
Private Sub IObjectControl_Activate()
    Dim sec As IServerSecurity
    Call CoGetCallContext(IServerSecurity, sec) ' Throws 0x8000402B
End Sub

' GOOD: In your main method
Public Sub DoSomething()
    Dim sec As IServerSecurity
    Call CoGetCallContext(IServerSecurity, sec) ' Works fine here
End Sub

If you can't edit the code, you're stuck with the first two causes.

Quick-Reference Summary Table