You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Return a more actionable error description when the user attempts to write to an MSIX-installation's root. #25733
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.
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.
@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.
Activity
DrusTheAxe commentedon May 15, 2026
Better to solve the root issue in the first place
#9278 (comment)
#9278 (comment)
beedell-roke commentedon May 15, 2026
Howard Kapustein (@DrusTheAxe), I agree, albeit for first-party commandlets.
DrusTheAxe commentedon May 16, 2026
Why?
beedell-roke commentedon May 18, 2026
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.
DrusTheAxe commentedon May 19, 2026
True, but ultimately
Set-Content $fn...and other equivalent are data driven yieldingE_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.