winget-cli
winget-cli copied to clipboard
Failed in attempting to update the source: winget
Brief description of your issue
Winget hasn't been able to access the winget source to fetch updates and new packages. I have tried resetting the sources, changing internet connections, checking Windows Firewall, etc but none of these resulted in any improvement.
Steps to reproduce
> winget upgrade
Failed in attempting to update the source: winget
Failed when searching source; results will not be included: winget
No installed package found matching input criteria.
> winget source update
Updating all sources...
Updating source: msstore...
Done
Updating source: winget...
Cancelled
Expected behavior
For winget to be able to access its repo, update its sources and then upgrade my installed applications.
Actual behavior
Whatever these logs tell us:
> winget upgrade
WinGet-2022-01-01-11-39-54.319.log
> winget source update
WinGet-2022-01-01-11-41-02.453.log
Environment
> winget --info
Windows Package Manager (Preview) v1.2.3411-preview
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.22000.376
Package: Microsoft.DesktopAppInstaller v1.17.3411.0
Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
I'm getting the same error but it seems to still be able to retrieve the upgrades:
> winget upgrade
Failed in attempting to update the source: winget
Name Id Version Available Source
------------------------------------------------------------------------------
Microsoft OneDrive Microsoft.OneDrive 21.220.1024.0005 22.033.0213.0002 winget
1 upgrades available.
> winget search powertoys
Failed in attempting to update the source: winget
Name Id Version Source
--------------------------------------------------------
Microsoft PowerToys XP89DCGQ3K6VLD Unknown msstore
PowerToys (Preview) Microsoft.PowerToys 0.57.2 winget
That said, source update
still gets cancelled:
> winget source update
Updating all sources...
Updating source: msstore...
Done
Updating source: winget...
██████████████████████████████ 3.44 MB / 3.44 MB
Cancelled
> winget --info
Windows Package Manager v1.2.10271
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.22000.593
Package: Microsoft.DesktopAppInstaller v1.17.10271.0
winget source reset
doesn't fix this.
Now winget won't retrieve updates at all. It's pretty much useless now.
Is no one else experiencing this?
I'm getting this exact behaviour when I try to run this command through powershell remoting (or winrm).
I'm trying to use winget to provision a Vagrantbox and this problem pretty much makes this impossible.
I'm getting this exact behaviour when I try to run this command through powershell remoting (or winrm).
cc @horihel: If you're using the .msixbundle
file then it's not a supported scenario due to MSIX's limitations. I believe the MSIX engineering team is tracking this issue but it's on their backlog for now.
If you want to use WinGet through WinRM then you'll need to run WinGet unpackaged. You can do this by extracting the contents of the AppInstaller_X64.msix
file to your chosen location and run it via winget.exe
. You will also have to do this if you want to run WinGet as SYSTEM context.
^ Note: It's been a while I've played around with WinGet through WinRM but lots of people have managed to get it up and running in previous releases of WinGet unless there was something that was changed in the recent releases of WinGet.
I've checked and yes, my vagrant-boxes indeed use the MSIXbundle.
Interestingly, i can make it work by using "powershell_elevated_interactive: true" with the vagrant:shell provisioner. This parameter forces the shell process into the interactive session of the "vagrant" user (which has to be logged in of course). winget seems to be happy with this.
Any winget invocations after that (at least during initial provisioning) work - even in non-interactive sessions. Probably because they don't need to update source any more.
Something's definitely broken with winget
recently.... getting this error now on multiple PCs in my org when we didn't used to (including my own when running from an elevated PowerShell terminal). Not sure I have much else to add to this ticket besides "me too".
Same here, trying to install Powershell per these docs.
winget search Microsoft.PowerShell
Failed in attempting to update the source: winget
Failed when searching source; results will not be included: winget
No package found matching input criteria.
winget install --id Microsoft.Powershell --source winget
Failed when opening source(s); try the 'source reset' command if the problem persists.
An unexpected error occurred while executing the command:
0x8a15000f : Data required by the source is missing
Also I assume this is weird:
winget source update
Updating all sources...
Updating source: msstore...
Done
Updating source: winget...
██████████████████████████████ 0%
Cancelled
From the logs:
2022-06-16 15:43:50.989 [REPO] Source add/update failed, waiting a bit and retrying: winget
2022-06-16 15:43:53.161 [CORE] Did not find extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2022-06-16 15:43:53.161 [CORE] Downloading to path: C:\Users\alert\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix
2022-06-16 15:43:53.161 [CORE] Started applying motw to C:\Users\alert\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix with zone: 3
2022-06-16 15:43:53.162 [CORE] Finished applying motw
2022-06-16 15:43:53.162 [CORE] WinINet downloading from url: https://winget.azureedge.net/cache/source.msix
2022-06-16 15:43:53.556 [CORE] Download completed.
2022-06-16 15:43:53.557 [CORE] Starting AddPackage operation #1: file:///C:/Users/alert/AppData/Local/Temp/WinGet/Microsoft.Winget.Source_8wekyb3d8bbwe.msix SkipSmartScreen: 1
2022-06-16 15:43:53.557 [CORE] Begin waiting for operation #1
2022-06-16 15:43:53.557 [CORE] Begin blocking for operation #1
2022-06-16 15:43:53.651 [CORE] Deployment operation #1: A specified logon session does not exist. It may already have been terminated.
2022-06-16 15:43:53.651 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!00007FFC72A7657A: (caller: 00007FFC72A76C09) Exception(2) tid(2b0c) 80070520 A specified logon session does not exist. It may already have been terminated.
Msg:[Operation failed: A specified logon session does not exist. It may already have been terminated.
]
2022-06-16 15:43:53.656 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(516)\WindowsPackageManager.dll!00007FFC72BCFA23: (caller: 00007FFC729DB9AD) LogHr(2) tid(2b0c) 80070520 A specified logon session does not exist. It may already have been terminated.
Msg:[D:\a\_work\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!00007FFC72A7657A: (caller: 00007FFC72A76C09) Exception(2) tid(2b0c) 80070520 A specified logon session does not exist. It may already have been terminated.
Msg:[Operation failed: A specified logon session does not exist. It may already have been terminated.
]
]
I have the same Problem, also with the weird fail in the logs mentioning that D:\a\_work\1\s\external\pkg\...
path.
I get this whenever I try to intall or update anything at all.
The log from running winget source update
:
2022-11-05 12:24:47.488 [CORE] WinGet, version [1.3.2691], activity [{D89A021F-2E42-4585-AC41-8EBE5B870E73}]
2022-11-05 12:24:47.488 [CORE] OS: Windows.Desktop v10.0.19044.2130
2022-11-05 12:24:47.488 [CORE] Command line Args: winget source update
2022-11-05 12:24:47.488 [CORE] Package: Microsoft.DesktopAppInstaller v1.18.2691.0
2022-11-05 12:24:47.488 [CORE] IsCOMCall:0; Caller: winget-cli
2022-11-05 12:24:47.494 [CLI ] WinGet invoked with arguments: 'source' 'update'
2022-11-05 12:24:47.494 [CLI ] Found subcommand: source
2022-11-05 12:24:47.494 [CLI ] Found subcommand: update
2022-11-05 12:24:47.494 [CLI ] Leaf command to execute: root:source:update
2022-11-05 12:24:47.494 [CLI ] Executing command: update
2022-11-05 12:24:47.498 [REPO] GetCurrentSourceRefs: Source named 'microsoft.builtin.desktop.frameworks' from origin Default is hidden and is dropped.
2022-11-05 12:24:47.512 [REPO] Named source requested, found: msstore
2022-11-05 12:24:47.513 [REPO] Named source to be updated, found: msstore
2022-11-05 12:24:47.613 [REPO] Named source requested, found: winget
2022-11-05 12:24:47.614 [REPO] Named source to be updated, found: winget
2022-11-05 12:24:47.730 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerCommonCore\MsixInfo.cpp(311)\WindowsPackageManager.dll!00007FF8035B65C7: (caller: 00007FF80361F80F) Exception(1) tid(3e70) 8051100F
2022-11-05 12:24:47.730 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(53)\WindowsPackageManager.dll!00007FF80372F321: (caller: 00007FF803612D1C) LogHr(1) tid(3e70) 8051100F Msg:[D:\a\_work\1\s\external\pkg\src\AppInstallerCommonCore\MsixInfo.cpp(311)\WindowsPackageManager.dll!00007FF8035B65C7: (caller: 00007FF80361F80F) Exception(1) tid(3e70) 8051100F ]
2022-11-05 12:24:47.730 [REPO] Source add/update failed, waiting a bit and retrying: winget
2022-11-05 12:24:49.744 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerCommonCore\MsixInfo.cpp(311)\WindowsPackageManager.dll!00007FF8035B65C7: (caller: 00007FF80361F80F) Exception(2) tid(3e70) 8051100F
2022-11-05 12:24:49.744 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(634)\WindowsPackageManager.dll!00007FF80372EF51: (caller: 00007FF80353B8F3) LogHr(2) tid(3e70) 8051100F Msg:[D:\a\_work\1\s\external\pkg\src\AppInstallerCommonCore\MsixInfo.cpp(311)\WindowsPackageManager.dll!00007FF8035B65C7: (caller: 00007FF80361F80F) Exception(2) tid(3e70) 8051100F ]
2022-11-05 12:24:49.744 [REPO] Failed to update source: winget
2022-11-05 12:24:49.970 [CLI ] Leaf command succeeded: root:source:update
An emtpy file named D:\a
did exist at some point, but I deleted it, which didn't change anything.
The sources seem correct:
winget source list
Name Argument
-----------------------------------------------------
msstore https://storeedgefd.dsx.mp.microsoft.com/v9.0
winget https://cdn.winget.microsoft.com/cache
Same issue here , started 2 days ago. No changes to the system. I see a lot of people commenting, but does anyone know why this is happening?
fresh install windows 11 Edition Windows 11 Pro Version 22H2 Installed on 11/5/2022 OS build 22621.755 Experience Windows Feature Experience Pack 1000.22636.1000.0
winget upgrade Failed in attempting to update the source: winget Failed when searching source; results will not be included: winget No installed package found matching input criteria.
I have also been having this issue lately
Windows: Windows.Desktop v10.0.22621.755
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.2161.0
Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
fresh install windows 11 Edition Windows 11 Pro Version 22H2 Installed on 11/5/2022 OS build 22621.755 Experience Windows Feature Experience Pack 1000.22636.1000.0
winget upgrade Failed in attempting to update the source: winget Failed when searching source; results will not be included: winget No installed package found matching input criteria.
Used VPN Canda server the source for winget update and working for install app
i have this problem too!
I am also having this issue across multiple devices in our fleet on Win 10 and Win 11. I noticed it last Friday. The issue seems to be on MS's side or with Winget. Please fix this as it is making winget to unreliable for our use case.
I'm having this issue as well, I did notice if I VPN out the issue is resolved. I'm using OPNSense as a firewall, but I'm not sure that it's blocking anything either.
it's working fine for me now, look like it was an issue on their end maybe their firewall temporary not accepting my vpn
It’s intermittent. On some PCs it works occasionally then stops. Some not at all ScottOn Nov 11, 2022, at 07:29, o13e @.***> wrote: it,s working fine for me now
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
I managed to resolve "Failed in attempting to update the source: winget" with solution provided at the following link: https://github.com/microsoft/winget-cli/issues/1999#issuecomment-1127497598
Which basically says:
I was having the same problem recently. I deleted the "installed.db" file and solved the problem. The location of the file "installed.db": %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\StoreEdgeFD
and then I ran
winget source update --verbose-logs
Which seems to have managed to successfully update winget sources.
same thing for me at version v1.4.3132-preview
receiving the same. notice Cancelled at 91%
PS C:\Users\Burton.Rodman> winget search postman
Failed in attempting to update the source: winget
Failed when searching source; results will not be included: winget
No package found matching input criteria.
PS C:\Users\Burton.Rodman> winget source update --verbose-logs
Updating all sources...
Updating source: msstore...
Done
Updating source: winget...
███████████████████████████▎ 91%
Cancelled
PS C:\Users\Burton.Rodman> winget --info
Windows Package Manager v1.4.11071
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.22621.1848
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.11071.0
I have the same issue.
PS C:\Users\Michael Vega\Documents> winget source update --verbose-logs
Updating all sources...
Updating source: msstore...
Done
Updating source: winget...
█████████████████████████████ 8.00 MB / 8.24 MB
Cancelled
PS C:\Users\Michael Vega\Documents> winget --info
Windows Package Manager v1.5.2201
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.19045.2965
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.20.2201.0
Same here.
logfile:
WinGet-2023-09-27-17-26-29.138.log
EDIT: Today the problem seems to have disappeared 🤔
Same here.
Same.
The CDN is down again (https://cdn.winget.microsoft.com/cache).
winget source list
CDN is down here as well.
Thanks for being down again. Using your tool to install clients... now I can install it manually.
Same.
at the same time, in the folder %AppData%\..\Local\Temp\WinGet
there is an installation file Microsoft.Widget.Source_8wekyb3d8bbwe.msix
which updated winget with a double click without any problems
after that, all package sources became updated
Same issue here (see attached)
Is there any work around yet?
Only one of the machines I use has this problem, although they return the same content in the list of sources when ran:
winget source list
And 'source update' or 'upgrade' shows the same result as @TIT8 .
Manually downloading and installing from here got me working: https://winget.azureedge.net/cache/source.msix
Manually downloading and installing from here got me working: https://winget.azureedge.net/cache/source.msix
Here too!
The CDN seems to be down again. Once we've manually installed https://winget.azureedge.net/cache/source.msix , how do we winget upgrade --all
while skipping the source update?
The only thing that worked for me (and I suspect will work for lots of people): use a VPN to the US region, as mentioned in https://github.com/microsoft/winget-cli/issues/1826#issuecomment-1305894692
These regional CDN issues rarely get resolved quickly because "works for me" for most Microsoft employees.
I had the same problem on two devices. The solution in my case was to updating the package installer from Microsoft (App-Installer
) at https://www.microsoft.com/p/app-installer/9nblggh4nns1. Then all of a sudden the problems were gone.
I suspect that the solution above by @tsull360 goes in the same direction.
The solution in my case was to updating the package installer from Microsoft (
App-Installer
)
Out of the box Windows 11 23H2 (fresh install using ISO from Microsoft) results in a broken winget install. Windows Store installs a bunch of unwanted garbage on the first access to the internet, but apparently App Installer needs to be upgraded manually.
A bit of a shame that this doesn't work out of the box, nor the sort of error message that end-users can manage to solve themselves, at a minimum the error message could be more useful.