AppX deployment failing with access denied (Code 0x80070005) under administrator

Lysa Analyst 20 Reputation points
2026-11-10T13:10:55.8133333+00:00

Hi all,

Having a frustrating issue where an AppX package deployment fails with an access-denied error (0x80070005), even though the installation is being run from an elevated PowerShell prompt using a full Domain Admin / Local Admin account.

I'm trying to figure out why Windows is blocking the package staging or registration phase despite administrator privileges. Could this be caused by ACL permission conflicts on C:\Program Files\WindowsApps, AppLocker / Software Restriction Policies blocking the deployment identity, or a corrupted StateRepository database under AppXSvc?

Does anyone know which specific AppXDeployment-Server event logs or tracing logs provide the clearest breakdown of where the permission check is failing?

Appreciate any help!

Lysa.

Windows for business | Windows Client for IT Pros | Devices and deployment | Set up, install, or upgrade
0 comments

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-11-10T13:11:17.06+00:00

    For AppX/MSIX deployment, the clearest first diagnostics are the Event Viewer operational logs under:

    1. Event Viewer (Local) > Applications and Services Logs > Microsoft > Windows
    2. Check:
      • AppXDeployment-Server > Microsoft-Windows-AppXDeploymentServer/Operational
      • AppxPackagingOM > Microsoft-Windows-AppxPackaging/Operational

    Start with AppXDeployment-Server. If the deployment error is related to package open or staging details, AppxPackagingOM can contain additional detail.

    PowerShell can also surface the recent deployment events:

    Get-AppxLog

    For 0x80070005, the supported causes in the available guidance include:

    • insufficient permissions
    • running without the required elevation for installs that require per-machine deployment
    • antivirus or security software blocking the package file
    • file system ACLs blocking read access to the package
    • the app not being full trust, or not having the packageManagement restricted capability when calling the deployment API

    Relevant fixes called out in the guidance are:

    1. Run the install command from an elevated prompt.
    2. If installing for all users, use Add-AppxProvisionedPackage instead of Add-AppxPackage.
    3. Check read permissions on the package file, for example with icacls.
    4. Temporarily disable real-time antivirus scanning or add an exclusion for the .msix or .msixbundle file.

    The available documentation does not confirm C:\Program Files\WindowsApps ACL issues, AppLocker / Software Restriction Policies, or a corrupted StateRepository database as documented causes for this specific scenario.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Domic Vo 37,000 Reputation points Independent Advisor
    2026-11-10T14:16:41.1866667+00:00

    Hello Lysa,

    Error 0x80070005 (E_ACCESSDENIED) does not necessarily indicate insufficient administrator privileges; AppX deployment also enforces package-specific permissions, security policies, and registration requirements. I recommend starting with Event Viewer → Applications and Services Logs → Microsoft → Windows → AppXDeployment-Server → Microsoft-Windows-AppXDeploymentServer/Operational, particularly Event ID 404, which typically contains the deployment failure details, and Event ID 465 if package opening fails. Immediately after reproducing the issue, run Get-AppxLog or Get-AppxLog -ActivityId <ActivityID> in elevated PowerShell to retrieve the detailed deployment errors and identify the exact failing operation. Also check Microsoft-Windows-AppxPackaging/Operational for package-related errors and review AppLocker logs under Microsoft-Windows-AppLocker/EXE and DLL and MSI and Script if application control policies may be involved. Avoid manually modifying ACLs on C:\Program Files\WindowsApps or rebuilding the StateRepository database without evidence of corruption, as these actions can damage Windows app registration and package servicing. If the logs identify an access-denied operation, please share the corresponding Event ID, Activity ID, Windows build, and the complete deployment error so we can isolate whether the problem originates from filesystem permissions, policy enforcement, or the AppX registration infrastructure.

    If my answer is useful for you, please hit Accept the answer to support me.

    Thank you

    Domic Vo.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.