Repository navigation
PowerShell module not working in system context #5991
Description
Relevant area(s)
WinGet CLI, PowerShell Module
Relevant command(s)
No response
Brief description of your issue
Since the December update (v1.12.440), the Get-WinGetPackage command no longer works when executed in SYSTEM context. The process exits immediately with exit code 1 and does not export or return the list of installed packages. The same command works correctly when run in a user context.
Steps to reproduce
Run the Get-WinGetPackage in system context.
Expected behavior
The command should work as before in system context.
Actual behavior
The process exits with code 1.
Environment
Windows Package Manager v1.12.440
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.22631.5909
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.27.440.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 Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride Disabled
LocalArchiveMalwareScanOverride Disabled
ProxyCommandLineOptions Disabled
DefaultProxy Disabled
Activity
Mmate99 commentedon Jan 21, 2026
The error output from the PS module:
JohnMcPMS commentedon Jan 22, 2026
I'm not seeing the issue, so there is likely something more specific to your setup going on:
Logs for this should go to
%TEMP%\WinGet\defaultState\for the SYSTEM user. On my machine that isC:\Windows\Temp\WinGet\defaultState.Mmate99 commentedon Jan 27, 2026
Thanks for the info! Managed to figure out what caused the issue, an older PS module version was installed on my machine (1.11.460) with the new winget version. After updating the PS module the issue was solved.
akos-szego commentedon Jan 27, 2026
JohnMcPMS could you please clarify if using either WinGet CLI or the related PS module is supported from the SYSTEM user running in Session 0 (as usually services do)? We (and probably others, too) need a definitive statement since in case it's not supported, it can break at any time. In turn it doesn't make sense to build any automated management solution on top of it. Thanks!
JohnMcPMS commentedon Jan 27, 2026
The CLI is not supported from SYSTEM at all, as one cannot register the MSIX package for the SYSTEM user.
The PS module is supported for SYSTEM use in session 0. When running as system it does not have a dependency on the MSIX package.
Note that individual package functionality is not guaranteed in SYSTEM contexts. This is to say, not every package can be installed successfully when running as SYSTEM. winget-pkgs does not validate that flow during ingestion.
Poking Demitrius Nelon (@denelon) in case my developer messaging abilities are poor.
akos-szego commentedon Feb 9, 2026
Thanks for the clarification.
blackops786187 commentedon Feb 9, 2026
I am running windows 11 25h2 with powershell 5.1. I used psexec to open powershell as system and then installed the winget cli module. However all the commands are giving me this error
Is this module not supported in powershell 5.1 when running under the system context? It seems if i just run it as the standard user under powershell 5.1 the package installs without issue so it seems to be specific to the system context
aledeniz commentedon Sep 9, 2026
I currently have an active Microsoft Support case for this issue and have informed the support engineers assigned to the ticket.
The issue is trivial to reproduce using Sysinternals PsExec.
From an elevated PowerShell 5.1 session, run:
This opens a new PowerShell session running as
NT AUTHORITY\SYSTEM.In the SYSTEM session, run either:
or:
Both commands fail with the error shown in the screenshot below.
The behaviour described in this issue is reproducible in my environment and appears to affect both the PowerShell module and the WinGet CLI when running under
NT AUTHORITY\SYSTEM.aledeniz commentedon Oct 7, 2026
Demitrius Nelon (@denelon) Joey Maffiola (@J-MaFf) JohnMcPMS Mmate99
For further clarification, the Microsoft support case we have open on this topic is 2609010050002033, which was opened on 1 September 2026. We have been actively working with multiple Microsoft support teams on this issue for over a month.
One point I would like to clarify is that we were aware from the outset that using winget.exe directly was not the recommended path for our scenario. We understood the supported automation mechanism to be the Microsoft.WinGet.Client PowerShell module, and that has been our sole focus throughout the discussion.
After revisiting both the public documentation and the support discussions, I think the core issue is that Microsoft.WinGet.Client is officially documented as supporting Windows PowerShell 5.1, including on the PowerShell Gallery package page, where Windows PowerShell 5.1 compatibility is declared and no significant caveats are presented regarding individual cmdlets or common automation scenarios.
At the same time, all the cmdlets we have tested ultimately fail with WindowsPowerShellNotSupported.
Our use case does not appear unusual. We are simply trying to automate application maintenance across Windows Servers and Windows Clients through Configuration Manager Run Scripts running under LocalSystem. Throughout our investigation, every engineer we engaged and every piece of documentation we reviewed led us to believe that using the PowerShell module should be supported for this sort of enterprise automation scenario.
We actually worked around the issue fairly early on by spawning a PowerShell 7 process and invoking the required cmdlets from there. Technically that works.
However, from our perspective, that workaround raises a different question. If the practical requirement for using Microsoft.WinGet.Client is to deploy and maintain PowerShell 7 across the estate, that has a significant operational impact. In our environment that would mean installing, updating and governing an additional runtime across hundreds of servers and client devices.
This is precisely why the current behaviour was surprising to us. Windows PowerShell 5.1 is part of the operating system and serviced through the operating system lifecycle. Given that Microsoft.WinGet.Client is documented as supporting Windows PowerShell 5.1, and given the commonplace nature of this automation scenario, we expected the module to support it without requiring a separately deployed PowerShell 7 runtime.
Ultimately, the question is whether the current behaviour, where cmdlets documented under a Windows PowerShell 5.1 compatible module reject execution in Windows PowerShell 5.1, is an unintentional product decision or a gap between the documented compatibility story and the actual implementation?
denelon commentedon Oct 7, 2026
Alessandro Riolo (@aledeniz),
The Microsoft.WinGet.Client PowerShell module has mixed support for Windows PowerShell. It does work for Repair-WinGetPackageManager to ensure the client can be updated on the device, but the other cmdlets require PowerShell 7.
The PowerShell team has planned to discontinue support for unpackaged distribution which is adding to some additional complexity here. There is work ongoing to get PowerShell 7 included in Windows, but that would still be a problem for usage in session 0. There is also work ongoing to support package registration for session 0 which would enable calling WinGet directly (it would also enable calling packaged PowerShell 7).
I do not have ETAs for either of those efforts.
Can you provide links to the documentation? I'd be happy to go update it and make it clear. The original intent was to be able to support both Windows PowerShell and PowerShell 7, but it ended up being more complex, and in the end, we decided to hold off based on the work in progress (which has taken far longer than anticipated to complete).
aledeniz commentedon Oct 8, 2026
Demitrius Nelon (@denelon) thank you for the feedback.
The most glaring is the PowerShell Gallery: https://www.powershellgallery.com/packages/Microsoft.WinGet.Client/1.29.380
aledeniz commentedon Oct 8, 2026
Demitrius Nelon (@denelon) I looked up Repair-WinGetPackageManager, that is a WinGet client servicing mechanism, not a PowerShell 7 servicing mechanism.
The moment I am forced to use PowerShell 7, I need an update mechanism for it. In our case - not generalisable - we are going to try to use the Azure Update Manager for the Windows Servers, Intune for the Intune licensed Windows Clients, but we still don't have a mechanism for the non Intune licensed Windows Clients. Buying Intune licenses for those is not an option because there are other missing pre-requisites.
I have seen the below on SCCM, but I wasn't able to figure out if that does indeed include PowerShell 7. I will contact our SMEs to understand if we can still use SCCM on those machines, but I hope you are agreeing that adopting WinGet or Microsoft.WinGet.Client PowerShell module seems quite a struggle without PowerShell 5.1 support. You can read the ticket, the Microsoft support engineers did state multiple times that the supported path is the PowerShell module, none was aware of the PowerShell 7 requirement.
denelon commentedon Oct 9, 2026
Alessandro Riolo (@aledeniz), thanks for the pointers. We had issues with the PowerShell gallery when we listed with only PowerShell 7 support. We ended up having to show it as Windows PowerShell.
It has been quite frustrating trying to figure out a mechanism for the PowerShell module to work properly for both Windows PowerShell and PowerShell 7. I was hoping we'd be able to have the ability for WinGet to be registered for the system context (session 0), but that work has taken longer to get completed, and it will likely only work for newer versions of Windows. The mechanisms are fairly deeply rooted in the OS and will be non-trivial (putting it mildly) to take down into older versions of Windows. That may not end up being an option.