CO_E_RUNAS_VALUE_MUST_BE_AAA Fix: RunAs Activation Error

You're staring at CO_E_RUNAS_VALUE_MUST_BE_AAA and wondering why your COM+ application won't activate. I've seen this error more times than I care to count, and the culprit is almost always the same: someone set the RunAs identity to a specific user instead of leaving it at "Activate As Activator."

This error pops up when a client tries to instantiate a COM+ component, but the server-side configuration has the RunAs value pointing to a user account. The system expects the AAA (Activate As Activator) value because the component is marked as requiring activation under the caller's identity. When it finds a username, it bails with 0x80080016.

You'll see this in enterprise apps that use COM+ for middle-tier logic — think legacy VB6 components, some .NET serviced components, or third-party ERP systems. The fix is usually a 30-second change, but sometimes the registry is involved or the COM+ package got corrupted.

Let's fix it. Start with the most common cause, then move down the list if needed.

Cause 1: RunAs is Set to a Specific User in Component Services

The number one reason for this error is that the COM+ application's identity is set to "This user" instead of "Interactive user" or "The interactive user." When the component is configured to run as the activator (which is the default for most components), you can't override that with a fixed account at the application level.

Here's the fix:

1. Open Component Services — press Win+R, type dcomcnfg, hit Enter.
2. Expand Component Services > Computers > My Computer > COM+ Applications.
3. Find the problematic application (it might have a name like "MyApp" or something cryptic). Right-click it and select Properties.
4. Go to the Identity tab.
5. You'll see three radio buttons: "Interactive user," "This user," and "The interactive user." If "This user" is selected, that's your problem.
6. Change it to Interactive user — that's the same as "Activate As Activator" for most purposes.
7. Click OK and restart the application (right-click the app in the list, select Shut down, then start it again).

If the component itself has a RunAs attribute in its activation properties, you might need to tweak that too. In the same properties window, check the Activation tab and make sure "Server application" is selected and the "Run application as" is set to "The interactive user."

I've seen this happen after an admin thought they were securing the app by running it under a service account. Bad move. COM+ doesn't allow mixing per-component RunAs with a fixed application identity, and you get this exact error.

Test the client after the change. If it still fails, move on to cause 2.

Cause 2: Registry RunAs Value Points to a User SID

Sometimes the Component Services snap-in shows the correct setting, but the registry has a stale or corrupt value that overrides it. The COM+ catalog stores the RunAs information in the registry under the AppID.

Here's how to check and fix it:

1. Open Registry Editor (regedit.exe).
2. Navigate to HKEY_CLASSES_ROOT\AppID\{YourAppID}. You need the AppID of the COM+ application. You can find that in Component Services under the application's Properties, but it's easier to search for the display name.
3. Look for a value named RunAs. If it exists and contains a username or SID (like DOMAIN\User), that's causing the conflict.
4. Delete the RunAs value or change it to Interactive User (the string value should be empty or the local system account name).

Actually, the cleanest way is to delete it — the default behavior when no RunAs value exists is to run as the activator.

If you're not comfortable editing the registry, you can use the Component Services to export the application and re-import it. That often resets the registry entries.

Be careful with 64-bit vs 32-bit. If the COM+ app is 32-bit, you might need to look under HKEY_CLASSES_ROOT\Wow6432Node\AppID instead. I've wasted 20 minutes chasing that one.

After deleting the value, restart the COM+ application and test again.

Cause 3: The COM+ Application is Corrupt or Needs Re-Registration

If the first two fixes don't solve it, the COM+ package itself might be in a bad state. This happens after a botched uninstall, a partial Windows update, or when someone manually deleted files from the application's directory.

The quickest fix is to delete and recreate the COM+ application.

1. In Component Services, right-click the application and select Delete. Yes, it's that drastic, but you're going to re-add it.
2. Right-click COM+ Applications, select New > Application.
3. Click Next, select Create an empty application.
4. Give it a name and select Server application.
5. Set the identity to Interactive user (again, that's the key).
6. Finish the wizard.

If the application came from an installer, you might need to run that installer again to re-register the components. For .NET serviced components, you can use regsvcs.exe to re-register the assembly:

regsvcs /c YourAssembly.dll

That forces a new COM+ application registration and should clear out any stale settings.

One more thing: check the Windows Event Log under Application for COM+ errors around the time of the failure. Often, you'll see a more specific error code or a component name that points to the exact issue.

And if you're dealing with a distributed transaction or a load-balanced environment, make sure all servers have the same COM+ configuration. I once fixed this on one node only to have the error persist because the other node still had the bad RunAs value.

Quick Reference Table

Stick with these fixes and you'll kill this error fast. I've seen it in production dozens of times, and it's never anything more exotic than one of these three things. Good luck.