| Previous | Next |
| E_ELEVATED_ACTIVATION_NOT_SUPPORTED | E_FULL_ADMIN_NOT_SUPPORTED |
E_UAC_DISABLED
User Account Control is disabled, so the app activation prerequisite fails
E_UAC_DISABLED is HRESULT 0x80270252 (signed decimal -2144927150, unsigned decimal 2150040146). The value is a failure in FACILITY_SHELL (facility 39) with code field 0x0252. AllStat records the exact Windows message: “This app can't be activated when UAC is disabled.”
Why UAC matters here
This result is not a consent-prompt refusal. It means the UAC security model required by the packaged-app activation path is disabled at the system level. Microsoft’s Windows App Certification Kit documentation explicitly lists enabled UAC as a prerequisite for IApplicationActivationManager::ActivateApplication. The shell therefore stops before normal launch dispatch.
A user can be a local administrator while UAC remains enabled; that is not the same condition. Likewise, suppressing prompts through policy is not automatically equivalent to disabling the underlying mechanism. Diagnose the effective UAC configuration rather than inferring it from whether a prompt appeared.
Typical environments
- A legacy image or kiosk build disabled UAC through security policy or registry configuration.
- A troubleshooting script changed UAC settings and the required restart has not restored a supported state.
- A cloned test image carries old hardening assumptions that are incompatible with packaged applications.
- An administrator interprets “never notify” and complete UAC disablement as identical settings.
- A certification machine differs from developer workstations in local or domain security policy.
Evidence to collect
- Windows edition/build, effective UAC policy, policy source, and whether a restart is pending.
- The caller’s user, token type, integrity level, and session, so this code is not confused with elevated-context activation.
- The AppUserModelID, activation contract, and corresponding Immersive-Shell event.
- Whether all packaged apps fail or only one package fails after UAC is enabled.
- Recent security-baseline, registry, image-customization, or group-policy changes.
Recovery procedure
- Restore UAC to a supported configuration using the organization’s normal policy channel rather than an ad hoc registry edit.
- Restart Windows if the changed setting requires it, then confirm the effective policy after boot.
- Repeat activation in a normal interactive user session.
- If the HRESULT changes, continue with the new result; package registration or startup faults may have been hidden behind the prerequisite failure.
- For managed devices, correct the central policy so the problem does not return at the next refresh.
Retry and operational impact
An immediate loop cannot enable UAC and is not useful. Retry only after configuration and restart requirements are satisfied. An unattended product should surface a machine-policy prerequisite and avoid repeatedly repairing the package, because package files are not implicated by this code.
What not to conclude
E_UAC_DISABLED does not prove that the user lacks administrative rights, that the target requires elevation, or that an AppLocker rule blocked the executable. It also does not identify a corrupt package. The code is narrower: the platform activation environment lacks enabled UAC.
Practical scenario
A lab image disables UAC to support an old automation suite. Every Store app activation through the certification harness returns E_UAC_DISABLED. Re-registering individual packages has no effect. Restoring UAC through the image policy and rebooting makes activation proceed to the actual application launch stage.
Official Microsoft references
- Microsoft: COM error codes for security and setup
- Microsoft: Windows App Certification Kit launch prerequisites
- Microsoft: User Account Control settings and configuration
- Microsoft: IApplicationActivationManager::ActivateApplication
Looking for a different code? Search another status or error code.