Update-WinGetPackage -Scope System fails with 0x80070652 (ERROR_INSTALL_ALREADY_RUNNING) despite no real install in progress

Summary

Update-WinGetPackage -Scope System reproducibly fails with a synthetic "another installation is already running" error, even when no real installer (no msiexec.exe/TiWorker.exe) is running and the target package uses a non-MSI installer technology.

Environment

• Microsoft.WinGet.Client module version: 1.29.280
• Windows 11 Pro, elevated (Administrator) PowerShell 7.6.3
• winget-cli: as bundled with above module version

Repro

Import-Module Microsoft.WinGet.Client
$result = Update-WinGetPackage -Id 'Git.Git' -Source winget -MatchOption EqualsCaseInsensitive -Scope System -Mode Silent
$result | Format-List *

Id                 : Git.Git
Name               : Git
Source             : winget
CorrelationData    :
InstallerErrorCode : 0
ExtendedErrorCode  : System.Runtime.InteropServices.COMException (0x80070652)
RebootRequired     : False
Status             : InternalError

0x80070652 = HRESULT -2147023278 = Win32 error 1618 = ERROR_INSTALL_ALREADY_RUNNING.

What I verified this is NOT

• tasklist shows no msiexec.exe or TiWorker.exe running at the time of failure.
• Git for Windows (Git.Git) is not an MSI-based installer (Inno Setup), so a real MSI mutex collision doesn't apply.
• The failure is reproducible across separate attempts, not transient.
• The equivalent CLI command works (after clearing the state below): winget upgrade --id Git.Git --exact --scope machine --silent --accept-source-agreements --accept-package-agreements.

What I found investigating the source

ContextOrchestrator.cpp's EnqueueAndRunItem throws exactly this HRESULT (HRESULT_FROM_WIN32(ERROR_INSTALL_ALREADY_RUNNING)) when an item with a matching OrchestratorQueueItemId is already present in the in-process work queue:

https://github.com/microsoft/winget-cli/blob/master/src/AppInstallerCLICore/ContextOrchestrator.cpp

OrchestratorQueueItemId (ContextOrchestrator.h) is keyed by package ID + source ID only — not by scope, verb (install vs. upgrade), or caller session. This looks like a collision/stale-queue-entry bug: something in the machine-scope (-Scope System) code path appears to enqueue or leave behind a queue item that a subsequent call for the same package+source then collides with, surfacing as this synthetic "already running" error even though nothing is actually running.

While reproducing this on a real host, I also observed the underlying WindowsPackageManagerServer.exe process end up in a stuck state where even the plain CLI (winget upgrade --scope machine) subsequently hung indefinitely on "Waiting for another install/uninstall to complete..." until the server process was manually killed (Stop-Process -Name WindowsPackageManagerServer -Force) — suggesting the module's failed -Scope System call may leave the shared COM server's queue in a bad state that also blocks unrelated CLI usage afterward, not just the module.

Related

• #4136 — same exact HRESULT/Status signature reported for a different package (Cloudflare.Warp), no scope specified. Confirms the error code itself is a known, currently unresolved failure mode, but doesn't connect it to -Scope System specifically.
• #4787 — maintainer confirms the module's Install/Update-WinGetPackage cmdlets don't properly pipe the requested scope into the composite package catalog options.
• #5328 — active rework of scope handling in the PowerShell cmdlets (closed via a fix), same day as the #4787 maintainer comment — indicates this area was known-immature.
• #4661 — same general pattern (module fails, CLI succeeds for the identical package), different HRESULT.

Ask

• Confirm whether OrchestratorQueueItemId should also key on scope/verb, or whether the machine-scope code path is enqueuing a duplicate/stale item.
• Confirm whether a failed -Scope System call can leave WindowsPackageManagerServer's internal queue in a state that also blocks subsequent CLI operations against the same package, and if so, whether that's expected or itself a bug.

Start with the Update-WinGetPackage reproduction, then read ContextOrchestrator.cpp and ContextOrchestrator.h, especially EnqueueAndRunItem and OrchestratorQueueItemId. Determine whether the machine-scope call creates a duplicate or stale queue entry and whether it leaves WindowsPackageManagerServer blocking later CLI operations. Done means the queue-key and failure-state behavior are confirmed or ruled out.