Forum Discussion
WinGet sources cancelled system-wide after repair install
I’ve been troubleshooting a persistent WinGet issue where the winget and winget-font sources consistently fail to update, while the Microsoft Store source updates normally. The problem originally appeared alongside other Windows networking issues, but those were separately traced to Kaspersky encrypted connection scanning. After disabling that feature, normal HTTPS traffic started working again, including Outlook, YouTube Music, and direct curl requests. The WinGet issue, however, remained unchanged.
I then checked Windows integrity. sfc /scannow initially found and repaired corruption, and a later scan reported no integrity violations. DISM also reported that the component store was repairable, so I ran the relevant repair commands. I later performed a Windows 11 repair reinstall that kept my files, applications, and settings. Microsoft Support also had me perform an in-place Windows 11 Pro repair install from an ISO using the "Keep personal files and apps" option. After all of this, the WinGet problem still persisted.
My current WinGet version is v1.29.380, and Microsoft Desktop App Installer is version 1.29.380.0. The sources are registered correctly. winget source list shows the Microsoft Store source, the WinGet source at https://cdn.winget.microsoft.com/cache, and the WinGet font source at https://cdn.winget.microsoft.com/fonts.
The main issue is reproducible every time I run winget source update. The Microsoft Store source updates successfully, but both winget and winget-font immediately return Cancelled. Running winget source reset --force completes successfully, but it does not fix the issue. After the reset, normal winget search commands still fail with the message that WinGet cannot open the sources.
The verbose WinGet logs show the failure occurring while WinGet attempts to retrieve headers from https://cdn.winget.microsoft.com/cache/source2.msix. The failures include 0x80072EFF and 0x80072EFE, with messages indicating that the connection was reset or terminated abnormally. The same behavior occurs when WinGet attempts to access the equivalent source file under the winget-font endpoint.
What makes this particularly strange is that the same CDN URLs work normally outside WinGet. For example, curl -I https://cdn.winget.microsoft.com/cache/source2.msix returns HTTP/1.1 200 OK. I also tested the same URL through the Windows WinHTTP COM interface using WinHttp.WinHttpRequest.5.1, and that request also returned status 200. WinHTTP proxy configuration shows direct access with no proxy server configured.
I also verified the installed WinGet source package. Get-AppxPackage Microsoft.Winget.Source reports version 2026.1009.2124.28 with status OK, and this matches the source version advertised by the WinGet CDN. I re-registered Microsoft.DesktopAppInstaller as well. An earlier attempt failed because the package was in use, but after rebooting and closing related processes, the package was re-registered successfully. This did not change the behavior.
IPv6 was also investigated. The current network does not have functional global IPv6 connectivity, but disabling IPv6 entirely made no difference to WinGet. Kaspersky was also fully disabled during testing, and the WinGet source cancellation still occurred, so the problem does not appear to be caused by Kaspersky.
To rule out corruption in my main Windows profile, I created a completely fresh local administrator account and tested WinGet there. The exact same behavior occurred. winget --version worked normally, but winget source update showed msstore: Done, followed by winget: Cancelled and winget-font: Cancelled. A normal winget search command also failed to open the sources. This confirms that the issue is not specific to my main user profile.
At this point, the issue survives source resets, App Installer re-registration, a fresh administrator account, DISM/SFC repairs, and a full in-place Windows repair installation. Direct access to the WinGet CDN works through other Windows networking methods, while WinGet itself consistently fails when opening or refreshing its pre-indexed package sources.
Microsoft Support reviewed the troubleshooting and agreed that, because the issue occurs on a fresh local administrator account and still exists after an in-place Windows repair install, it appears to be a deeper WinGet or App Installer related issue rather than a normal profile or general network problem. They recommended escalating the issue to the WinGet engineering community for further investigation.
1 Reply
Your tests already go well beyond a routine source reset: both CDN sources fail across profiles and repair installs, while Microsoft Store succeeds. A successful HEAD request through curl or WinHTTP proves that particular request works, not that WinGet’s entire source retrieval follows the same path successfully. I would stop repeating Windows reinstalls and submit a focused reproduction to the Microsoft WinGet client repository, as Support suggested. Collect winget --info, source list, App Installer version, Windows build, and a fresh winget source update --verbose-logs --open-logs run. Include the exact errors and a concise list of completed tests, especially the clean profile and direct HTTP results. If permitted, compare once on another network to help distinguish the client from the network path. Redact usernames and sensitive log content. The evidence warrants investigation, but does not yet establish a specific WinGet defect or guaranteed workaround.
