Can't run winget.exe: "Access is denied"

[rasa]

Brief description of your issue

Typing:
c:\> winget
returns
Access is denied

I can run winget logged in as the original local administrator user. It's failing when I login as a different user who's also an local adminstrator. I've tried resetting the rights to winget.exe using takeout and icalcs /reset /c /q, but that didn't help. I've uninstalled/reinstalled it several times, but nothing helps. Can't the installer reset the rights, so it just works?

Steps to reproduce

See above.

Expected behavior

winget runs without reporting errors

Actual behavior

See above

Environment

Windows 10 x64 10.0.19042

[KevinLaMS]

Sorry to hear that.
Can you verify what WHERE returns?
Example:
C:\Users\kevinla\source\repos\winget-cli-restsource\documentation\guide>where winget
C:\Users\kevinla\AppData\Local\Microsoft\WindowsApps\winget.exe

My guess is you may not have read permission which seems odd.
Can you see the files in that folder?
Example: dir C:\Users<YOUR PATH>\AppData\Local\Microsoft\WindowsApps\

Can you run the following and provide me the output?
powershell Get-AppxPackage microsoft.DesktopAppInstaller

Finally, while we are digging into this, feel freed to file a feedback hub issue as this will produce LOGS I can make a dev look at.

[ghost]

@rasa this issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.

[ghost]

@rasa this issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.

[pefoley2]

I'm hitting an identical issue:
C:\Users\jfole>winget
Access is denied.

where winget
C:\Users\jfole\AppData\Local\Microsoft\WindowsApps\winget.exe

dir C:\Users\jfole\AppData\Local\Microsoft\WindowsApps
Volume in drive C has no label.
Volume Serial Number is 7439-9EA9

Directory of C:\Users\jfole\AppData\Local\Microsoft\WindowsApps

10/09/2021 11:41 AM

Backup
10/02/2021 10:30 PM 0 GameBarElevatedFT_Alias.exe
10/09/2021 11:36 AM Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
06/08/2021 11:37 PM Microsoft.MicrosoftEdge_8wekyb3d8bbwe
08/13/2021 06:43 PM Microsoft.SkypeApp_kzf8qxf38zg5c
10/09/2021 11:41 AM Microsoft.WindowsTerminal_8wekyb3d8bbwe
10/02/2021 10:30 PM Microsoft.XboxGamingOverlay_8wekyb3d8bbwe
04/15/2021 01:11 AM 0 MicrosoftEdge.exe
10/09/2021 11:36 AM 0 python.exe
10/09/2021 11:36 AM 0 python3.exe
08/13/2021 06:43 PM 0 Skype.exe
10/01/2021 05:00 PM 0 Spotify.exe
10/01/2021 05:00 PM SpotifyAB.SpotifyMusic_zpdnekdrzrea0
10/09/2021 11:36 AM 0 winget.exe
10/09/2021 11:41 AM 0 wt.exe
8 File(s) 0 bytes
7 Dir(s) 395,438,116,864 bytes free

powershell Get-AppxPackage microsoft.DesktopAppInstaller

Name : Microsoft.DesktopAppInstaller
Publisher : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture : X64
ResourceId :
Version : 1.16.12653.0
PackageFullName : Microsoft.DesktopAppInstaller_1.16.12653.0_x64__8wekyb3d8bbwe
InstallLocation : C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.16.12653.0_x64__8wekyb3d8bbwe
IsFramework : False
PackageFamilyName : Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
PublisherId : 8wekyb3d8bbwe
IsResourcePackage : False
IsBundle : False
IsDevelopmentMode : False
NonRemovable : False
Dependencies : {Microsoft.VCLibs.140.00.UWPDesktop_14.0.30035.0_x64__8wekyb3d8bbwe,
Microsoft.DesktopAppInstaller_1.16.12653.0_neutral_split.scale-100_8wekyb3d8bbwe}
IsPartiallyStaged : False
SignatureKind : Store
Status : Ok

Feedback Hub report filed: https://aka.ms/AAe01u7

[denelon]

@rasa have you taken a look at our troubleshooting steps? We've recently added a section with some PowerShell commands that may help resolve the issue.

[JohnMcPMS]

@pefoley2, I know it has been a while, but from your feedback logs it looks like an issue in the OS itself. I have forwarded to the correct team. Rebooting should resolve the issue if you encounter it again (and yes, I know how that sounds coming from a Microsoft employee 😄 ).

[rasa]

I still have this issue. The troubleshooting steps did not help. Additionally, on a different Windows 10 Pro x64 fully patched system, I have been getting
The system cannot execute the specified program.
for several weeks. Reinstalling doesn’t help. Rebooting doesn’t help.

[denelon]

@rasa we've released Windows Package Manager 1.3.

Is this still happening?

[rasa]

I gave up fighting installing winget months ago. I spent many many hours, but couldn't work around the access denieds and The system cannot execute the specified program.s, even after multiple rounds of rebooting, uninstalling and reinstalling. The troubleshooting steps were no help either. On multiple systems too.

Now, I simply type scoop install winget, and I never have issues. For reference, Scoop installs winget via:
https://github.com/ScoopInstaller/Main/blob/0bc53dd323e6789594032997d6ca0e91c4220f5d/bucket/winget.json#L23

I find it ironic that I had to use another packaging tool to successfully use this packaging tool. Hopefully 1.3 has addressed these issues. I will leave this issue open as others are feeling my pain, but feel free to close it, as I've moved on.

(Full disclosure: I am a scoop maintainer)

[denelon]

@rasa thanks for responding!

The irony isn't lost on me either. We've had quite a few challenges working through the incantations to get everything working correctly. There have been a mixture of issues related to the fact that winget is delivered via App Installer and we're currently depending on an update from the store. This problem should gradually go away with newer updates to both App Installer and Windows.

I'm going to go ahead and close this, but the history will be preserved for others to find. Also, it's worth noting MSIX packages aren't available to system context calls. They were designed to be registered upon interactive login, and our path forward for system / remote execution is via a COM API we're developing as a part of the Integration for Intune, third-party MDM providers, and the native PowerShell implementation.

[alinaimi]

You likely have multiple instances of winget.exe in your system’s $PATH. To resolve this, consider cleaning up your PATH variable or directly calling the correct executable file "%LOCALAPPDATA%\Microsoft\WindowsApps\winget.exe"

[rasa]

You likely have multiple instances of winget.exe in your system’s $PATH.

@alinaimi In my case, I didn't, but that might help others who encounter this issue.

[twglomski]

Since I stumbled on this while trying to automate install of .NET runtimes, I'll throw in the research I found:

Right after installing winget I was getting the Access is denied error (On Server 2022). I would try a few things, and after a while the error would go away and work normally.

This seemed strange to me as there were troubleshooting steps I would try and it would work, and when I'd try them again they wouldn't work. So I wrote a loop to attempt opening winget every 5 seconds to see if after a certain amount of time the error would go away. It turns out it did - 10 to 15 minutes after the initial install.

I checked in the Event Log to attempt to correlate this to any service starts, and I noticed the AppX Deployment service restarted right before the error went away. I tried restarting that service after install but that didn't work - only time seemed to resolve this.

IDK if this would be helpful for anyone finding this in the future. I will note that @rasa 's suggestion of using Scoop worked flawlessly. (Turned out that I didn't need the .NET runtimes, but rather the .NET web hosting pack, which I couldn't find on winget and ended up using Chocolatey for my install.)

The script I used to install, then loop over running winget until it magically started working:

Invoke-WebRequest -Uri https://aka.ms/getwinget -OutFile Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle
Invoke-WebRequest -Uri https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx -OutFile Microsoft.VCLibs.x64.14.00.Desktop.appx
Invoke-WebRequest -Uri https://github.com/microsoft/microsoft-ui-xaml/releases/download/v2.7.3/Microsoft.UI.Xaml.2.7.x64.appx -OutFile Microsoft.UI.Xaml.2.7.x64.appx
Invoke-WebRequest -Uri https://github.com/microsoft/winget-cli/releases/download/v1.6.3482/24146eb205d040e69ef2d92d7034d97f_License1.xml -OutFile 24146eb205d040e69ef2d92d7034d97f_License1.xml
Add-AppxPackage Microsoft.VCLibs.x64.14.00.Desktop.appx
Add-AppxPackage Microsoft.UI.Xaml.2.7.x64.appx
Add-AppxProvisionedPackage -Online -PackagePath Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle  -LicensePath 24146eb205d040e69ef2d92d7034d97f_License1.xml -dependencypackagepath Microsoft.VCLibs.x64.14.00.Desktop.appx
$ResolveWingetPath = (Resolve-Path "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe").Path

$then = get-date; $erroraction = 'silentlyContinue'; do {start-sleep -seconds 5;$wgr = . $resolvewingetpath\winget.exe} while (!$wgr);$now=get-date; $elapsed = $now-$then;write-output "Took $($elapsed.minutes) minutes and $($elapsed.seconds) seconds for WinGet to work. Started working at $($now)"

[fluidum]

Thank you @twglomski !

Your script lines helped getting my winget working on Windows Server 2022 Standard 21H2 (20348.2227), winget v1.6.3482

The system cannot execute the specified program.

[marioqxx]

I had the same problem. Deleting folder \Users<user>\AppData\Local\Temp\Winget - which for whatever reason had only Administrator-access-rights as descibed here:

#4704 (comment)

solved the problem for me.