Failed in attempting to update the source: winget

[sebaFlame]

Brief description of your issue

Winget will not update when running as normal user. It will update when run under admin permissions, but then it can not upgrade any app. Updating/upgrading used to work as user.

Steps to reproduce

PS C:\Users\C_B-A> winget upgrade --all --verbose
Failed in attempting to update the source: winget
Name                                       Id                           Version   Available Source
--------------------------------------------------------------------------------------------------
Microsoft .NET SDK 5.0.214 (x64)           Microsoft.DotNet.SDK.5       5.0.214   5.0.408   winget
Microsoft Visual C++ 2005 Redistributable  Microsoft.VCRedist.2005.x86  8.0.56336 8.0.61001 winget
Microsoft .NET SDK 6.0.203 (x64)           Microsoft.DotNet.SDK.6       6.0.203   6.0.405   winget
4 upgrades available.

(1/4) Found Microsoft .NET SDK 5.0 [Microsoft.DotNet.SDK.5] Version 5.0.408
This application is licensed to you by its owner.
An unexpected error occurred while executing the command:
0x80070005 : unknown error

(2/4) Found Microsoft Visual C++ 2005 Redistributable [Microsoft.VCRedist.2005.x86] Version 8.0.61001
This application is licensed to you by its owner.
An unexpected error occurred while executing the command:
0x80070005 : unknown error

(3/4) Found Microsoft .NET Runtime 3.1 [Microsoft.DotNet.Runtime.3_1] Version 3.1.32
This application is licensed to you by its owner.
An unexpected error occurred while executing the command:
0x80070005 : unknown error

(4/4) Found Microsoft .NET SDK 6.0 [Microsoft.DotNet.SDK.6] Version 6.0.405
This application is licensed to you by its owner.
An unexpected error occurred while executing the command:
0x80070005 : unknown error

15 package(s) have version numbers that cannot be determined. Use --include-unknown to see all results.

or

PS C:\Users\C_B-A> winget source update --verbose-logs
Updating all sources...
Updating source: msstore...
Done
Updating source: winget...
Cancelled

The log from the above command:
WinGet-2023-02-22-13-49-49.557.log

Expected behavior

Winget to update its sources and upgrade apps.

Actual behavior

Winget is not updating or upgrading.

Environment

PS C:\Users\C_B-A> winget --info
Windows Package Manager v1.4.10173
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19045.2604
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.10173.0

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

User Settings: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json

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

[Trenly]

Does running winget source reset --force in an administrator shell resolve the issue? The command resets all sources back to their default configuration

[sebaFlame]

It does not. I still can not update/upgrade as user or upgrade as administrator. In the attached file (WinGet-2023-02-22-13-49-49.557.log you'll find several access denied errors.

[JuryA]

@sebaFlame: I have similar problems - everything started after I installed the preview version as Provisioned Appx Package (Add-AppxProvisionedPackage) over the last version installed from Microsoft Store and after that, I used this Winget to update the store version to the latest one. Now I cannot remove Provisioned Appx Package and Winget is working but still messing the ACL on the filesystem causing this Access Denied and related issues. The root cause of this issue is (see attached picture):

Deleting the folder C:\Users\<your_username>\AppData\Local\Temp\WinGet (fixing permissions is much more complicated - I have a domain account) fixes the Access Denied problem but not the problem with uninstalling Provisioned Appx.

@MSWingetTeam: Why is the version in the MS Store different from the manual installation version? MSIXBUNDLE is similar but cannot be installed via Add-AppxPackage! Why is it so difficult to deploy!? Why does MS Store handle dependencies but manual installation doesn't!? I fully understand that there is a lot of work in the background (Win32 API code converted to .NET C#, etc.) but these issues are stupid complications for mere mortals. No comment what if I come across the problems with UAC... Sorry for my excitation but the last straw was expired TLS certificate on CDN - that's not good situation! No offense...

[Masamune3210]

Why is the version in the MS Store different from the manual installation version?

Because it's a lot quicker and easier to publish a release on GitHub than it is to push a release through the store process

MSIXBUNDLE is similar but cannot be installed via Add-AppxPackage!

You should be able to just double click them if Add-AppxPackage doesn't work

Why is it so difficult to deploy!? Why does MS Store handle dependencies but manual installation doesn't!?

Because it's fundamentally a different way of installing. When installing through the store, it automatically grabs the packages for any missing dependencies and installs them as well. For manual installation, you are directly telling the system to install this specific package, no more, no less

I fully understand that there is a lot of work in the background (Win32 API code converted to .NET C#, etc.) but these issues are stupid complications for mere mortals. No comment what if I come across the problems with UAC... Sorry for my excitation but the last straw was expired TLS certificate on CDN - that's not good situation! No offense

To err is to be human, and last I checked devs are still human. Things are bound to break as they move, it's when they don't get fixed that you should start to worry, not so much that they break in the first place. No team can be expected to crystal ball their way through every possibility

[JuryA]

Why is the version in the MS Store different from the manual installation version?

Because it's a lot quicker and easier to publish a release on GitHub than it is to push a release through the store process

MSIXBUNDLE is similar but cannot be installed via Add-AppxPackage!

You should be able to just double click them if Add-AppxPackage doesn't work

These answers are not explaining my question - why I cannot install appx/msix bundle with Add-AppxPackage? Sorry, but double-click is simply not working over SSH! Why is the "double click" not implemented to Add-AppxPackage? Imagine that I'm a regular user connected via SSH to a PowerShell session and want to install Winget ... no access to the UI, RDP, etc. How I can do the "double click"? If it's possible to install Winget with Add-AppxProvisioningPackage, why it's not possible via Add-AppxPackage? Why it is possible via "double click"? Why the "double click" doesn't need the license file? This is my question - seriously.

Why is it so difficult to deploy!? Why does MS Store handle dependencies but manual installation doesn't!?

Because it's fundamentally a different way of installing. When installing through the store, it automatically grabs the packages for any missing dependencies and installs them as well. For manual installation, you are directly telling the system to install this specific package, no more, no less

I don't agree... MDM is doing that how? Why it's not possible to use the same CIM API? If exist a way how to do that, this is only an excuse. If I can install Store App with Winget itself, your argument is odd. Why Add-AppxPackage doesn't accept license files? Why is the license file used at all? This is the correct question! I don't want to start a flame war here - I like Winget really a lot. But don't stick your head in the sand - these questions had to come sooner or later.

I fully understand that there is a lot of work in the background (Win32 API code converted to .NET C#, etc.) but these issues are stupid complications for mere mortals. No comment what if I come across the problems with UAC... Sorry for my excitation but the last straw was expired TLS certificate on CDN - that's not good situation! No offense

To err is to be human, and last I checked devs are still human. Things are bound to break as they move, it's when they don't get fixed that you should start to worry, not so much that they break in the first place. No team can be expected to crystal ball their way through every possibility

I fully agree with you that err is human. But those errors are caused by overengineering of the wheel. I think that removal of old binaries was a big mistake - a much better way could have been to install using one of the older versions - as far as I know, they were also able to install applications from the Store, or not?

Don't take it personally - take it as a serious critical view of the matter. It may sound too aggressive now, but it's not meant to be - it's still only feedback.

[sebaFlame]

I have a non standard (system-wide) TEMP location. I can not find one under %LOCALAPPDATA%/Temp. I removed the WinGet directory in the system-wide temp and this did not fix the issue.

[sebaFlame]

I gave "Everyone" "Full Control" on that temp directory and now update works. Upgrade does not work. It's giving Access Denied when the installer gets executed. I believe it can not acces the extracted setup files.

[sebaFlame]

After manually adding the group "Administrators" to the downloaded installer (.exe/.msi) under %TEMP%/WinGet I can get upgrade to work. If I change any of the permissions on the directories, WinGet resets them. I also have a non standard Administrator account.

[KineticTheory]

@sebaFlame Thank you for adding the notes above. Your experience provided a hit that fixed my issue. I removed all files from %TEMP%, rebooted and now winget is working again. I'm guessing there were some left over tmp files with bad permissions that caused winget to fail like this:

❯ winget upgrade Graphviz
Failed in attempting to update the source: winget
Found Graphviz [Graphviz.Graphviz] Version 7.1.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
An unexpected error occurred while executing the command:
0x80070005 : Access is denied.

[sebaFlame]

I've changed the modified %TEMP% back to %LOCALAPPDATA%/Temp on the user account and everything is working again. WinGet might be using a hard-coded temp path?

[sebaFlame]

@MSWingetTeam I believe this is directly related to #2945 . I also had to add CREATOR OWNER permissions on the the custom %TEMP%. When I add Administrators group, it gets removed when I call winget. This is why I can't install anything.

[sebaFlame]

I installed the latest preview (https://github.com/microsoft/winget-cli/releases/tag/v1.5.441-preview) and this fixed the issue. Closing!

[Montigomo]

this helps me

# run under powershell.exe !!!
$smpath = "$env:TEMP\source.msix"
Invoke-WebRequest -Uri https://cdn.winget.microsoft.com/cache/source.msix -OutFile $smpath
Add-AppxPackage -Path $smpath 

[Frxhb]

this helps me

# run under powershell.exe !!!
$smpath = "$env:TEMP\source.msix"
Invoke-WebRequest -Uri https://cdn.winget.microsoft.com/cache/source.msix -OutFile $smpath
Add-AppxPackage -Path $smpath 

same! Thank you