Get-WinGetPackage in 1.29.380 fails with "Failed to create instance: -2147023174" in an elevated PowerShell session

[HeinziAT]

Relevant area(s)

PowerShell Module

Relevant command(s)

Get-WinGetPackage. I did not test other commands, so those might be affected as well.

Brief description of your issue

Get-WinGetPackage in 1.29.380 fails with "Failed to create instance: -2147023174" in an elevated PowerShell session.

Steps to reproduce

In an elevated PowerShell session (tested with Windows Server 2025, the built-in Administrator account and the built-in PowerShell version):

Uninstall-Module Microsoft.WinGet.Client
Install-Module -Name Microsoft.WinGet.Client -RequiredVersion 1.29.280
Get-WinGetPackage

Note that Get-WinGetPackage outputs the list of installed packages. Now let's try the same with 1.29.380:

Uninstall-Module Microsoft.WinGet.Client
Install-Module -Name Microsoft.WinGet.Client -RequiredVersion 1.29.380
Get-WinGetPackage

Expected behavior

Get-WinGetPackage behaves like in 1.29.280.

Actual behavior

Get-WinGetPackage : Failed to create instance: -2147023174
At line:1 char:1
+ Get-WinGetPackage
+ ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-WinGetPackage], COMException
    + FullyQualifiedErrorId : System.Runtime.InteropServices.COMException,Microsoft.WinGet.Client.Commands.GetPackageC
   mdlet

Get-WinGetPackage works in a non-elevated PowerShell session.
Reverting to 1.29.280 (see above) fixes the issue.

Environment

Windows Package Manager v1.11.510
Windows: Windows.Server v10.0.26100.32522
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.26.510.0

[JohnMcPMS]

For technical reasons, PowerShell module 1.29.380 and later will require package release 1.29.380 and later for elevated use. You can use the module itself to update via Repair-WingetPackageManager -Latest.

[HeinziAT]

JohnMcPMS Thanks, but a quick test on my Windows 11 PC failed:

PS C:\WINDOWS\system32> Get-WinGetPackage
Get-WinGetPackage : Failed to create instance: -2147023174
At line:1 char:1
+ Get-WinGetPackage
+ ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-WinGetPackage], COMException
    + FullyQualifiedErrorId : System.Runtime.InteropServices.COMException,Microsoft.WinGet.Client.Commands.GetPackageC
   mdlet

PS C:\WINDOWS\system32> Repair-WinGetPackageManager -Latest
PS C:\WINDOWS\system32> Get-WinGetPackage
Get-WinGetPackage : Failed to create instance: -2147023174
At line:1 char:1
+ Get-WinGetPackage
+ ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-WinGetPackage], COMException
    + FullyQualifiedErrorId : System.Runtime.InteropServices.COMException,Microsoft.WinGet.Client.Commands.GetPackageC
   mdlet

winget itself seems to be up-to-date:

C:\Windows\System32>winget -v
v1.29.380

Get-WinGetPackage still doesn't work (elevated).

[novinxy]

I also have the same issue

For me it's of deployment issue:

• module/winget had "minor version" change but it breaks things. Does winget-cli not follow semver convention?
• searching for appinstaller on my machine doesn't return latest version

     Name                      Id                                Version      Source
     --------------------------------------------------------------------------------
     App Installer             Microsoft.AppInstaller            1.29.290     winget
     AppInstaller File Builder Microsoft.AppInstallerFileBuilder 1.2020.221.0 winget
  

• winget upgrade winget doesn't update to latest winget
• Seems there is some misalignment in deployments. winget-cli release is not deployed to winget-pkgs, but Microsoft.WinGet.Client is deployed to powershellgallery. Shouldn't we deploy to both repositories to ensure consistent environment? Maybe we should consider automatic deployments to winget-pkgs?

JohnMcPMS what do you think about it?

[JohnMcPMS]

HeinziAT, I just tried it and it is working for me. Are you sure that you have the 380 module loaded? You may have to restart the PS process and use 380 first to ensure that you aren't getting stale native DLLs being used.

Grzegorz Nowiński (@novinxy), are you saying that you are experiencing an issue when you have both of them at 380? Or that you have this error due to not having them both at 380, and consistent deployment would resolve that?

[novinxy]

I had issue with powershell module on 380 and winget on 290. Repair-WingetPackageManager and comouter restart fixed the issue.

I mean that consistent deployments would resolve that issue, maybe it would even eliminate similar issues in the future.

Interesting part is that in our environment we have 300 machines, some of them got newer winget (not sure why, maybe from windows update), some couldn't get it except using Repair-WingetPackageManager.

[HeinziAT]

JohnMcPMS: Yes, it appears that something had still been cached. After logging off and on it started working with everything on 380. Thanks!

Can something be done about the error message? Maybe

This version of the Microsoft.WinGet.Client PowerShell module requires winget 1.29.380 or later when used in an elevated session. Please close all PowerShell windows, execute Repair-WingetPackageManager -Latest and then log off and on.

instead of

Get-WinGetPackage : Failed to create instance: -2147023174

?

[sba923]

I'm facing the same issue with 1.11.460 on a Windows 11 build 10.0.26200.9550 machine

And I'm not facing the issue on another Windows 11 machine (build 10.0.26200.9457) with 1.29.380

More a Windows 11 issue than an issue with the module?

[rbalsleyMSFT]

It appears that the issue is related to winget changing from using named pipes to using local RPC. In my testing, if the module or CLI are 1.29.380 or greater (excluding the current 1.30.140-preview CLI build as that build has the old named pipes configuration) and the other component is a version earlier than that, you have a mismatch between one of them using named pipes and the other isn't.

So you could either be 1.29.280 for both and working fine (using the named pipes code), but as soon as either the CLI or module update to 1.29.380, you'll have one looking for named pipes and the other isn't. That mismatch is what causes the issue.

[novinxy]

FYI
I created issue in winget-pkgs and it was resolved by adding winget 380
microsoft/winget-pkgs#440350 (comment)

That gives us another way to resolve issue with
winget upgrade winget