[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

Abierto
  • ¿Algo no está bien?
#5,683 0 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
csharp
Área
backend, desktop

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C#
Estrellas
26.8k
Forks
970
Merge medio
17 h 24 min
PR fusionados (30 d)
126

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Devolutions/UniGetUI

Todos los issues de Devolutions/UniGetUI

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.