[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

Offen
  • Stimmt etwas nicht?
#5,683 2 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
csharp
Bereich
backend, desktop

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug needs-author-answer priority: high 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.

Vorherrschende Sprache
C#
Sterne
26.8k
Forks
970
Ø Merge
18 Std. 33 Min.
Gemergte PRs (30 T.)
124

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus Devolutions/UniGetUI

Alle Issues in Devolutions/UniGetUI

Ähnliche Issues

Weitere Issues zu C#

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.