| Previous | Next |
| CO_E_MISSING_DISPLAYNAME | CO_E_ELEVATION_DISABLED |
CO_E_RUNAS_VALUE_MUST_BE_AAA
The important question is not merely what the text says, but which contract was being evaluated. At this boundary, the class requested through the elevation moniker is configured with an incompatible RunAs identity instead of Activate As Activator or the launching user.
What the status narrows down
COM activation is a sequence rather than a single operation: registration lookup, SCM or surrogate selection, process startup, class-factory publication, marshaling, and finally the requested interface call. The useful evidence is the evidence from the first stage that fails; a later RPC or cleanup message can otherwise hide the original activation problem.
Do not collapse this result into a nearby status. This is not a bad password for the configured account; the identity model itself is incompatible with elevation-moniker activation. Compare lifecycle, identity, caller, and first API.
Evidence worth preserving
| Incident evidence | Question it answers |
|---|---|
| CLSID-to-AppID mapping and the AppID RunAs value | Separates contract failure from environment. |
| Elevation\Enabled, LocalizedString, and machine-wide registration view | Creates a stable before/after control. |
| Configured service/account identity and whether activation is local or remote | Tests whether the first boundary moves. |
| Client token, requested elevation level, and moniker string | Pins evidence to one attempt. |
The goal is reproducibility, not a full data dump. Prefer object IDs, configuration exports, event correlation, and redacted paths over credentials, cryptographic material, or user content.
A controlled diagnostic sequence
- Remove only the incompatible RunAs value in a test registration and compare activation; keep every other input fixed and record the first event that differs from the failing run.
- Activate the same class normally to verify that its server registration is otherwise usable; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Test the approved Activate As Activator configuration with a least-privilege client; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
A retry becomes evidence only when one controlled variable changes. In this case, if the same operation later succeeds unchanged, preserve that fact but continue checking timing, object generation, service restart, cache replacement, or policy refresh; transient success does not explain the earlier boundary.
How to read the outcome
The following decision points keep the investigation tied to the returning operation:
| Observed result | Interpretation |
|---|---|
| The minimal or known-good comparison succeeds | The control works; inspect production-specific state. |
| The control fails at the same first operation | The control also fails; inspect host/provider evidence. |
| A new HRESULT marks another boundary | The failure moved to another boundary; diagnose the new status separately rather than treating it as confirmation that the entire operation is fixed. |
Correction and proof
A defensible correction is specific to the evidence: Use the documented elevation identity configuration or redesign the privileged operation as a service with an explicit secured interface. Preserve the pre-change configuration or trace.
Close the incident only when elevated activation succeeds only for the intended class and operation, while remote or unapproved identity cases remain blocked. Repeat under the original identity and state. A different environment is comparison, not proof.
Technical references
These references define the HRESULT family and subsystem contract used above:
- Microsoft Open Specifications: HRESULT values.
- Microsoft: COM clients and servers.
- Microsoft: CoGetClassObject.
- Microsoft: COM elevation moniker.
Looking for a different code? Search another status or error code.