No Output for Winget running as system from "C:\program files\windowsapps\Microsoft.DesktopAppInstaller_1.18.2691.0_x64__8wekyb3d8bbwe"

[Scrat01]

On about 10% of our desktop estate winget.exe produces no console output when running as the Local System Account from "C:\program files\windowsapps\Microsoft.DesktopAppInstaller_1.18.2691.0_x64__8wekyb3d8bbwe"

Winget runs as expected when run as a standard user. This is only happening on about 10% of our devices. The other 90% winget.exe runs as expected for the local system account when run from "C:\program files\windowsapps\Microsoft.DesktopAppInstaller_1.18.2691.0_x64__8wekyb3d8bbwe"

Windows: Windows.Desktop v10.0.19044.2251 System Architecture: X64 Package: Microsoft.DesktopAppInstaller v1.18.2691.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

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

[denelon]

We need to update https://github.com/microsoft/winget-cli/tree/master/doc/troubleshooting with the information regarding running WinGet using the system context. The issue is that we are distributed as an MSIX package which is registered "per user" upon login.

Calling WinGet remotely using the system context requires a separate package and is leveraging the COM API developed for Intune and third-party MDM integration.

[Scrat01]

We need to update https://github.com/microsoft/winget-cli/tree/master/doc/troubleshooting with the information regarding running WinGet using the system context. The issue is that we are distributed as an MSIX package which is registered "per user" upon login.

Calling WinGet remotely using the system context requires a separate package and is leveraging the COM API developed for Intune and third-party MDM integration.

Morning @denelon ,

Thanks for replying. I am using Winget through an Intune app so it is executing as "system" but executed locally. This is working correctly on circa 1500 machines but is failing to produce winget output as system on circa 250 of the machines. I appreciate that as msix it installs per user but i have been executing it from ""C:\program files\windowsapps\Microsoft.DesktopAppInstaller_1.18.2691.0_x64__8wekyb3d8bbwe"\winget.exe" when running it as system.

The problem is if i cant get it working consistently for the whole estate I wont be able to use it as a solution as it would be inconsitent. I have had a look at the new Intune App Store and while it does show promiss I think it still has some growing up to do, hence why I would prefer to use winget.

Many thanks,

Scrat

[denelon]

Have you been able to determine if there are any similarities between the two sets of machines? OS version, App Installer Version, or anything else? I'm wondering if it has to do with whether there has been an interactive logon doing the actual registration or if the App Execution Alias is enabled or disabled.

[Scrat01]

Morning,

Machines are running the same windows 10 version and CU. App installer vesions are also the same. I have tried the Winget preview 1.4.x versions but no change. I have tried toggling the Execution Alias but again no change.

[rozmansi]

Experienced similar issue. After deploying the Visual C++ Redistributables the WinGet starts normally as SYSTEM user.

[mjr4077au]

I've been experiencing this myself and am yet to determine the circumstances. Have had it on Windows 10 and 11 machines, both of which are 22H2, both of which have worked previously also.

The only thing of relevance I can probably add here is that winget.exe exits with code -1073741515 (0xC0000135) after showing nothing to the console.

I could probably build a debug version of winget and see if I trigger some kind of assertion? It'd be good if debug versions were built and had PDBs available though.

EDIT: Testing with debug build won't be needed, can confirm the latest runtime offered above does resolve the issue. These are the runtimes I was using with the Microsoft.DesktopAppInstaller, are they incorrect?

[cgerke]

We need to update https://github.com/microsoft/winget-cli/tree/master/doc/troubleshooting with the information regarding running WinGet using the system context. The issue is that we are distributed as an MSIX package which is registered "per user" upon login. Calling WinGet remotely using the system context requires a separate package and is leveraging the COM API developed for Intune and third-party MDM integration.

Morning @denelon ,

Thanks for replying. I am using Winget through an Intune app so it is executing as "system" but executed locally. This is working correctly on circa 1500 machines but is failing to produce winget output as system on circa 250 of the machines. I appreciate that as msix it installs per user but i have been executing it from ""C:\program files\windowsapps\Microsoft.DesktopAppInstaller_1.18.2691.0_x64__8wekyb3d8bbwe"\winget.exe" when running it as system.

The problem is if i cant get it working consistently for the whole estate I wont be able to use it as a solution as it would be inconsitent. I have had a look at the new Intune App Store and while it does show promiss I think it still has some growing up to do, hence why I would prefer to use winget.

Many thanks,

Scrat

How are you calling it? I'm doing something like this 7zip example....

#region CODE
$winget = $null
$DesktopAppInstaller = "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe"
$SystemContext = Resolve-Path "$DesktopAppInstaller"
if ($SystemContext) { $SystemContext = $SystemContext[-1].Path }
$UserContext = Get-Command winget.exe -ErrorAction SilentlyContinue
if ($UserContext) { $winget = $UserContext.Source }
elseif (Test-Path "$SystemContext\AppInstallerCLI.exe") { $winget = "$SystemContext\AppInstallerCLI.exe" }
elseif (Test-Path "$SystemContext\winget.exe") { $winget = "$SystemContext\winget.exe" }
else { return $false }
if ($null -ne $winget) { $winget }
# Logs $(env:LOCALAPPDATA)\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
& "$winget" install --id "7zip.7zip" --exact --silent --accept-source-agreements --accept-package-agreements | Out-String
#endregion

[kugelbit]

Hey,

I have the same Problem as @Scrat01 on an fresh and patched installed windows 11. winget is installed and i can use it normaly as an local user. but when i try to use it from remote (via C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.20.2201.0_x64__8wekyb3d8bbwe\winget.exe ) in system context no output is printed.

Does anybody has an workaround for this? I also tried the ps7 winget.client module with no success.

[mjr4077au]

Experienced similar issue. After deploying the Visual C++ Redistributables the WinGet starts normally as SYSTEM user.

@kugelbit, this is the solution.

[abraxid]

has something changed? I am still having this issue on DesktopAppInstaller_1.21.3482.0_x64__8wekyb3d8bbwe and MS Visual C++ 14.38.33130 and I get no output from winget when running as system...

[rbrannath]

has something changed? I am still having this issue on DesktopAppInstaller_1.21.3482.0_x64__8wekyb3d8bbwe and MS Visual C++ 14.38.33130 and I get no output from winget when running as system...

It is still an issue, I have been troubleshooting this the whole night before I finally found this issue. After manually installing Visual C++ Redistributables it is working like a charm. Still weird, as it is working just fine as normal user.

@rozmansi thanks! Your comment saved my weekend!

[Jorilx]

Happened to us too right now, installing vcredist fixed the problem