cannot update apps installed with machine scope using winget in the system context

[bandizsolt]

Brief description of your issue

I installed ungoogled chromium using the following command:

winget install -e --id eloston.ungoogled-chromium --interactive --scope machine --architecture x64

or NAPS2 with:

winget install -e --id Cyanfish.NAPS2 --interactive --scope machine --architecture x64

Now, when I try to update using winget running in the system context, it doesn't recognize these applications, and as a result, it doesn't update them.

Now I don't know how to trace this back if it's an issue with the installation file, to understand what the problem might be.

Using this program (https://github.com/Romanitho/Winget-AutoUpdate), I've come to the point where winget doesn't recognize these software applications in the system context (in this issue are the details Romanitho/Winget-AutoUpdate#362). However, it's also possible that winget doesn't recognize them because something goes wrong during the installation.

Steps to reproduce

1. Install ungoogled chromium using the following command:

   winget install -e --id eloston.ungoogled-chromium --interactive --scope machine --architecture x64

2. Alternatively, install NAPS2 with:

   winget install -e --id Cyanfish.NAPS2 --interactive --scope machine --architecture x64

3. When attempting to update using winget in the system context, it fails to recognize these applications (tested with winget export), resulting in an inability to update them.

Expected behavior

The ability to update these applications in the system context.

Actual behavior

It cannot be updated with winget when using it in the system context.

Environment

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

Windows: Windows.Desktop v10.0.22631.2715
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.21.3133.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

[bandizsolt]

Could the issue be that when running winget in system context, it cannot see the correct IDs for the installed programs? As shown in the attached capture, the installed software seems to have incorrect IDs in the system context.

• For ungoogled-chromium (install ID: eloston.ungoogled-chromium), it displays: Chromium.
• For NAPS2 (install ID: Cyanfish.NAPS2), it shows: {B75B572B-2954-4D26-8986-A0D889CFA4B8}.

It only fails to display the correct ID under the system and user contexts, it shows correctly for the admin user.

[bandizsolt]

@stephengillie Could you please point me in the right direction on how to investigate what might be causing this?

[stephengillie]

Hi @bandizsolt,

Unfortunately I'm not well-informed on the specific impacts of using the SYSTEM context, and will defer to @Trenly and @denelon.

[bandizsolt]

Hi, @stephengillie, thank you very much, I just need a little guidance on where to start so I know where to begin. It would be a bit much to sift through the entire source code to find a solution for this.

[stephengillie]

I searched Issues for SYSTEM and ame across this:

• Winget as SYSTEM fails to upgrade certain packages #4332

When running as the SYSTEM user, any application information stored in a specific user profile isn’t accessible to WinGet. When looking for applications that are installed, WinGet will check the registry for application information in both the Local Machine and the current user. When running as SYSTEM, any applications installed in a specific user scope won’t be visible to SYSTEM as their information is under that specific users UID and not the SYSTEM users UID

The package manager software reads the Windows Registry (and other sources such as its installed.db?), and compares this to an XML of manifest data, to detect other installed software. These 2 outputs you mentioend do look like the application is reading the wrong line of data from somewhere such as the Edit: manifest file.

• This seems to be opposite from the Issue linked above - instead of user scope packages not being visible, it's machine scope packages, and that Issue states that machine scope should still be visible.

Edit continued:

• The GUID provided above matches the x64 ProductCode from version 7.1.2 of Cyanfish.NAPS2.

• The other output provided above matches the PackageName for eloston.ungoogled-chromium.

[bandizsolt]

If I understand correctly, then winget reads the installed programs from the Windows registry and compiles a list from that. Afterward, somehow it tries to search by name, and if it finds a match, it downloads the corresponding manifest file, from which it extracts information such as whether there is a new version and where to download it from. Please correct me if I'm misunderstanding.

For example, when using the winget list command, does it retrieve all installed programs from the registry, search for them in the winget and msstore sources, download the manifest files, and list them?

I tried to find this installed.db file and got 4 hits, but all of them are empty, with no values. So, it seems it only retrieves data from the Windows registry for installed applications and then creates a list.?

For this Product code: {E84C60AF-70D3-4588-A8EE-A2FC1A2AB71B}, I found 9 hits in the Windows registry, and I'm attaching two of them as screenshots, where some data is visible.

I've also figured out that these values are in the manifest files, but I still don't know how it works winget in the background with these.

Thank you very much for your efforts!

[stephengillie]

The Publish pipeline takes our repo's /manifests contents, and rewrites this into an XML file, which is compressed into source.msix, and put onto a host for our CDN to distribute. Then, running 'winget list" has the client download this MSIX and decompress it, to use as a data source. This data is compared to data under certain Registry paths within HKLM and HKCU, and matching results returned.

• It refreshes (downloads a new MSIX) every 5 minutes I believe - if it's been more than 5 minutes since the last run, it downloads (or at least checks), but if less than 5 it uses the local cache.