#5397·UniGetUI

[IMPROVEMENT] Detect installer "app is running" failures (Spotify exit 26) and offer close/retry

Author: marco-carvalhoCreated Sep 18, 2026Updated Sep 18, 2026

Please confirm these before moving forward.

  • I have searched for my feature proposal and have not found a work-in-progress/duplicate/resolved/discarded issue.
  • This improvement refers to an existing feature. If you want to suggest a new feature, please use this template.
  • This improvement is not a bug. If you want to report a bug, please use this template.

Related, but not the same:

  • #5031 asks to surface Git installer-log text when processes block the update.
  • #997 (closed as not planned in 2023) was Git blocked by running processes; at the time UniGetUI did not yet have KillProcessOperation.

This issue is about a case WinGet already explains on stdout, which UniGetUI currently maps to a generic failure.

Describe the improvement

When updating Spotify.Spotify while Spotify is running, WinGet already prints a clear reason:

Found Spotify [Spotify.Spotify] Version 1.3.1.234.g59d6bf59
Successfully verified installer hash
Starting package install...
The application is currently running. Exit the application and try again.
Installer failed with exit code: 26

Closing Spotify.exe and retrying the same winget upgrade --id Spotify.Spotify succeeds. In UniGetUI the same update only shows a generic failure (OperationFailedDialog title = Metadata.FailureMessage, plus “see the Command-line Output”).

WinGetPkgOperationHelper already maps several WinGet codes to OperationVeredict.AutoRetry (elevation, already installed, not applicable). Installer exit 26 / stdout containing “currently running” falls through to OperationVeredict.Failure.

UniGetUI already has the pieces to do better:

  • InstallOptions.KillBeforeOperation + KillProcessOperation
  • RetryMode.Retry / Retry_Interactive on OperationFailedDialog
  • Settings.K.KillProcessesThatRefuseToDie

Suggested change (small, existing patterns):

  1. In WinGetPkgOperationHelper._getOperationResult, detect this class of failure from stdout (currently running / localized equivalents) or installer exit 26 when WinGet reports Installer failed with exit code: 26.
  2. Set a specific FailureMessage, e.g. {package} is currently running. Close it and retry the update.
  3. On the failed-operation dialog, add Retry after closing {process} that prepends KillProcessOperation (package exe / KillBeforeOperation) and retries, same idea as retry-as-admin.
  4. Optional: if KillBeforeOperation is empty, guess Spotify from Spotify.Spotify / display name, only when the installer said the app is running.

Do not silently taskkill /F by default. Reuse CloseMainWindow() first, then the existing “kill processes that refuse to die” setting.

winget CLI was run unelevated; elevation is not the issue here (Spotify also prohibits elevation).

Describe how this improvement could help users

Spotify, Discord, Git, browsers, etc. often fail silent WinGet upgrades only because the app is open. UniGetUI currently looks like a hard error. Showing the real reason and offering close+retry would match what the CLI already says, and would reuse KillProcessOperation instead of asking users to discover “Close apps before this operation” in package options.