[BUG] Updates page stuck on "No updates" - the engine inside the GUI finds nothing, but the same engine run --headless in the same session finds them

Aperta
  • Qualcosa non va?
#5,683 0 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
backend, desktop

Direzione di ricerca

Start by comparing the GUI hosted engine with the headless engine around the WinGet ListUpdates task and the single instance path; the report names src/UniGetUI.PackageEngine.Managers.WinGet and WindowsPackageManager.Interop. Reproduce by querying updates through the GUI session, then running the same binary with --headless in the same session. Done means both modes return the same expected updates for this reproduction.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug winget
Please confirm these before moving forward
  • I have searched for my issue and have not found a work-in-progress/duplicate/resolved issue.
  • I have tested that this issue has not been fixed in the latest (beta or stable) release.
  • I have checked the FAQ section for solutions.
  • This issue is about a bug (if it is not, please use the correct template).
UniGetUI Version

2026.3.3 (Build 107, Avalonia UI, installed from the setup exe - not the MSIX)

Windows version, edition, and architecture

Windows 11 Pro 25H2, build 26200, x64. winget 1.29.380 (DesktopAppInstaller 1.29.380.0). Single user, admin capable, normally running unelevated.

Describe your issue

The Updates page shows "No updates" permanently. Weird part: it's only the engine instance hosted by the GUI that does this, not the app's engine in general.

Proof from the same box, same user, same Windows session, minutes apart:

  • GUI running: querying that exact session through its IPC (uniget package updates) returns {"updates": []} every time
  • kill the GUI, run UniGetUI.exe --headless from PowerShell, same session: the app's CLI returns 4 updates with isUpgradable true (KillDisk, Battle.net, NS-USBloader, Ubisoft Connect)
  • winget upgrade in that same console agrees with the headless engine (3 upgrades + 2 unknown, which are exactly the Battle.net/NS-USBloader pair)

I went after every suppression path first so this report would be clean: trimmed WinGetAlreadyUpgradedPackages.json and WinGetUpdateAttempts.json (app closed, byte-verified afterwards, no affected ids in there), ignore list empty, no pins on the affected packages, restarted a bunch, ran elevated (same result), fresh boot after clearing a zombie instance. GUI keeps saying 0. Elevated doesn't change it either.

One more thing that matters: winget itself returns different upgrade lists in the console vs over ssh on this machine (same user) - I'm filing that over at microsoft/winget-cli#6140 where it partially fits. But the GUI-empty thing above reproduces fully inside one session, so it's separate from the ssh/session thing.

Steps to reproduce the issue
  1. Open UniGetUI, Updates page shows "No updates". While it's open: uniget package updates -> {"updates": []} (this CLI probe attaches to the GUI's own session registration)
  2. Quit UniGetUI completely. From plain PowerShell, same user:
    UniGetUI.exe --headless --ipc-api-transport tcp --ipc-api-port 7061
  3. uniget --transport tcp --tcp-port 7061 package updates
    -> 4 updates, isUpgradable true
  4. winget upgrade in the same console -> 3 upgrades + 2 unknown, matches the headless engine
  5. Relaunch the GUI, reload Updates -> still 0

Also, from inside one GUI session: package installed returns correct rows (e.g. Audacity 3.7.9) and package search finds the catalog entry (Audacity 4.0.2 available, isUpgradable false). So installed-side and available-side data are both fine in that same session - only the update computation comes back empty.

UniGetUI Log
2026.3.3 keeps app/manager logs in memory per session (no file export), so this is the tail captured live over the IPC API while the GUI session was alive:

App log (GUI session): normal boot - Build 107, UI Framework: Avalonia, .NET 10.0.14, Elevated: False, Packaged (MSIX): False, "Api running on named pipe UniGetUI.IPC". One recurring warning: "Unable to retrieve secret for resource 'UniGetUI/GitHubAccessToken': Element not found" (x2 at boot). Managers load normally afterwards.
Package Managers Logs
winget manager, GUI session (over IPC):
- Logged subprocess task on manager Winget, type RefreshIndexes - winget.exe " source update --disable-interactivity " - start 15:07:38, end 15:07:39 - Return code: SUCCESS (0)
- Logged native task on manager Winget, type ListUpdates - start 15:07:39, end 15:07:47 - "The task reported success"
- OtherTask - native, success

Both scan tasks report SUCCESS, then the update list served by that session stays empty ({"updates": []}, queried repeatedly via its own token). The same binary run --headless in the same session minutes later produces the correct list.

winget.exe upgrade, same console session (ground truth):
Active@ KillDisk 25   LSoftTechnologies.ActiveKillDisk        < 26.0.7   ->  26.0.7   winget
Epic Online Services  EpicGames.EpicOnlineServices            4.2.1      ->  4.3.1    winget
Ubisoft Connect       Ubisoft.Connect                         < 175.0.0.13393 -> 175.0.0.13393  winget
3 upgrades available. 2 package(s) have version numbers that cannot be determined. (those 2 = Battle.net + NS-USBloader, which the headless engine does include)
Relevant information

Possibly related: #4545 (winget CLI reports upgrades but UniGetUI didn't - fixed in 2026.1.7 with the reload refresh fix; I'm on 2026.3.3 and this survives that fix, but the split is different: GUI-hosted engine vs headless engine in the same session). #5541 also shows GUI/headless hosting differences in this layer. Upstream context: microsoft/winget-cli#6140 (winget returns different sets per session type - I'm adding a comment there with same-user data).

My unproven suspicion: the native ListUpdates COM task inside the GUI-hosted process (src/UniGetUI.PackageEngine.Managers.WinGet + WindowsPackageManager.Interop) returns S_OK with zero results once the Avalonia shell has booted, while headless (no UI shell) enumerates fine. Also seen: relaunching while an old instance is mid-exit gets redirected into a zombie that has no working engine or API at all (MainInterface pipe redirect) - maybe worth a look on the single-instance path too.

Happy to test a debug build or pull more captures - the headless/GUI differential is a 60 second repro on my side.

Screenshots and videos

Nothing visual that helps - it's just an empty Updates page with a working engine behind it. Can record the CLI differential live if you want it.

Lingua principale
C#
Stelle
26.8k
Fork
970
Merge medio
17h 24m
PR unite (30g)
126

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Devolutions/UniGetUI

Tutte le issue di Devolutions/UniGetUI

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.