Repair-WinGetPackageManager failing on version 1.12.350

[KarbitsCode]

Relevant area(s)

PowerShell Module

Relevant command(s)

No response

Brief description of your issue

Repair-WinGetPackageManager failling on version 1.12.350 because it said it's being currently in use (see my CI logs), which unknown to me and I haven't figure it out how to get pass it (I tried killing the winget process, but it doesn't seem like it was the issue and I don't know which process locking it).

Steps to reproduce

Install-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery -Verbose -AllowClobber
Repair-WinGetPackageManager -Version $(Get-ReleaseTag) -Verbose

Expected behavior

Finished successfully.

Actual behavior

Environment

Windows Package Manager v1.11.510
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.26100.6899
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.26.510.0

Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads
Configuration Modules              %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Enabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Enabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled

[github-actions]

The following issues might be duplicates:

• Repair-WinGetPackageManager -Latest fails on the new PowerShell module v1.12.350 #5826

AI-generated content by genai-issue-dedup may be incorrect.

[KarbitsCode]

The following issues might be duplicates:

• Repair-WinGetPackageManager -Latest fails on the new PowerShell module v1.12.350 #5826

AI-generated content by genai-issue-dedup may be incorrect.

This one has slightly different error message.

[florelis]

I tried killing the winget process, but it doesn't seem like it was the issue and I don't know which process locking it

It likely is the WindowsPackageManagerServer.exe process, which is the server for our COM API. I'm not sure if the cmdlet is supposed to be killing it as part of the process.

[KarbitsCode]

I tried killing the winget process, but it doesn't seem like it was the issue and I don't know which process locking it

It likely is the WindowsPackageManagerServer.exe process, which is the server for our COM API. I'm not sure if the cmdlet is supposed to be killing it as part of the process.

I did try killing that WindowsPackageManagerServer.exe but no avail. This problem doesn't happen in any previous versions though.

[KarbitsCode]

I got somewhat detailed error message from Get-AppPackageLog (from CI):

Packages were not updated because affected apps are still running.
Running apps: {Microsoft.DesktopAppInstaller_8wekyb3d8bbwe!WinGetComServer},
Directly serviced packages: {Microsoft.DesktopAppInstaller_1.26.510.0_x64__8wekyb3d8bbwe},
Indirectly serviced packages: {NULL},
Number of previous attempts: 0, Is user session locked: false, Force update deferred by package: false

Maybe @florelis was right, it is related to COM server.

[JohnMcPMS]

I believe that this was caused by a change that introduced a Version property on the COM server and then used it in the PowerShell, meaning Repair-WinGetPackageManager started invoking the server and blocking itself. For now, using -Force for repair should work around the issue.