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

[kyle-sexton]

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

• The Update-WinGetPackage command fails with an error #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.
• Powershell Module Should Support Scope Parameter #4787 — maintainer confirms the module's Install/Update-WinGetPackage cmdlets don't properly pipe the requested scope into the composite package catalog options.
• Better support for Scope in PowerShell cmdlets #5328 — active rework of scope handling in the PowerShell cmdlets (closed via a fix), same day as the Powershell Module Should Support Scope Parameter #4787 maintainer comment — indicates this area was known-immature.
• PowerShell client fails to install certain packages which work with the winget CLI #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.

[denelon]

Thanks for the detailed report.

One clarification: -Scope System is valid for the PowerShell/WinRT API surface. Internally it maps to Manifest::ScopeEnum::Machine, which is the same scope represented by --scope machine in the CLI. The CLI/settings/manifest parser use user and machine; the API layer uses User and System.

The queue observation is partially accurate: OrchestratorQueueItemId is currently keyed by package ID and source ID, and package operations are serialized through the operation queue. That does not necessarily mean scope or verb should be part of the key; the queue is intended to prevent concurrent operations against the same package/source.

Given that, I don’t think we should treat this as evidence that System is an unsupported scope. If you can still reproduce this on the latest module/winget build, please attach the WinGet logs for the failed PowerShell call and confirm whether the failure occurs after restarting WindowsPackageManagerServer.exe. Without logs or a current-version repro, this looks more likely to be either a stale/in-progress package operation in the COM server or a duplicate of the existing ERROR_INSTALL_ALREADY_RUNNING reports rather than a scope parsing issue.