Standard users cannot launch WinAppSDK apps: Singleton package Access Denied (0x80070005)

[SharpDevSa]

Describe the bug

An MSIX packaged application built with WinAppSDK fails to launch when executed by a standard, low-privileged user. The application only launches successfully if it is explicitly run as an administrator.

Troubleshooting revealed that this issue is tied to the Microsoft.WindowsAppRuntime.Singleton package. Event logs show access denied errors (0x80070005) related to the provisioning of MicrosoftCorporationII.WinAppRuntime.Singleton for the standard user. The installation/update process does not fail outright, but permission management is corrupted, preventing the app from starting for non-admins.

When attempting to install or provision the application as a standard user, the Appx deployment server logs record the following errors:

AppX Deployment operation failed for package <App_Name>_<Version>_x64__<Hash> with error 0x80070005. The specific error text for this failure is: Deployment operation failed.

Started deployment Add operation on a package with main parameter <App_Package_Name>.msix and Options ForceApplicationShutdownOption,ForceTargetApplicationShutdownOption,ForceUpdateFromAnyVersion,NormalPriorityRequest and 0. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.

Additionally, there is a specific warning related to the WinAppRuntime Singleton package not finding user-specific files:

MicrosoftCorporationII.WinAppRuntime.Singleton_8000.879.2017.0_x64__8wekyb3d8bbwe : C:\Program Files\WindowsApps\MicrosoftCorporationII.WinAppRuntime.Singleton_8000.879.2017.0_x64__8wekyb3d8bbwe\microsoft.system.package.metadata\S-1-5-21-[Redacted_User_SID]-1002-MergedResources-*.pri : No user-specific merged files found

AppXSVC Queue Jamming:
Further investigation of the Event Viewer revealed Information and Warning logs showing that the AppXSvc (Deployment Service) fails to clear out older packages due to locked files (e.g., throwing a 0x5 Access Denied error when trying to delete files in C:\Program Files\WindowsApps\Deleted). Because the deployment service cannot process the locked files, the queue jams, causing subsequent MSIX deployments (like the WinAppRuntime Singleton) to fail their permission management processes.

Steps to reproduce the bug

Note: We have not found a way to reproduce this issue locally. It occurs intermittently in specific client environments, making it difficult to reproduce on demand.

1. Deploy an MSIX packaged application built with WinAppSDK 1.8 (or newer) via Intune or the Microsoft Store.
2. Log into Windows with a standard, non-administrator user account.
3. Attempt to launch the application normally.
4. The application briefly attempts to start and immediately closes without opening the UI.
5. Right-click the application and select "Run as administrator" – the application successfully launches.

Expected behavior

The application and its associated WinAppSDK runtime components should provision correctly and launch for standard users without requiring elevated administrator privileges.

Screenshots

No response

NuGet package version

1.8.260209005

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 24H2 (26100, June 2025 Update)

IDE

Visual Studio 2022, Other

Additional context

• The issue persists even if we try to install the app using the latest version of the WinAppSDK (version 2.3.1).
• The issue persists even if the C:\Program Files\WindowsApps\Deleted directory is forcibly cleared and AppXSvc is restarted.
• WinUI 3 Gallery installed from the Microsoft Store exhibits the exact same behavior on affected machines (installs successfully but fails to run as a standard user).

Workarounds Discovered

Our team found two ways to bypass or fix this issue:

Workaround 1: Manual Singleton Provisioning
Downloading the Microsoft.WindowsAppRuntime.Singleton.msix (from the 1.8 redistributable) and forcing a manual provision via PowerShell for the low-privileged user restores functionality:

Add-AppxProvisionedPackage -Online -PackagePath "C:\Path\To\Singleton.msix" -SkipLicense
Add-AppxPackage -RegisterByFamilyName -MainPackage "MicrosoftCorporationII.WinAppRuntime.Singleton_8wekyb3d8bbwe"

Workaround 2: Downgrading WinAppSDK
Downgrading our project's WinAppSDK version from 1.8.260209005 back to 1.7.250401001 completely resolves the issue.

[lauren-ciha]

Thank you for filing an issue! Could you please share the event logs you have with us and/or submit this issue through Feedback Hub (press [Windows key]+[F])? If you submit the issue on Feedback Hub, share the link here so we can track your issue more effectively on our end. When submitting, please select "Developer Platform" as the category and "Windows App SDK" as the sub-category.

Edit: Also, is the app full trust or have the packageManagement restricted capability? A common cause for 0x80070005 ACCESS_DENIED is missing one of these capabilities.

[SharpDevSa]

Unfortunately, we are currently unable to submit this issue through the Feedback Hub because we cannot reproduce it locally. We plan to ask the affected customers to submit it from their machines. If they agree to do so, I will share the link here.

The app runs in full trust mode:

<Capabilities>
     <rescap:Capability Name="runFullTrust" />
</Capabilities>