winget install from non-elevated terminal: "no app associated with this file" dialog then exits 0x800704C7

[chy5301]

Relevant area(s)

WinGet CLI

Relevant command(s)

winget install (winget upgrade is expected to hit the same code path.)

Brief description of your issue

When winget install is invoked from a non-elevated terminal for a package whose installer needs elevation (reproduced with Microsoft.PowerShell 7.6.0 → 7.6.1, which resolves to the x64 MSI), winget correctly requests UAC elevation, downloads and verifies the installer, then prints Starting package install... — but instead of launching the MSI, Windows pops up a shell dialog:

This file does not have an app associated with it for performing this action
(localized on zh-CN systems as: 该文件没有与之关联的应用来执行该操作)

Dismissing the dialog, winget exits with:

An unexpected error occurred while executing the command:
0x800704c7 : The operation was canceled by the user.

The user did not cancel anything — the dialog itself is the failure. The MSI is never handed to msiexec.

Reproduced on two independent Windows 11 x64 machines (not specific to a single environment).

Local file associations are correct and identical between the user and admin contexts, and double-clicking the exact downloaded MSI works — so this appears to be specific to winget's post-elevation launch path (likely the WinGet Package Manager Server COM surrogate) rather than to the user's file-association state.

Steps to reproduce

On a machine with Microsoft.PowerShell 7.6.0 installed:

1. Open a non-elevated terminal (plain Windows Terminal / PowerShell 5.1 / PowerShell 7 launched without "Run as administrator").
2. Run:

   winget install --id Microsoft.PowerShell
   

3. Approve the UAC prompt that appears.
4. Observe:
   • winget prints Successfully verified installer hash and Starting package install...
   • Windows displays a shell dialog: "This file does not have an app associated with it for performing this action".
   • After the dialog is dismissed, winget exits with 0x800704C7.

Full output:

> winget install --id Microsoft.PowerShell
Found an existing package already installed. Trying to upgrade the installed package...
Found PowerShell [Microsoft.PowerShell] Version 7.6.1.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Successfully verified installer hash
Starting package install...
The installer will request to run as administrator. Expect a prompt.
An unexpected error occurred while executing the command:
0x800704c7 : The operation was canceled by the user.

Expected behavior

After UAC approval, winget should launch the downloaded MSI through msiexec exactly the same way it does when invoked from an already-elevated terminal, regardless of whether the host terminal was elevated.

Actual behavior

The post-elevation launch fails at ShellExecute with a "no app associated with this file" dialog, even though:

• assoc .msi returns .msi=Msi.Package in both user and admin sessions — identical output.
• ftype Msi.Package returns Msi.Package="%SystemRoot%\System32\msiexec.exe" /i "%1" %* in both user and admin sessions — identical output.
• Double-clicking the exact file that winget downloaded into its per-package temp directory (%LOCALAPPDATA%\Temp\WinGet\Microsoft.PowerShell.7.6.1.0\PowerShell-7.6.1-win-x64.msi) from Explorer launches msiexec and shows the installer UI correctly.
• Running the same winget install --id Microsoft.PowerShell from an elevated terminal does not trigger the dialog; msiexec is invoked normally. (A separate, unrelated MSI error 1603 then occurs due to a missing C:\Windows\Installer cache entry — that is out of scope for this report.)
• The winget --info output is identical between the two machines used to reproduce.

Hypothesis: winget's auto-elevation path (COM surrogate / WinGet Package Manager Server) performs a ShellExecute of the installer in a context where the .msi ProgID cannot be resolved the same way a regular user-shell ShellExecute can. The misleading "canceled by the user" message comes from the user closing the Windows-generated "no associated app" dialog, not from any actual cancel action.

Environment

[winget --info]
Windows Package Manager v1.28.240
Windows: Windows.Desktop v10.0.26100.8246
System architecture: X64
Package: Microsoft.DesktopAppInstaller v1.28.240.0

Windows 11 IoT Enterprise LTSC 2024
  OsVersion    : 10.0.26100 (build 26100)
  Architecture : x64

Package under test:
  Id            : Microsoft.PowerShell
  Installed     : 7.6.0
  Target        : 7.6.1
  Installer used by winget: PowerShell-7.6.1-win-x64.msi
  (winget show lists Installer Type: msix, but for this machine
   winget actually selected the x64 MSI installer.)

Also reproduced on a second independent Windows 11 x64 machine with the same
winget / Microsoft.DesktopAppInstaller versions.

[github-actions]

The following issues might be duplicates:

• ShellExecuteEx that invokes a handler that uses DelegateExecute always fails #6104

AI-generated content by genai-issue-dedup may be incorrect.

[chy5301]

Thanks for the pointer from the dedup bot. I checked #6104 — the two reports touch the same code path (the ShellExecuteExW call with the runas verb in ShellExecuteInstallerHandler), but I don't think they are duplicates:

• ShellExecuteEx that invokes a handler that uses DelegateExecute always fails #6104: ShellExecuteExW succeeds but hProcess is NULL because a registered COM object with DelegateExecute intercepted the runas verb. winget then throws 0x8007029C from the !execInfo.hProcess check. No shell dialog.
• This issue (winget install from non-elevated terminal: "no app associated with this file" dialog then exits 0x800704C7 #6173): ShellExecuteExW fails at the shell level — Windows pops up a "no app associated with this file" dialog, and winget exits with 0x800704C7 only after the dialog is dismissed. .msi / Msi.Package associations resolve correctly in both user and elevated contexts, and double-clicking the same downloaded MSI works.

Happy to be corrected if a maintainer sees them as the same root cause — both do suggest the ShellExecuteExW path could use more robust fallback/reporting when the spawned process is missing for any reason.

[Delphier]

Same issue here.

[nzp]

Same issue, tried updating Powershell via WinGet.

Windows 11 Enterprise, Version 25H2, OS build 26200.8246, Windows Feature Experience Pack 1000.26100.297.0. Last night Windows Update installed KB5083769 and KB5082417. Same winget --info output regarding versions as the OP has.

[Offby0ne]

Having the same issue trying to update PowerShell from 7.6.0 to 7.6.1.0

winget --info
Windows Package Manager v1.28.240
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.26200.8246
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.28.240.0

[stephengillie]

Exit code analysis:

Hex	Dec	InvDec	Symbol	Description
800704C7	-2147023673	2147943623	ERROR_CANCELLED	Cancelled by user

I'm guessing that the "user" here might be the installer, but the meaning and token of this exit code might be different in this situation.

[denelon]

There are a few complexities here.

Did the devices have the MSI or the MSIX variation (or both) of PowerShell installed?
Did the user run winget install Microsoft.PowerShell or winget upgrade Microsoft.PowerShell

Running winget upgrade Microsoft.PowerShell should result in WinGet finding the installed version (MSI or MSIX) and upgrading it.
Running winget install Microsoft.PowerShell on a device with the MSI would find the MSIX variation "first" as the preferred installer and perform a side by side install of the packaged version, and it would create the App Execution Alias.

If the terminal is running PowerShell and an attempt was made to upgrade the MSI version while the user is running it, that's likely a reason the cancel error would be seen becuse it's not logical to upgrade the binary while it's "running".

[Offby0ne]

It's the same behavior whether using upgrade or install. I've successfully upgraded the last several versions by using install. This is the first time I'm having this issue with it.

winget upgrade Microsoft.PowerShell
Found PowerShell [Microsoft.PowerShell] Version 7.6.1.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Successfully verified installer hash
Starting package install...
The installer will request to run as administrator. Expect a prompt.
An unexpected error occurred while executing the command:
0x800704c7 : The operation was canceled by the user.

[mgua]

yesterday i hed the problem as described in upgrading powershell. problem was impacting both commands winget upgrade and winget install. did not reboot. This morning i just retried winget install and went thru without errors

 ~#@❯ winget install --id Microsoft.PowerShell --source winget
Found an existing package already installed. Trying to upgrade the installed package...
Found PowerShell [Microsoft.PowerShell] Version 7.6.1.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Successfully verified installer hash
Starting package install...
The installer will request to run as administrator. Expect a prompt.
An unexpected error occurred while executing the command:
0x800704c7 : The operation was canceled by the user.

... wait 12 hours... did not reboot.

 ~#@❯ winget install --id Microsoft.PowerShell --source winget
Found an existing package already installed. Trying to upgrade the installed package...
Found PowerShell [Microsoft.PowerShell] Version 7.6.1.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Successfully verified installer hash
Starting package install...
The installer will request to run as administrator. Expect a prompt.
Successfully installed
 ~#@❯

[nzp]

Today it worked for me too, without any problem. I did reboot in the meantime, though.

[denelon]

We found an issue related to elevation. We mitigated it with a small modification to the manifest (elevation setting), and we're digging in to see what changed.