Installing 7zip on Windows on Arm installs x64 version

[bitcrazed]

Relevant area(s)

WinGet CLI

Relevant command(s)

winget install

Brief description of your issue

When installing 7zip.7zip on freshly re-paved Windows Arm Dev Kit running Qualcomm 8Cx Gen3 Arm processor, winget installs the x64 version of 7zip even though there is an ARM64 version listed in its manifest

Steps to reproduce

winget install 7zip.7zip on Arm based machine.

Expected behavior

Expected (when forced via --architecture flag):

C:\> winget install 7zip.7zip --architecture arm64
Found 7-Zip [7zip.7zip] Version 26.02
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://github.com/ip7z/7zip/releases/download/26.02/7z2602-arm64.exe
  ██████████████████████████████  1.51 MB / 1.51 MB
Successfully verified installer hash
Starting package install...
Successfully installed

Actual behavior

Actual:

C:\> winget install 7zip.7zip
Found 7-Zip [7zip.7zip] Version 26.02
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://github.com/ip7z/7zip/releases/download/26.02/7z2602-x64.msi
  ██████████████████████████████  1.90 MB / 1.90 MB
Successfully verified installer hash
Starting package install...
Successfully installed

Environment

Windows Package Manager (Preview) v1.30.90-preview
© 2026 Microsoft. All rights reserved.

Windows: Windows.Desktop v10.0.27975.984
System Architecture: Arm64
Package: Microsoft.DesktopAppInstaller v1.30.90.0

WinGet Directories
-----------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diag…
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\sett…
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads
Configuration Modules              %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
ConfigurationProcessorPath                Disabled
DefaultProxy                              Disabled

[github-actions]

Possible duplicate(s):

Thank you for submitting this issue.

The issue(s) below may already track your request or bug. Please take a look — if one of them matches, give that issue a 👍 and close this one as a duplicate. Older or curated issues are preferred as the canonical one to follow.

• x64 version of winget does install x64 packages on arm system, instead of the arm variant #2731 — x64 version of winget installs x64 packages on ARM system instead of the ARM variant — describes the same root cause
• Updating OpenJS.NodeJS tries to install x64 version on ARM64 system #3695 — winget tries to install x64 version on ARM64 system when updating a package — same behavior with a different package

Template: msftbot/duplicate/surfaced by Duplicate Surfacing

[DandelionSprout]

Checking real quick, a temporary workaround would be to use winget install 7zip.7zip --installer-type wix -a arm64

[Zocker1999NET]

Checking real quick, a temporary workaround would be to use winget install 7zip.7zip --installer-type wix -a arm64

that does not make sense, at least the newest manifest for version 26.02 does not provide an installer for arm64 with type WiX, see . Probably adding -a arm64 is the only needed flag (the same that the issue author suggested).

In general, to me this seems to be the issue that winget here prefered to choose an MSI/WiX installer for a different architecture than choosing an exe installer for the correct architecture.

So winget install 7zip.7zip --installer-type exe could maybe also be a vialable workaround? (I have no arm64 machine here to test that myself)

[DandelionSprout]

Right, good point. I was probably a bit too quick to check at the time.

[SpecterShell]

I think it is the InstallerLocale added to the MSI/WiX installer entries in the recent PRs makes WinGet prefer en-US installers over the others?

[DandelionSprout]

Sounds likely.

[Trenly]

Rich Turner (@bitcrazed) - A few questions

1. Does the same thing happen when using Winget v1.28 instead of v1.29 or v1.30 ?
2. Can you provide the Winget logs from winget install 7zip.7zip --verbose --logs (using your current version, v1.30) so that the installer selection process can be seen in the log files?

[Trenly]

I think it is the InstallerLocale added to the MSI/WiX installer entries in the recent PRs makes WinGet prefer en-US installers over the others?

I don't think it would be the installer locale, though it could be. More likely to be the installer type - MSI perferred over EXE. There's probably nothing indicating that architecture should be a higher applicability filter than installer type

[bitcrazed]

Kaleb Luedtke (@Trenly) - Requested logfile using that command-line is in this gist.

Looks like it's just defaulting to pulling-down x64.

Could it be that the arch selection is performed in order of x64 ... x86 ... arm64 rather than matching arch?