Skip to content

[BUG] "Ask for administrator privileges once for each batch" can still show multiple UAC prompts with parallel operations set to 1 #5442

Closed
#5483
#5446
Closed
[BUG] "Ask for administrator privileges once for each batch" can still show multiple UAC prompts with parallel operations set to 1#5442
#5483
#5446
Assignees
GabrielDuf
Labels
bugSomething isn't working

Description

@fabergen
fabergen
opened on Sep 27, 2026

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.0

Windows version, edition, and architecture

Microsoft Windows 11 Pro 25H2 · Build 26200.9457 · x64

Describe your issue

I have enabled the option "Ask for administrator privileges once for each batch of operations".

The separate option "Ask only once for administrator privileges" is disabled, and the maximum number of parallel operations is set to 1.

When I start multiple package updates together as one batch, UniGetUI can still display multiple UAC prompts for package operations that require elevation.

In one reproducible test, I started a batch of 7 WinGet updates. Three packages required administrator privileges:

  • CodecGuide.K-LiteCodecPack.Full
  • Notepad++.Notepad++
  • Microsoft.WindowsADK

Although all three operations belonged to the same batch and were processed sequentially, I received 3 separate UAC prompts.

The UniGetUI logs show that all three elevated operations were launched through "UniGetUI Elevator.exe" and that the same administrator-rights cache process ID was used until the batch completed.

With "Ask for administrator privileges once for each batch of operations" enabled, I would expect one UAC confirmation to be reused for all elevated package operations within that batch.

Steps to reproduce the issue

  1. Open UniGetUI Settings.

  2. Under the administrator/elevation settings:

    • Enable "Ask for administrator privileges once for each batch of operations".
    • Leave "Ask only once for administrator privileges" disabled.
    • Set the maximum number of parallel operations to 1.

  3. Make sure multiple WinGet updates are available, including more than one package that requires elevation.

  4. Start all selected updates together as one batch.

  5. Approve the UAC prompts as they appear.

  6. Observe that multiple UAC prompts can be shown during the same batch.

In my reproducible test, the batch contained 7 updates. Three of them required elevation:

  • CodecGuide.K-LiteCodecPack.Full
  • Notepad++.Notepad++
  • Microsoft.WindowsADK

All operations were processed sequentially because the parallel operation limit was set to 1, but 3 separate UAC prompts were shown.

ICS-PC01-session.log

UniGetUI Log

Relevant excerpt from ICS-PC01-session.log:

[2026-09-27 12:16:00 ] WinGet package CodecGuide.K-LiteCodecPack.Full requires elevation, forcing administrator rights...
[2026-09-27 12:16:00 ] Caching admin rights for process id 20532

[2026-09-27 12:17:32 ] WinGet package Notepad++.Notepad++ requires elevation, forcing administrator rights...
[2026-09-27 12:17:32 ] Caching admin rights for process id 20532

[2026-09-27 12:17:45 ] WinGet package Microsoft.WindowsADK requires elevation, forcing administrator rights...
[2026-09-27 12:17:45 ] Caching admin rights for process id 20532

[2026-09-27 12:19:16 ] Clearing UAC prompt since there are no remaining operations
[2026-09-27 12:19:16 ] Resetting administrator rights cache for process id 20532

The complete ICS-PC01-session.log is attached.

Package Managers Logs

Relevant package manager operation logs:

K-Lite Codec Pack Full:
Executing process with StartInfo:
 - FileName: "C:\Program Files\UniGetUI\Assets\Utilities\UniGetUI Elevator.exe"
 - Arguments: ""C:\Users\gufa\AppData\Local\Microsoft\WindowsApps\winget.exe" update --id "CodecGuide.K-LiteCodecPack.Full" --exact --source winget --accept-source-agreements --disable-interactivity --silent --include-unknown --accept-package-agreements --force"

The operation completed successfully with return value 0.

Notepad++:
Executing process with StartInfo:
 - FileName: "C:\Program Files\UniGetUI\Assets\Utilities\UniGetUI Elevator.exe"
 - Arguments: ""C:\Users\gufa\AppData\Local\Microsoft\WindowsApps\winget.exe" update --id "Notepad++.Notepad++" --exact --source winget --accept-source-agreements --disable-interactivity --silent --include-unknown --accept-package-agreements --force"

The operation completed successfully with return value 0.

Windows Assessment and Deployment Kit:
Executing process with StartInfo:
 - FileName: "C:\Program Files\UniGetUI\Assets\Utilities\UniGetUI Elevator.exe"
 - Arguments: ""C:\Users\gufa\AppData\Local\Microsoft\WindowsApps\winget.exe" update --id "Microsoft.WindowsADK" --exact --source winget --accept-source-agreements --disable-interactivity --silent --include-unknown --accept-package-agreements --force"

The operation completed successfully with return value 0.

The complete operation logs for all three packages are attached.

Relevant information

ICS-PC01-session.log
UniGetUI-Protokoll_K-LiteCodecPack.txt
UniGetUI-Protokoll_Notepad++.txt
UniGetUI-Protokoll_WindowsADK.txt

Screenshots and videos

No response

Activity

  1. fabergen
    added
    bugSomething isn't working
    on Sep 27, 2026

  2. GabrielDuf commented on Sep 28, 2026

    @GabrielDuf
    Gabriel Dufresne (GabrielDuf)
    on Sep 28, 2026
    Contributor

    Hi fabergen,
    I've looked into it and found two issues on our side:

    • Elevation caching is requested per operation instead of once per batch.
    • UniGetUI doesn't currently log the elevator's exit code/output, so a failed cache attempt is silent. The Caching admin rights… message is logged before the attempt, so it doesn't guarantee the cache was actually created.

    I'll fix both of them.

    That said, neither fully explains the three prompts. Re-requesting an existing cached session shouldn't prompt again, so it looks like the session may be disappearing between operations.

    Could you run these in PowerShell while a batch is running, ideally between two packages?

    Get-Process "UniGetUI Elevator" -ErrorAction SilentlyContinue | Select-Object Id, StartTime
[IO.Directory]::GetFiles("\\.\pipe\") | Where-Object { $_ -match 'gsudo' }
reg query "HKLM\SOFTWARE\unielevate-gsudo" 2>$null

    If the process and pipe are still there, the session is alive and we'll need to look elsewhere. If not, the session is being lost, and the registry command may help explain why.

  3. Gabriel Dufresne (GabrielDuf)
    self-assigned this
    on Sep 28, 2026
  4. Gabriel Dufresne (GabrielDuf)
    linked a pull request that will close this issueAcquire the administrator rights cache once per batch and report elevator failures #5446on Sep 28, 2026

  5. fabergen commented on Oct 1, 2026

    @fabergen
    fabergen
    on Oct 1, 2026
    Author

    Hi,
    I ran the requested checks every 2 seconds during full update batches on four systems.
    UAC prompts observed:

    • ICS-PC01 / Windows 11: 1 prompt
    • ICS-PC02 / Windows 11: 1 prompt
    • ICS-NB01 / Windows 11: 1 prompt
    • ICS-NB02 / Windows 10: 2 prompts
      The interesting case is ICS-NB02. On that system, the cached elevation session did not disappear between operations.
      The relevant sequence was:
    • 14:39:02 — UniGetUI logs Caching admin rights for process id 10572
    • 14:39:14 — the gsudo session is present with both named pipes
    • 14:39:26 — Notepad++ requires elevation and UniGetUI again logs Caching admin rights for process id 10572
    • 14:39:39 — PDF-XChange Editor requires elevation and UniGetUI again logs Caching admin rights for process id 10572
    • 14:41:07 — UniGetUI logs Clearing UAC prompt since there are no remaining operations and Resetting administrator rights cache for process id 10572
    • 14:41:10 — the diagnostic monitor sees both the UniGetUI Elevator process and the gsudo pipes disappear
      During the whole period between the initial cache creation and the final reset, the same gsudo named-pipe session remained present. For example, the pipes were still there immediately after the Notepad++ elevation request, and also while PDF-XChange Editor was being started.
      UniGetUI also kept using the same process id 10572 for the cache requests and only reset the cache after the last operation.
      Immediately before the reset, the gsudo pipes were still present. They disappeared only after UniGetUI had cleared/reset the cache.
      So at least in this Windows 10 test, the second UAC prompt cannot be explained by the cached gsudo session disappearing between package operations.
      One additional observation on the same system: the desktop shortcut PDF-XChange Editor was left behind after the update. I do not see a protected-shortcut cleanup/relaunch entry in the current UniGetUI session log for this run, so I cannot say whether that is related to the second UAC prompt.
      I have attached the diagnostic logs from all four systems, plus the complete UniGetUI session.log from ICS-NB02.

    session.log
    UniGet-Credentials-Test.PS1-(ICS-PC01_GUFA).log
    UniGet-Credentials-Test.PS1-(ICS-PC02_SIWE).log
    UniGet-Credentials-Test.PS1-(ICS-NB02_GÜNTER).log
    UniGet-Credentials-Test.PS1-(ICS-NB01_GUFA).log

  6. GabrielDuf commented on Oct 7, 2026

    @GabrielDuf
    Gabriel Dufresne (GabrielDuf)
    on Oct 7, 2026
    Contributor

    Hi fabergen, thanks, these diagnostics narrowed it down.

    The cached session is staying alive between operations, so my earlier theory about it disappearing was wrong. More importantly, ICS-PC01 produced 3 prompts in the first report and 1 in the re-test on the same build, which pointed to a race rather than a configuration issue.

    The problem was in cache on: the elevator waits up to two seconds for its credentials service to start, but returns exit code 0 even if the service isn't ready. UniGetUI trusted that code, so on a slow start it assumed the cache was available and each elevated package fell back to its own UAC prompt.

  7. Gabriel Dufresne (GabrielDuf)
    linked a pull request that will close this issueVerify that the administrator rights cache was really established #5483on Oct 7, 2026
  8. Gabriel Dufresne (GabrielDuf)
    closed this as completedin #5483on Oct 7, 2026

  9. fabergen commented on Oct 24, 2026

    @fabergen
    fabergen
    on Oct 24, 2026
    Author

    Hi,

    I tested this again today with UniGetUI 2026.3.2.0, and unfortunately the user-visible problem from #5442 is still reproducible.

    I updated these three packages together in one batch:

    • JGraph.Draw → 32.6.1
    • TrackerSoftware.PDF-XChangeEditor → 11.1.1.0
    • Microsoft.PowerShell → 7.6.8.0

    My relevant settings are:

    • Ask for administrator privileges once for each batch of operations = enabled
    • Ask only once for administrator privileges = disabled
    • Maximum parallel operations = 1
    • Removal of newly created desktop shortcuts = enabled

    During this single batch I received three administrator/UAC credential prompts.

    The important difference compared with my original report is that the cache race fixed by #5483 does not seem to be the cause this time.

    The log explicitly confirms that the cache was successfully established:

    [2026-10-24 5:59:49 ] Caching admin rights for process id 18436
[2026-10-24 5:59:58 ] The elevator cached administrator rights for process id 18436
[2026-10-24 5:59:58 ] Info: Elevation allowed for process Id 18436 and children.

    The cache remained active until the end of the batch:

    [2026-10-24 6:01:12 ] Resetting administrator rights cache for process id 18436
[2026-10-24 6:01:12 ] Clearing UAC prompt since there are no remaining operations

    However, while that cache was active, UniGetUI also attempted to remove the protected PDF-XChange desktop shortcut:

    [2026-10-24 6:00:37 ] Deleting shortcut C:\Users\Public\Desktop\PDF-XChange Editor.lnk
[2026-10-24 6:00:37 ] Not allowed to delete shortcut {shortcutPath=C:\Users\Public\Desktop\PDF-XChange Editor.lnk}: Access to the path 'C:\Users\Public\Desktop\PDF-XChange Editor.lnk' is denied.
[2026-10-24 6:00:37 ] Relaunching UniGetUI elevated to delete 1 protected shortcut(s)

    So there is an additional elevation path for protected-shortcut cleanup while the batch administrator-rights cache is already active.

    I also noticed that the WinGet manifest for Microsoft.PowerShell 7.6.8.0 contains machine-scope MSI installers with:

    Scope: machine
ElevationRequirement: elevatesSelf

    UniGetUI did not log a forcing administrator rights message for the PowerShell update in this run.

    I cannot determine from session.log alone which of the three visible prompts belonged to which elevation path, so I do not want to overstate the cause.

    But from the user perspective the expected behavior is still:

    If “ask once per batch” is enabled, all UniGetUI-controlled elevation operations belonging to that batch should reuse the same administrator-rights cache, including protected-shortcut cleanup.

    So #5483 appears to have fixed the original cache-establishment race, but multiple credential prompts can still occur within one batch on UniGetUI 2026.3.2.0.

    I have attached a sanitized excerpt from the current session.log containing only the relevant batch, cache and shortcut-cleanup entries.

    Relevant code:
    https://github.com/Devolutions/UniGetUI/blob/v2026.3.2/src/UniGetUI.Core.Tools/ShortcutFileRemover.cs

    PowerShell 7.6.8.0 WinGet manifest:
    https://github.com/microsoft/winget-pkgs/blob/master/manifests/m/Microsoft/PowerShell/7.6.8.0/Microsoft.PowerShell.installer.yaml

    UniGetUI-2026.3.2-UAC-session-excerpt-2026-10-24.log

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions