Skip to content

Winget incorrectly detects per-user MSI scope (No applicable update found) #3011

Open
Bug
Open
Winget incorrectly detects per-user MSI scope (No applicable update found)#3011
Bug
Labels
Area-ScopeIssue related to "machine", "user", or "system" contextCommand-UpgradeIssue related to WinGet UpgradeIssue-BugIt either shouldn't be doing this or needs an investigation.

Description

@sitiom
Ryan (sitiom)
opened on Feb 26, 2023

Brief description of your issue

I cannot upgrade packages whose MSI installers are under user scope. A No applicable update found is shown despite it showing to be available from the winget upgrade command.

Here are some examples of packages with this issue:

  • Google.IAPDesktop
  • PDFArranger.PDFArranger
  • Dummerle.Rare
  • Mu.Mu
  • RussellBanks.Komac

Steps to reproduce

  1. Install an old version of one of the packages above. For this example, we will use RussellBanks.Komac.
  2. Check available updates via winget upgrade. Komac should show up.
  3. Upgrade the package (winget upgrade RussellBanks.Komac)
  4. See No applicable upgrade found. message.

Log:

2023-02-20 21:31:17.269 [CORE] WinGet, version [1.5.441-preview], activity [{5406AEB0-B779-484D-B465-C2A2EF98C06A}]
2023-02-20 21:31:17.270 [CORE] OS: Windows.Desktop v10.0.25284.1000
2023-02-20 21:31:17.270 [CORE] Command line Args: "C:\Users\vedan\AppData\Local\Microsoft\WindowsApps\winget.exe" upgrade --id RussellBanks.Komac --exact -s winget --open-logs
2023-02-20 21:31:17.270 [CORE] Package: Microsoft.DesktopAppInstaller v1.20.441.0
2023-02-20 21:31:17.270 [CORE] IsCOMCall:0; Caller: winget-cli
2023-02-20 21:31:17.278 [CLI ] WinGet invoked with arguments: 'upgrade' '--id' 'RussellBanks.Komac' '--exact' '-s' 'winget' '--open-logs'
2023-02-20 21:31:17.278 [CLI ] Found subcommand: upgrade
2023-02-20 21:31:17.278 [CLI ] Leaf command to execute: root:upgrade
2023-02-20 21:31:17.294 [CLI ] Executing command: upgrade
2023-02-20 21:31:17.309 [REPO] Named source requested, found: winget
2023-02-20 21:31:17.325 [CORE] Examining extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2023-02-20 21:31:17.325 [CORE] Found matching extension.
2023-02-20 21:31:17.375 [REPO] Opening SQLite Index for ImmutableRead at 'C:\Program Files\WindowsApps\Microsoft.Winget.Source_2023.220.1651.303_neutral__8wekyb3d8bbwe\Public\index.db'
2023-02-20 21:31:17.375 [SQL ] Opening SQLite connection #1: 'C:\Program Files\WindowsApps\Microsoft.Winget.Source_2023.220.1651.303_neutral__8wekyb3d8bbwe\Public\index.db' [1, 40]
2023-02-20 21:31:17.377 [REPO] Opened SQLite Index with version [1.6], last write [2023-02-20 21:21:06.000]
2023-02-20 21:31:17.686 [REPO] Creating PredefinedInstalledSource with filter [None]
2023-02-20 21:31:17.686 [REPO] Creating new SQLite Index [4294967295.4294967295] at ':memory:'
2023-02-20 21:31:17.686 [SQL ] Opening SQLite connection #2: ':memory:' [6, 0]
2023-02-20 21:31:17.757 [REPO] Reading MSI UpgradeCodes
2023-02-20 21:31:17.758 [REPO] Examining ARP entries for Machine | X64
2023-02-20 21:31:17.776 [REPO] Examining ARP entries for Machine | X86
2023-02-20 21:31:17.854 [REPO] Reading MSI UpgradeCodes
2023-02-20 21:31:17.856 [REPO] Examining ARP entries for User | X64
2023-02-20 21:31:18.315 [REPO] Opening SQLite Index for ReadWrite at 'C:\Users\vedan\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft.Winget.Source_8wekyb3d8bbwe\installed.db'
2023-02-20 21:31:18.315 [SQL ] Opening SQLite connection #3: 'C:\Users\vedan\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft.Winget.Source_8wekyb3d8bbwe\installed.db' [2, 0]
2023-02-20 21:31:18.317 [REPO] Opened SQLite Index with version [1.6], last write [2023-02-20 20:30:49.000]
2023-02-20 21:31:18.406 [CLI ] Found one app. App id: RussellBanks.Komac App name: Komac
2023-02-20 21:31:18.409 [REPO] Downloading manifest
2023-02-20 21:31:18.409 [CORE] WinINet downloading from url: https://cdn.winget.microsoft.com/cache/manifests/r/RussellBanks/Komac/1.0.4/d166-RussellBanks.Komac.yaml
2023-02-20 21:31:18.459 [CORE] Download hash: 59432829da366f7f6275dad785f4b8495ab9dfc19817ecc2fb8905255038d794
2023-02-20 21:31:18.459 [CORE] Download completed.
2023-02-20 21:31:18.461 [CLI ] Starting installer selection.
2023-02-20 21:31:18.461 [CLI ] Installer [X64,burn,User,en-US] not applicable: Installer scope does not match currently installed scope: User != Machine
2023-02-20 21:31:18.461 [CLI ] Installer [X64,burn,User,en-US] not applicable: Installed package type 'msi' is not compatible with installer type burn
2023-02-20 21:31:18.479 [CLI ] Terminating context: 0x8a15002b at D:\a\_work\1\s\external\pkg\src\AppInstallerCLICore\Workflows\UpdateFlow.cpp:a6

Expected behavior

It should successfuly start to upgrade the package.

Actual behavior

A No applicable upgrade found. message is shown despite an upgrade being available.

Environment

Windows Package Manager (Preview) v1.5.441-preview

Windows: Windows.Desktop v10.0.22621.1265
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.20.441.0

Activity

  1. microsoft-github-policy-service
    added
    Needs-TriageIssue needs to be triaged
    on Feb 26, 2023

  2. Masamune3210 commented on Feb 26, 2023

    @Masamune3210
    Masamune3210
    on Feb 26, 2023

    Its telling you that no applicable update is found because the installer types and scopes are not compatible with each other.

    Upgrades are only supported if the scopes match and the installers are directly compatible with each other iirc.

  3. sitiom commented on Feb 26, 2023

    @sitiom
    Ryan (sitiom)
    on Feb 26, 2023
    Author

    Upgrades are only supported if the scopes match and the installers are directly compatible with each other iirc.

    Yes, but in this case it should match. Winget is saying that the installer is in the machine scope when it really is user scope.

  4. mdanish-kh commented on Feb 26, 2023

    @mdanish-kh
    Muhammad Danish (mdanish-kh)
    on Feb 26, 2023
    Contributor

    MSIs by default install in machine scope IIRC. To have them install in user scope, you would have to provide additional InstallerSwitches ALLUSERS=2 MSIINSTALLPERUSER=1 in the manifest.

    Ref: MSIINTALLPERSUSER Property

    You could see these switches are added to separate the two scopes in the manifest for Microsoft.RemoteDesktopClient

    But not all MSI installers (the one that comes at the top of my head is Microsoft.PowerShell) support per-user installation. So, I guess it's a matter of testing whether an MSI installer supports per-user installation, and if does you would need to add the necessary InstallerSwitches in the manifest.

  5. sitiom commented on Feb 26, 2023

    @sitiom
    Ryan (sitiom)
    on Feb 26, 2023
    Author

    The packages mentioned above are user-scoped only. See also russellbanks/Komac#103 (comment):

    That has no effect on the behavior of the installer. The install does write to that location, but the uninstall strings are still located in HKLM (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID}) image

    To confirm that the issue is still present: image

  6. sitiom commented on Feb 26, 2023

    @sitiom
    Ryan (sitiom)
    on Feb 26, 2023
    Author

    Can you point to me a per-user only MSI installer that properly places the registry in the HKCU? So far the packages that I have found all install in HKLM and have the same problem.

  7. Trenly commented on Feb 26, 2023

    @Trenly
    Kaleb Luedtke (Trenly)
    on Feb 26, 2023
    Contributor

    Komac does a per-user install but places all of its registry entries in HKLM (which is meant for machine-wide installs) so WinGet will immediately think that Komac is a machine-wide install because of this. Komac will need to place registry entries in HKCU to be considered a per-user install to WinGet.

    Russell Banks (@russellbanks)

  8. russellbanks commented on Feb 26, 2023

    @russellbanks
    Russell Banks (russellbanks)
    on Feb 26, 2023

    I invoke jPackager from the JDK for this, which uses Wix for exe's and msi's. I use InstallScope="perUser" Platform="x64", so I don't know whether this is Java or Wix that is putting it in the wrong place.

  9. sitiom commented on Feb 26, 2023

    @sitiom
    Ryan (sitiom)
    on Feb 26, 2023
    Author

    I use InstallScope="perUser" Platform="x64", so I don't know whether this is Java or Wix that is putting it in the wrong place.

    Or it's by design: https://stackoverflow.com/questions/32273217/how-and-why-installation-per-user-manages-to-write-to-hklm. Winget should have some sort of special detection for this one.

  10. Ryan (sitiom)
    changed the title [-]Cannot upgrade MSIs under user scope (`No applicable update found`)[/-] [+]Winget incorrectly detects per-user MSI scope (`No applicable update found`)[/+] on Feb 26, 2023

  11. sitiom commented on Feb 26, 2023

    @sitiom
    Ryan (sitiom)
    on Feb 26, 2023
    Author

    If it's a WIX bug then it's best to file an issue over at their repository to check if it's intentional or not. Developers of WIX are also in the process of rewriting its entire project (wixtoolset/wix4) which is currently in alpha so there might be a possibility that it might be fixed over there.

    Rob Mensching (@robmen) Sorry for the ping, but can we get your advice from here? Does Windows Installer really write to HKLM regardless of install scope, and what is the proper way to detect installation context from MSIs?

    Honeygain seems to be already deleted from winget-pkgs (microsoft/winget-pkgs#60711)

    Nullsoft installers can be fixed:

    The issue at hand here is about MSI installers.

    SumatraPDF seems to be already properly behaving now:
    image
    image

  12. robmen commented on Feb 27, 2023

    @robmen
    Rob Mensching (robmen)
    on Feb 27, 2023

    Windows Installer doesn't document its use of the registry. Use the MSI APIs, like MsiGetProductInfoExW.

  13. Stephen Gillie (stephengillie)
    added
    Issue-BugIt either shouldn't be doing this or needs an investigation.
    and removed
    Needs-TriageIssue needs to be triaged
    on Feb 27, 2023
  14. Demitrius Nelon (denelon)
    added this to the milestone on Jun 5, 2023
  15. Demitrius Nelon (denelon)
    removed this from the milestone on Nov 14, 2024

  16. denelon commented on Dec 30, 2024

    @denelon
    Demitrius Nelon (denelon)
    on Dec 30, 2024
    Collaborator

    WinGet is currently looking at registry entries to determine the scope of an installed package. I'll talk with the team about this bug today during our engineering sync meeting. I'm also going to go ahead and add this to the project to prioritize the work.

  17. Demitrius Nelon (denelon)
    added this to WinGeton Dec 30, 2024
  18. Demitrius Nelon (denelon)
    moved this to To Do in WinGeton Dec 30, 2024

  19. mdanish-kh commented on Dec 30, 2024

    @mdanish-kh
    Muhammad Danish (mdanish-kh)
    on Dec 30, 2024
    Contributor

    [Policy] Area-Scope
    [Policy] Command-Upgrade

  20. microsoft-github-policy-service
    added
    Area-ScopeIssue related to "machine", "user", or "system" context
    Command-UpgradeIssue related to WinGet Upgrade
    on Dec 30, 2024
  21. Demitrius Nelon (denelon)
    assigned
    JohnMcPMS
    on Jan 2, 2025
  22. JohnMcPMS
    removed their assignment
    on Jan 13, 2025
  23. Justin Ma (hustcer)
    added a commit that references this issue on Jul 7, 2025

    Update winget default INSTALLDIR for per-machine install path (#16026)

    a674ce2

  24. cprivitere commented on Jul 18, 2025

    @cprivitere
    Chris Privitere (cprivitere)
    on Jul 18, 2025

    Demitrius Nelon (@denelon) you added #5099 to the 1.10 milestone, but it looks like it never made it in. Since this is the source bug 5099 is a dupe of, and I'm figuring the fact that 5099 is closed led to it getting lost after moving to newer milestones, any chance you can add this to a future milestone?

  25. annsek commented on Aug 24, 2026

    @annsek
    annsek
    on Aug 24, 2026

    Are you going to finally fix it after over 3 years?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area-ScopeIssue related to "machine", "user", or "system" contextCommand-UpgradeIssue related to WinGet UpgradeIssue-BugIt either shouldn't be doing this or needs an investigation.

    Type

    Bug

    Projects

    • WinGet
      Status
      To Do

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions