[Bug]: installed with machine scope but updates run in user context only

Question

[Bug]: installed with machine scope but updates run in user context only

bandizsolt opened this issue a year ago · comments

bandizsolt commented a year ago

The problem

Hi!

When I install ungoogled chromium with this:

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

then it install to the program files, but Winget-AutoUpdate only update in user context only, I do not know, where to start to debug, how to check, can you please guide, how to analyze this problem?

Thank you!

What version of WAU has the issue?

latest

What version of Windows are you using (ex. Windows 11 22H2)?

windows 10 / 11 latest (22H2)

What version of winget are you using?

latest stable (v1.5.1881)

Log information

No response

Additional information

No response

Romain · Answer 1 · Wed Jul 19 2023 20:34:50 GMT+0800 (China Standard Time)

Have you tried winget install -e --id eloston.ungoogled-chromium --interactive --scope machine --architecture x64 --scope machine ?

bandizsolt · Answer 2 · Wed Jul 19 2023 23:48:42 GMT+0800 (China Standard Time)

Have you tried winget install -e --id eloston.ungoogled-chromium --interactive --scope machine --architecture x64 --scope machine ?

Yep, I specified machine scope before architecture, as you can see. With "winget list --scope machine" I see that is on the list, but WAU only see in user scope.

If I dont specify or specify the user scope then it installs into the "C:\Users<username>\AppData\Local\Chromium" and WAU can update in user context what is ok. But installing in machine scope WAU will update only in user context.

As I see in this comment, winget detect the scope by registry:

Winget uses the registry to determine which applications are installed and the scope. If the registry keys fall under HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ or HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\ then it is a machine scope. If it falls under HKCU: instead of HKLM: then it is a user scope.

There isn't currently a way to show the installed scope except to query the registry manually.

Originally posted by @Trenly in microsoft/winget-cli#3239 (comment)

So winget it detects that soft correctly, how WAU detects the scope? Can you enlighten me please?

Romain · Answer 3 · Thu Jul 20 2023 13:53:54 GMT+0800 (China Standard Time)

yes sorry, haven't seen you've put it ^^ tired at the moment, need holidays 😅

WAU system scope detection is realized by this function (running in system context):
https://github.com/Romanitho/Winget-AutoUpdate/blob/main/Winget-AutoUpdate/functions/Get-WingetSystemApps.ps1

bandizsolt · Answer 4 · Mon Jul 24 2023 20:47:58 GMT+0800 (China Standard Time)

There is no problem, thank you, I looked through it, as I see, it depends on winget export so I think the problem is elsewhere. I maked some test, can you take a look please, what could causing this:

1 - winget_system_apps.txt - file is created with: Winget-AutoUpdate/functions/Get-WingetSystemApps.ps1 - generated automatically when wau is installed in user context

this list (from point 3) is filtered somehow, to show system apps but one package is missing

2 - exported with winget command:
winget export -o hecc.txt

here I think I exported all installed apps

3 - exported with winget command:
winget export -o eu.txt --accept-source-agreements -s winget | Out-Null;

this list is ok, there is in the list "eloston.ungoogled-chromium"
this exports only the apps what is upgradable from the winget source

github-actions · Answer 5 · Thu Aug 24 2023 10:00:22 GMT+0800 (China Standard Time)

This issue is stale because it has been open for 30 days with no activity.

github-actions · Answer 6 · Thu Sep 07 2023 10:02:26 GMT+0800 (China Standard Time)

This issue was closed because it has been inactive for 14 days since being marked as stale.

bandizsolt · Answer 7 · Tue Nov 21 2023 23:57:00 GMT+0800 (China Standard Time)

used modified script to run directly from powershell

function Get-WingetSystemApps {
    # Specify the working directory
    $WorkingDir = "c:\Users\public\Desktop\"

    # Specify the output text file
    $jsonFile = Join-Path $WorkingDir "winget_system_apps.txt"

    # Get list of installed Winget apps to json file
    & winget export -o $jsonFile --accept-source-agreements -s winget | Out-Null

    # Convert json file to txt file with app ids
    $InstalledApps = Get-Content $jsonFile | ConvertFrom-Json

    # Save app list
    $InstalledApps.Sources.Packages.PackageIdentifier | Set-Content $jsonFile

    # Sort app list
    Get-Content $jsonFile | Sort-Object | Set-Content $jsonFile
}

winget_system_apps manual run as Admin - running function Get-WingetSystemApps

7zip.7zip
Adobe.Acrobat.Reader.64-bit
Cyanfish.NAPS2
eloston.ungoogled-chromium
Ghisler.TotalCommander
GlavSoft.TightVNC
IrfanSkiljan.IrfanView
Microsoft.DevHome
Microsoft.Edge
Microsoft.EdgeWebView2Runtime
Microsoft.Office
Microsoft.OneDrive
Microsoft.VCRedist.2015+.x64
Microsoft.WindowsTerminal
OO-Software.ShutUp10
Romanitho.WiGUI
VideoLAN.VLC

winget_system_apps manual run as User - running function Get-WingetSystemApps, missing programs compared to manual admin list: Cyanfish.NAPS2, eloston.ungoogled-chromium, Microsoft.Office)

7zip.7zip
Adobe.Acrobat.Reader.64-bit
Ghisler.TotalCommander
GlavSoft.TightVNC
IrfanSkiljan.IrfanView
Microsoft.DevHome
Microsoft.Edge
Microsoft.EdgeWebView2Runtime
Microsoft.OneDrive
Microsoft.VCRedist.2015+.x64
Microsoft.WindowsTerminal
OO-Software.ShutUp10
Romanitho.WiGUI
VideoLAN.VLC

winget_system_apps Generated by WAU for a simple User, ~~(running script in user context)~~ (script runs in sytem context) - missing programs compared to manual admin list: Cyanfish.NAPS2, eloston.ungoogled-chromium, Microsoft.Office + Microsoft.DevHome, Microsoft.OneDrive, Microsoft.WindowsTerminal.

7zip.7zip
Adobe.Acrobat.Reader.64-bit
Ghisler.TotalCommander
GlavSoft.TightVNC
IrfanSkiljan.IrfanView
Microsoft.Edge
Microsoft.EdgeWebView2Runtime
Microsoft.VCRedist.2015+.x64
OO-Software.ShutUp10
Romanitho.WiGUI
VideoLAN.VLC

The inconsistency among the three saved lists listed here may not be crucial (fro my problem I think), but I'm interested in understanding why these differences exist. I assume that when the script runs, taking into account the user context, it should execute with system-level privileges (similar to having admin rights, right?). If the user has the same permissions, why don't the first and last lists match?

running as admin user: winget upgrade --source winget

Name     Id                         Version        Available
-----------------------------------------------------------------
Chromium eloston.ungoogled-chromium 119.0.6045.123 119.0.6045.159
Dev Home Microsoft.DevHome          0.600.297.0    0.601.297.0
2 upgrades available.

running as user: winget upgrade --source winget

Name               Id                 Version          Available
-----------------------------------------------------------------------
Dev Home           Microsoft.DevHome  0.600.297.0      0.601.297.0
Microsoft OneDrive Microsoft.OneDrive 22.012.0117.0003 22.131.0619.0001
2 upgrades available.

The question is the same as the issue: why doesn't the installation of apps, scoped at the machine level, does not get updated for the user when it runs at the system level, similar to admin rights, right?

If I check user context, and I am an admin user, the eloston.ungoogled-chromium will be updated.

Can you please look into this issue? I've reviewed the source code, but I can't find any other possible solution to this except running the script somehow as an admin.

How could this be traced back differently to identify where the issue might be? @Romanitho

update2:

running in system context winget upgrade --source winget
No installed package found matching input criteria.
because in system context cannot find/identify installed programs in machine scope like eloston.ungoogled-chromium, Cyanfish.NAPS2.

Romain · Answer 8 · Wed Nov 22 2023 00:05:17 GMT+0800 (China Standard Time)

Hello.
The problem comes directly from Winget itself. Running in system context is not the same as running with admin user.
Then, the function Get-WingetSystemApps simply lists the apps that can be detected under the context it is executed from.
So, the issue here is not part of WAU.

bandizsolt · Answer 9 · Wed Nov 22 2023 00:08:45 GMT+0800 (China Standard Time)

Thank you for clarifying things. So, there is a system context that is completely different from the user and admin contexts. How could this system context be tested?

Romain · Answer 10 · Wed Nov 22 2023 00:10:12 GMT+0800 (China Standard Time)

create a scheduled task that run with system rights. Use the Winget path from get-wingetcmd function

bandizsolt · Answer 11 · Wed Nov 22 2023 00:15:08 GMT+0800 (China Standard Time)

Thank you very much!

bandizsolt · Answer 12 · Wed Nov 22 2023 20:23:48 GMT+0800 (China Standard Time)

Hi, sorry to bother you with this issue. Could you please take a look, or should I create an issue in the Winget repository? @denelon

Andrzej Demski · Answer 13 · Thu Nov 23 2023 06:55:48 GMT+0800 (China Standard Time)

Thank you for clarifying things. So, there is a system context that is completely different from the user and admin contexts. How could this system context be tested?

Please use psexec, that tool can launch processes in system context.
https://learn.microsoft.com/en-us/sysinternals/downloads/psexec

Enjoy testing @bandizsolt

Göran Axel Johannesson · Answer 14 · Thu Nov 23 2023 11:05:48 GMT+0800 (China Standard Time)

Please use psexec

A more modern tool:
https://www.nirsoft.net/utils/advanced_run.html

bandizsolt · Answer 15 · Thu Nov 23 2023 16:38:37 GMT+0800 (China Standard Time)

Thank you very much @KnifMelti and @AndrewDemski-ad-gmail-com for recommending these software tools. I have already tested this from Task Scheduler. The issue is that when using winget in the system context, it doesn't recognize these applications, and therefore, it cannot update them (even though I installed it in machine scope, it doesn't recognize).