winget: "The system cannot execute the specified program."

[exoosh]

Brief description of your issue

Ran into this issue right now when winget worked last week. Possibly related to #1474.

I can rule out that this is about the execution aliases, because WinDbgX.exe and wt.exe work as expected. For further context, I run this from an elevated (using SuRun) prompt with a member of the BUILTIN\Administrators alias, but not BUILTIN\Administrator.

The exact same scenario worked last week, but that was before the latest Windows Update run.

The Event Viewer (Application log) shows for each instance of winget failing to launch:

Faulting application name: svchost.exe_AppXSvc, version: 10.0.19041.4355, time stamp: 0x9ce47784
Faulting module name: appxdeploymentserver.dll, version: 10.0.19041.5072, time stamp: 0x559cd44d
Exception code: 0xc0000005
Fault offset: 0x00000000001fd08b
Faulting process id: 0x4624
Faulting application start time: 0x01db3b25c64d9a03
Faulting application path: C:\windows\system32\svchost.exe
Faulting module path: c:\windows\system32\appxdeploymentserver.dll
Report Id: 01d68cfc-1d6c-4ded-b09c-a25faf16342e
Faulting package full name: 
Faulting package-relative application ID: 

For reference, that's a STATUS_ACCESS_VIOLATION. So the issue isn't the execution alias or the permissions or any such thing in my case.

Since the service starts on-demand it's always a fresh process anyway, so the fault is somewhere in the program (or in my Windows image). But the typical routine of sfc /scannow and dism followed by a reboot also don't resolve it:

C:\>dism /Online /Cleanup-Image /ScanHealth

Deployment Image Servicing and Management tool
Version: 10.0.19041.3636

Image Version: 10.0.19045.5131

[==========================100.0%==========================] No component store corruption detected.
The operation completed successfully.

C:\>dism /Online /Cleanup-Image /RestoreHealth

Deployment Image Servicing and Management tool
Version: 10.0.19041.3636

Image Version: 10.0.19045.5131

[==========================100.0%==========================] The restore operation completed successfully.
The operation completed successfully.

Due to the failure early on I cannot even attach. WinDbgX bails before it gets to this point.

PS: I think I may never quite fathom why a basic application like winget had to be packaged up as store app which caused it to assume some weird Xaml-package dependency and having to go through hoops with execution aliases. This could literally have been a native application that runs without any pain on a wide range of Windows versions (including Server editions) and has no prerequisites other than system DLLs and an internet connection.

Steps to reproduce

I have no idea whether and how anyone else would reproduce this.

Expected behavior

I expected winget to launch.

Actual behavior

The system cannot execute the specified program. was shown by the program attempting to launch winget.

Environment

Unable to retrieve this info for — hopefully — obvious reasons.

[exoosh]

The attempt to repair as outlined in this comment fails as well. In particular the last step:

$ Repair-WingetPackageManager -force -latest -verbose -AllUsers
VERBOSE: Creating MTA thread
VERBOSE: Running winget.exe with --version
VERBOSE: 'winget.exe' Win32Exception An error occurred trying to start process 'winget.exe' with working directory 'C:\'. The file cannot be accessed by the system.
VERBOSE: Program 'winget.exe' failed to run: StandardOutputEncoding is only supported when standard output is redirected..
VERBOSE: Integrity category type: AppInstallerNoLicense
VERBOSE: Downloading https://github.com/microsoft/winget-cli/releases/download/v1.9.25200/DesktopAppInstaller_Dependencies.json
VERBOSE: Size 264 bytes
VERBOSE: Executing Appx cmdlet Get-AppxPackage -Name Microsoft.VCLibs.140.00.UWPDesktop
VERBOSE: Microsoft.VCLibs.140.00.UWPDesktop is lower than minimum required version [14.0.33728.0]: Microsoft.VCLibs.140.00.UWPDesktop_14.0.33519.0_x64__8wekyb3d8bbwe
VERBOSE: Microsoft.VCLibs.140.00.UWPDesktop x64 dependency satisfied by: Microsoft.VCLibs.140.00.UWPDesktop_14.0.33728.0_x64__8wekyb3d8bbwe
VERBOSE: Executing Appx cmdlet Get-AppxPackage -Name Microsoft.UI.Xaml.2.8
VERBOSE: Microsoft.UI.Xaml.2.8 is lower than minimum required version [8.2310.30001.0]: Microsoft.UI.Xaml.2.8_8.2306.22001.0_x64__8wekyb3d8bbwe
VERBOSE: Microsoft.UI.Xaml.2.8 x64 dependency satisfied by: Microsoft.UI.Xaml.2.8_8.2310.30001.0_x64__8wekyb3d8bbwe
VERBOSE: Downloading https://github.com/microsoft/winget-cli/releases/download/v1.9.25200/Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle
VERBOSE: Size 236859576 bytes
VERBOSE: Downloading https://github.com/microsoft/winget-cli/releases/download/v1.9.25200/7fdfd40ea2dc40deab85b69983e1d873_License1.xml
VERBOSE: Size 2688 bytes
VERBOSE: Failed installing bundle via Add-AppxProvisionedPackage System.Management.Automation.CmdletInvocationException: The remote procedure call failed.

 ---> System.Runtime.InteropServices.COMException (0x80073CF9): The remote procedure call failed.

   at System.Management.Automation.MshCommandRuntime.ThrowTerminatingError(ErrorRecord errorRecord)
   --- End of inner exception stack trace ---
   at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input)
   at System.Management.Automation.PowerShell.Worker.ConstructPipelineAndDoWork(Runspace rs, Boolean performSyncInvoke)
   at System.Management.Automation.PowerShell.CoreInvokeHelper[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
   at System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
   at System.Management.Automation.PowerShell.Invoke(IEnumerable input, PSInvocationSettings settings)
   at Microsoft.WinGet.Client.Engine.Helpers.AppxModuleHelper.<>c__DisplayClass51_0.<AddProvisionPackageAsync>b__0()
   at Microsoft.WinGet.Common.Command.PowerShellCmdlet.Wait(Task runningTask, PowerShellCmdlet writeCmdlet)
--- End of stack trace from previous location ---
   at Microsoft.WinGet.Common.Command.PowerShellCmdlet.WaitMainThreadActionCompletion()
   at Microsoft.WinGet.Common.Command.PowerShellCmdlet.ExecuteInPowerShellThread(Action action)
   at Microsoft.WinGet.Client.Engine.Helpers.AppxModuleHelper.AddProvisionPackageAsync(String releaseTag)

There are events in parallel in the Application log, showing AppXSvc failing (see original report here).

@n5ke: FYI

[n5ke]

Just to confirm you rebooted after changing the permissions (no idea why that was necessary but it was) and you are running these as a user member of the administrators group -and maybe it matters- from an elevated powershell

Both the eventlog errors and the command line output we were seeing were exactly the same as you, so I'm out of ideas why it seemed to work on multiple windows systems for us but not you :(

[exoosh]

Just to confirm you rebooted after changing the permissions (no idea why that was necessary but it was) and you are running these as a user member of the administrators group -and maybe it matters- from an elevated powershell

Affirmative.

Both the eventlog errors and the command line output we were seeing were exactly the same as you, so I'm out of ideas why it seemed to work on multiple windows systems for us but not you :(

Well, it was a lead and it's definitely something I'll look to hone further.

As a side-note: the tinkering with the SDs messed up WinDbgX and Teams.

[ZachEDecker]

Same issue as above. Turns out pending Win updates was the issue. Rebooted and updated and everything's back to working normally.

[exoosh]

At least reboots don't seem to make a difference for me. So it's probably not a pending Windows Update. Also, the change of the SDs on the directories messed up several of the installed store apps. For WinDbgX and Teams the Repair feature (via Windows Settings) helped.

For WinGet there is no option to repair, the option to Reset fails and advises to retry and the Uninstall option fails with 0x80073CFA (ERROR_REMOVE_FAILED, "Removal failed. Please contact your software vendor.") ... which I am already doing with this ticket — contacting the vendor, that is.

@ZachEDecker are you running Windows 11 24H2 perchance (or Server 2025)? Asking because they have the new hotpatching feature enabled and there it could make sense that it behaves oddly without a reboot.

[ZachEDecker]

At least reboots don't seem to make a difference for me. So it's probably not a pending Windows Update. Also, the change of the SDs on the directories messed up several of the installed store apps. For WinDbgX and Teams the Repair feature (via Windows Settings) helped.

For WinGet there is no option to repair, the option to Reset fails and advises to retry and the Uninstall option fails with 0x80073CFA (ERROR_REMOVE_FAILED, "Removal failed. Please contact your software vendor.") ... which I am already doing with this ticket — contacting the vendor, that is.

@ZachEDecker are you running Windows 11 24H2 perchance (or Server 2025)? Asking because they have the new hotpatching feature enabled and there it could make sense that it behaves oddly without a reboot.

Running Win10 22H2. Looking through the updates that installed the only thing that looks remotely related is Servicing Stack 10.0.19041.5071. The rest were just .NET and SQL updates.

[dlong500]

Just throwing this out there in case it helps anyone else. I was having issues with not only winget but also other MS Store apps over the past week and it turns out at least my issue was resolved by installing the latest version of Windows App SDK (v1.6.3) that was just released a few days ago. See the thread here: microsoft/WindowsAppSDK#4881

Looks like the source of the issue (at least my issue) was a faulty Windows App SDK 1.6.2 that was pulled, but if it got installed it messed up all sorts of things. The thread above details some steps to fix the issue but the easiest method was to install the newly release App SDK v1.6.3.

[ClausAndersen]

Just throwing this out there in case it helps anyone else. I was having issues with not only winget but also other MS Store apps over the past week and it turns out at least my issue was resolved by installing the latest version of Windows App SDK (v1.6.3) that was just released a few days ago. See the thread here: microsoft/WindowsAppSDK#4881

Lucky you! I came here to say the same thing but having less luck. I have updated to 1.6.3 but still have the samme issue with "The system cannot execute the specified program".

I then try updating winget using:
Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle

This is from the latest current release v1.9.25200.

But on my system I am told I alread have a newer version. I think this is due to the 1.6.3 SDK being installed and the MSIX bundle being selfcontained. This is the same issue I have with Windows Terminal and created microsoft/terminal/issues/18237

I think it would but beneficial if a new self-contained MSIX bundle was built using SDK 1.6.3

[ClausAndersen]

I learned from the Windows Teminal issue that they where impacted by the SDK problem but not it is not self-contained.

After fixing Windows Terminal winget did still not work (as expected) but I was able to install using:

Add-AppxPackage .\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle

Notice that I did not need -ForceUpdateFromAnyVersion. Maybe it was enough that is was used for Windows Terminal. Or maybe you should try with:

Add-AppxPackage .\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle -ForceUpdateFromAnyVersion

This need to be done from Windows Powershell - not Powershell 7.