Skip to content

Return a more actionable error description when the user attempts to write to an MSIX-installation's root. #25733

Open

Description

Summary of the new feature / enhancement

I want to execute any of the commands that learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.5#known-limitations disallows: 1

  1. Register-PSSessionConfiguration

  2. Update-Help -Scope AllUsers

  3. Enable-ExperimentalFeature -Scope AllUsers

  4. Set-ExecutionPolicy -Scope LocalMachine

As an example, when I invoke Set-ExecutionPolicy -Scope LocalMachine, I see similar to:

Access to the path '$Env:ProgramFiles\WindowsApps\Microsoft.PowerShellPreview_7.6.4.0_x005F_x64__8wekyb3d8bbwe\powershell.config.json' is denied. To change the execution policy for the default (LocalMachine) scope, start PowerShell with the "Run as administrator" option. To change the execution policy for the current user, run "Set-ExecutionPolicy -Scope CurrentUser".

Considering that PowerShell knows that it's been installed with Add-AppxPackage, it knows the cause of this. Consequently, the user should be informed of the reason, or it should cite the relevant documentation.

Proposed technical implementation details (optional)

No response

Footnotes

  1. discussions/25729#discussioncomment-13676474 ↩

Activity

  1. DrusTheAxe commented on May 15, 2026

    @DrusTheAxe

    Better to solve the root issue in the first place

    #9278 (comment)

    #9278 (comment)

  2. beedell-roke commented on May 15, 2026

    @beedell-roke
    Author

    Howard Kapustein (@DrusTheAxe), I agree, albeit for first-party commandlets.

  3. DrusTheAxe commented on May 16, 2026

    @DrusTheAxe

    albeit for first-party commandlets

    Why?

  4. beedell-roke commented on May 18, 2026

    @beedell-roke
    Author

    Howard Kapustein (@DrusTheAxe), I meant that it shall be applicable solely to first-party commandlets. Third-party ones remain free to hard-code invalid paths, and because of how long those paths were valid, many likely shall continue to. Providing the developer/end-user with the ability to diagnose why these fail shall be useful in that context, so this and what you cite are not mutually exclusive.

  5. DrusTheAxe commented on May 19, 2026

    @DrusTheAxe

    @DrusTheAxe, I meant that it shall be applicable solely to first-party commandlets. Third-party ones remain free to hard-code invalid paths, and because of how long those paths were valid, many likely shall continue to. Providing the developer/end-user with the ability to diagnose why these fail shall be useful in that context, so this and what you cite are not mutually exclusive.

    True, but ultimately Set-Content $fn... and other equivalent are data driven yielding E_ACCESSDENIED, so there's not a good answer to "report this write is because you're holding it wrong vs that write is because you lack permission".

    The issue above notes 4 specific cmdlets, so yes, they could have a specific error message. Of course, the root problem is because PS is 'holding it wrong', ie a self-inflicted wound. Better to fix that, than change the error message to tell the user something they can't do anything about anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-Enhancementthe issue is more of a feature request than a bugNeeds-TriageThe issue is new and needs to be triaged by a work group.Package-MSIXIssue occurs with MSIX packageWG-Cmdletsgeneral cmdlet issuesWG-NeedsReviewNeeds a review by the labeled Working Group

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions