`winget list` and `upgrade` do not match installed packages to available packages in configured sources

[v-chsanford]

Brief description of your issue

Description

winget list, if called without arguments for the query parameter, fails to match an installed package with its available package from a configured source. When an installed package fails to match to an available package from a configured source, the Package ID will look like “ARP\Machine\X64...”. However, running winget list <search_term> does result in the installed package matching with its appropriate available package, even if the search term is as simple as a singular letter present in the package’s ID or Name.

For example, we have Git.Git version 2.48.1 available in our private repository. We only maintain one version in our private repository and remove old versions when new versions are published. If you were to have installed Git version 2.46.0 either manually or in the past from the same private source, a simple winget list will fail to match the packages. However, winget list g will return several installed packages, including Git.Git, and match the packages properly.

Similarly, winget upgrade will fail to match packages and identify an available upgrade. However, if you run winget upgrade <search_term>, then the packages will match appropriately so long as the desired package appears in the results.

Once you’ve installed the latest version of a package from the configured source, WinGet subsequently matches packages successfully.

I've confirmed this affects Git.Git and Notepad++.Notepad++, but Microsoft.PowerShell seems to not respond to the proposed workaround.

Steps to reproduce

Environment Details

Windows 11 or Windows Server 2025

WinGet Client version 1.9.25200 (latest stable), and 1.8.1911

Private self-hosted WinGet source configured (default sources removed)

Steps

Manually install a package that is available from a configured source.

Run winget search <query> to find the package in question and confirm it is available in the configured source.

Run winget list and winget upgrade (if the installed version is older than the available version), taking note of the results

Expected behavior

winget list should show all installed packages the WinGet Client can identify, including the package we’ve installed manually, with the Package ID and Package Name aligning with what is available in the configured source

winget upgrade should detect an upgrade is available to the package in question, assuming a version older than the one available in the configured source is installed

Actual behavior

winget list fails to match installed packages with available packages, showing a Package ID pulled from the registry

winget upgrade fails to detect an available upgrade for the package in question

Environment

Windows Package Manager v1.9.25200
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22631.4317
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.24.25200.0

Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
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

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
DefaultProxy                              Disabled

[v-chsanford]

Here's a screenshot capturing all of the relevant output when reproducing the issue:

[v-chsanford]

This issue is still occurring with the latest version of WinGet and the PowerShell module, version 1.10.340.

As the related thread mentions, I'm going to see if I can update/modify some manifests in our private repo to help WinGet correlate packages accordingly.

[denelon]

I think this might still require a manifest in the source with the product code or other metadata to correlate with what was installed. You might be able to add the AppsAndFeatures entries to match what is in the registry so WinGet can correlate, but it's somewhat on a package-by-package basis.

[v-chsanford]

We've found an acceptable workaround!

• With latest version of WinGet Client and PowerShell module, Find-WinGetPackage and Get-WinGetPackage do not work with REST sources unless specifically running in PowerShell 7 as SYSTEM

• Add-WinGetSource does not work in the System context at all, and System requires use of the PowerShell module in PowerShell 7 (module doesn't work in PowerShell 5.1 and winget cli commands do not work)

• This means that it is required to define your custom REST source using the provided group policy "Additional Sources" under Computer Configuration > Administrative Templates > Windows Components > Desktop App Installer

• For good measure, we've disabled the Default and Microsoft Store sources as well via Group Policy

• Once the latest version of the WinGet client and module is installed and the group policy is configured to add the desired source, you can launch PowerShell 7 as System and have free reign of Find-WinGetPackage and Get-WinGetPackage

• This alone does not fix the package correlation issue. To work around this, we simply get all available package IDs with Find-WinGetPackage, then execute Get-WinGetPackage in a foreach loop against the specific package IDs (which somehow allows WinGet to properly correlate the available package with the installed package), then if an update is available, run Update-WinGetPackage with the specific package IDs.

I personally believe this is more likely a bug with the client's ability to correlate packages from REST sources specifically rather than a fault on the REST source or manifest themselves, as we're consistently seeing this behavior across all of our manifests despite them being thoroughly cross-checked for alignment with the community manifests that are otherwise correlating without issue.