Failed in attempting to update the source: winget - No applicable installer found #2114
Comments
ghost
added
the
|
|
|
This is also a clean Windows 11 install. |
If manually installing the At least from my testing installing MSIX / APPX files via the Windows Package Manager seems to split the installation files between Also by clean installation I'm referring to installing Windows 11 via an ISO image / VHDX file and then running Microsoft Store's "Get updates" button to get the latest version of the Windows Package Manager. Official Windows 11 ISOs already have the correct permissions for various OS files and folders, and the correct security descriptors. You will also probably run into the same issue in Windows Sandbox because it uses your existing OS files to setup a container image which means if there's a third-party application that made changes to some OS files (like If you think your OS files are somehow corrupted then you can look into rebuilding your OS files by launching |
denelon
added
Issue-Bug
|
I mean.. I have Steam, VS Code, OBS, a couple more programs and Store apps. I'm actually not even sure if I wanna install whatever you linked there, I'm that cautious.
Haven't touched either of those.
That is also what I meant and what I did (in addition to Windows Updates).
Not sure what you mean.
If I need to resort to an in-place upgrade a week into a clean install and cautious usage then there is something seriously wrong and will break again a week after. |
As you can see, most of the things on there are either preinstalled or by Microsoft, as is the thing I'm trying to install. |
|
What about running
There are various third-party applications that can sometimes break your OS files / registry entries into bits and pieces even if you never touched or never installed CCleaner before. It'll also break more than just WinGet so other applications could be impacted without you knowing about it.
It's the exact same Download URL that you shared in your original post as part of your error logs but you can also run
WinGet can be manually installed via the You could try to reproduce your issue there if you wanted to and check what the outcome is. I'm not able to do this because I cannot reproduce this issue.
Not uncommon. There was a user who blamed WinGet for breaking their OS when in theory it was caused by the user (#1005) while other issues are related to CCleaner breaking OS installation. Sometimes there's just a lot variables on how issues like this can happen because of how complex Windows is. If you've already tried to redeploy the source file by running I'm not really that careful with my installation of Windows but I have yet to see anything break on my end even though I'm running Insider Preview builds of Windows 11. Although you mentioned that it's a 1-week old installation, I'm more talking about a 5-minute old installation which I was able to achieve via Hyper-V using a VHDX file to provide you a quick PoC. I don't know what exactly caused this issue other than the fact that it's definitely an issue on your end because |
|
Did you try reproducing on a fully up-to-date Windows install?
I posted a list of everything installed above. |
Yes I did. I used the Windows 11 ISO (22000.1) and the Windows 11 VHDX (22000.613) from the build release share and I also downloaded the Windows 11 ISO from https://www.microsoft.com/en-us/software-download/windows11 but still unable to reproduce this issue. Using the VHDX was faster than ISO because it already included the latest Cumulative Update (CU) and also skips most of the installation phase other than the OOBE for user name, password, etc. All that was left for me were Microsoft Defender Antivirus and .NET Framework 3.5 / 4.8 updates which installed quite fast using Windows Update, and even though it didn't require a reboot for those two updates, I ended up rebooting anyways. Using the ISO did take longer than VHDX because it has to go through the installation phase then OOBE then OOBE installs a Cumulative Update (CU) then OOBE again but for username, password, etc. After that I have to install everything, such as 22000.613, in Windows Update and update all of the applications from the Microsoft Store. These are pictures taken from the VM that used an ISO image which is also the same outcome for VHDX: Screenshots from ISO (Hyper-V)
winget source update (logs from DiagOutputDir)There's also a new optional update released today which seems to include a bug fix for MSIX but I don't know if that'll change anything: https://www.windowslatest.com/2022/04/26/windows-11-kb5012643-released-heres-everything-new-and-improved/
It should be posted in Feedback Hub because the Windows Servicing & Delivery (WSD) team are the ones that manages the production builds of Windows 11 and the Feedback Hub is always being checked by various teams regardless of how many upvotes a particular issue gets. WSD heavily prioritizes useful bug fixes, security fixes, and some features from the Windows Insider Preview builds into production builds of Windows 11.
I'm sure the developers of those applications are already aware of that due to the amount of complaints they receive. Also, I didn't show it in the VM because that application doesn't allow VMs to install it but it works fine on my PC running Dev Channel builds: |
I would if they had a website. Also just because you can't reproduce doesn't mean it's "on my end." Using a "5 minute clean install" perpetually is not realistic either. You're also running a way different winget version from me. Overall there could be so many other variables that are not "on my end" so I don't think such accusations are warranted or that the issue should be disregarded on that ground alone.
Did you download via Media Creation Tool? |
I guess my point here is that this shouldn't be happening to you regardless if it's a "5 minute clean install." or not. If I cannot reproduce it under a "5 minute clean install" then I shouldn't be able to reproduce it under a 2-month-old dirty install or even a 1-year-old dirty install which is what I'm expecting and is what I'm seeing. My 2-month-old and 1-year-old installs work completely fine with more than 30+ applications installed, though, those are running on Windows Insider Preview builds as I don't have any PCs running on production builds of Windows 11 other than pure virtual machines. Using a clean (a.k.a. fresh) installation of Windows 11 from scratch on a virtual machine or on a separate partition alongside your affected OS is more than enough to find where the root cause is which is what I would do if I ever had this issue.
Yes you're right that it can be caused by many things but it's hard to tell what exactly happened without you sysprepping your machine and sharing the sysprepped image to the public which obviously won't happen due to personal files, etc. My demonstration was that it's just a Proof of Concept (PoC) to show you that the fault wasn't caused by WinGet and wasn't caused by the OS updates from various Cumulative Updates that you've installed. There was actually a Cumulative Update that broke some stuff, including WinGet and Windows Subsystem for Linux 2, but that was several months ago and has already been bug fixed. Full OS upgrades would also be a different type of situation but not when you went from RS5 (Windows 10) to 21H2 (Windows 11) via a clean install. I'm also still using the same PC where I installed 1000+ apps to play around with WinGet packages and uninstalled all of them so that cluttered all of my drives, registry entries, etc. but still no issues here.
It's the same one you're running. Yours (WinGet): 1.2.10271 Yours (App Installer): 1.17.10271.0 This is listed in your original post: This is my picture: Version numbers do look the same to me, and yes, it's from the Microsoft Store. I purposely didn't sign in with my personal Outlook email address because then I would get automatically upgraded from
If other people were able to reliably reproduce this issue then I wouldn't of jumped into conclusions in the first place because the GitHub issue tracker and Feedback Hub would be filled with issues like this one which would obviously get the engineering team's attention and those issues would then get prioritized for a bug fix. I can, of course, reproduce the issue if I changed the permissions for the WinGet mostly downloads installers to Even if you've never touched those folders before, WinGet and other programs do, in fact, touch it but WinGet doesn't modify any folder permissions. If your folder permissions are incorrect then WinGet will tell you that in the logs. It might not be user friendly because it doesn't exactly tell you which folder is giving you Rest of the stuff in WinGet is done purely by the installers. All WinGet does is run installers with silent switches. WinGet doesn't modify any local files right now—not until portable apps and zip support becomes a thing in the future which is coming soon—this is all done by installers. That means WinGet doesn't play around with your For what it's worth all that's happening on your side is that WinGet is failing to deploy the This isn't a network issue on Microsoft's side because it successfully downloaded the
Yes I did. One of the ISOs were downloaded from https://www.microsoft.com/en-us/software-download/windows11. Another one of the ISOs were downloaded from within the Media Creation Tool. Regardless of which SKU I used the outcome will always be the same for me because the system OS files are still going to be the same as the only thing that's different there is licensing. This would be a different story if this was Home / Pro / Enterprise vs Server or LTSC because the installation methods for some areas are vastly different. These are also not UUPdump ISOs as UUPdump doesn't create an ISO that's consistent to the official Windows 11 ISOs. I haven't used them in over 2 years when the easiest way is that I can grab whatever install media I want from the build release share ;) (EDIT): Here's a picture from a "Standard account". WinGet2 is created via the Settings app and has no administrator privileges everything required a password but |
My bad, istg I saw a different version :D must'a been tired. What should the permissions be for |
|
Also I've come to the conclusion that the error only comes up occasionally, while other times the upgrade and install commands seem to go through just fine. |
I haven't had the time to dig into that yet. If you're still able to reproduce the issue then maybe capture via Sysinternals' Process Monitor? That will allow you to see what's happening and whether it's a first-party application or a third-party application that's doing this. It's as far as you'll get to debugging this issue without doing an in-place upgrade or trying to reproduce on a second partition with a fresh installation of Windows to check if it's a local issue, a client issue, or a server issue.
I don't think so as Windows doesn't ship with any monitoring software that's similar to Process Monitor.
This isn't the case according to the logs that you posted. There are 2 stages:
Download works because of this: Install fails because of this: I run preview builds of WinGet all the time so I see issues way earlier than most people. I ran into issues with unstable servers (was really just the publishing pipelines playing around with the |
|
Then why does it only work sometimes? Once it starts erroring out again, I'll make sure to get the logs.
|
A variety of reasons but it has nothing to do with server side. Only way you'll be able to tell is to use Process Monitor running in the background and then trying to repeoduce the issue which should tell you what process is accessing that path. ^ It'll also be able to tell whether Microsoft Defender is playing around with it which can happen sometimes. If you think it's happening server-side then you should capture logs via Fiddler but for this you'll need to be able to reproduce consistently as Fiddler will prevent you from connecting to certain websites due to MITM. |
|
I've attached the procmon logfile. Update: Here it went from being inaccessible back to working in a span of minutes: |
What about running
Whether or not you're able to reproduce it consistently or periodically have you tried to do an in-place upgrade to solve this yet? It will replace your system OS files with fresh ones. Even if you're only running first-party apps and that your install is less than a month old you should still do an in-place upgrade. It's an alternative option for you to explore.
Just so you know I wouldn't be commenting here if it wasn't a local issue because I could leave that up to the WinGet engineering team to solve ;) Most (not all of them) of the "Access is denied." issues in this repository were regarded as a local issue and that's to be expected as these "Access is denied." errors cannot be easily solved via an update to WinGet or App Installer. ^ This (above) could consist of:
I never ran into issues with my installation of Windows 10 / Windows 11 so I'm unable to expand on "a lot more that I'm missing here." but this issue still seems to be a local issue for you which means that if it's not a server-side issue and if it's not a client-side issue then you may have already gotten your answer here which is why I suggested you to do an in-place upgrade first in #2114 (comment) and then see if you're still able to reproduce it. WinGet also entered GA in May 2021 which means a lot of people have started using WinGet between May 2021 and May 2022 and there hasn't been an "Access is denied." issue that isn't a local issue. ^ #1848 required an in-place upgrade to solve that and the user isn't seeing that issue anymore. If you're still able to reproduce this when you've done an in-place upgrade then the issue would be caused by whatever changes that's been done to your OS. If you're still able to reproduce this on a separate disk partition or on a virtual machine then it's an OS issue which you should report to the Windows Feedback Hub. |
|
I'd rather do a clean install than the neither-here-nor-there "solution" that's an in-place upgrade. More importantly though, why would I do an in-place upgrade?
Do you happen to know which policies are known to cause this? I suspect that even when it's not throwing the error it's still not working. |
|
Just to update, the It doesn't even throw a warning anymore, just doesn't list anything new, even though it successfully updates and resets sources. |
|
Another update: Every other package upgrade (e.g. VSCode, PowerToys, Docker) is still ignored. |
I've no idea as I've never tinkered around with any policies as most of the policies on my device are pretty much set up automatically via Azure Active Directory (AAD). If this is actually a corporate device then it might be best to contact your employer about it since they might have custom policies in place which are not on Windows by default. This will also be the same for in-place upgrades and fresh installation of Windows as those policies will be re-applied. I'm afraid that you're pretty much stuck here encountering the same issue with no way to solve this other than doing the above (or wait for the next feature update for Windows 11 which will force you do to an in-place upgrade) so I wouldn't be surprised if you're still going run into this issue one year later which is why it's best for you to make the decision now rather than waiting magically to fix itself. If you're still running into this issue then Scoop (focuses on portable apps) or Chocolately (similar to WinGet but more powerful than WinGet) are good alternatives to WinGet while you end up getting it fixed.
Yes and that's because you're only running into this issue periodically and not all the time. WinGet's So you'll have to give it some time to update. Most people should see it update every 5 minutes (which is the default) when running |
|
I'm still having this issue and now I can't even fix it by myself anymore. What I've tried:
I also tried updating to the newest version of Winget CLI, as well as re-installing, but that solves it only for a temporary period of time. On my laptop it works fine, but doesn't on my desktop. Edit: now I just tried it again and it works. It's like sometimes the winget source is down or something, but that's odd, cause I don't have this issue on my laptop. |
|
Here's an issue showing that winget apparently is having all kinds of problems right now. |
|
winget CDN should be fine now. |
|
This might be two non-overlapping errors.
|
|
I'm experiencing the same issue right now. I can't even download source.msix manually. I've been trying to update my software for a week now. |
|
I'm also experiencing this issue. Update: Updating from 1.3 to 1.4 seems to have resolved the issue for me. |
|
My way of ending up with this issue was by having new apps installed into a new disk on D:, then the disk fried, and I had it removed and, after that, winget didn't work anymore. |
Brief description of your issue
Unable to install a package:
Logs:
Steps to reproduce
Try to install a package.
Expected behavior
Package gets installed
Actual behavior
Error.
Environment
> winget --info Windows Package Manager v1.2.10271 Windows: Windows.Desktop v10.0.22000.613 Package: Microsoft.DesktopAppInstaller v1.17.10271.0The text was updated successfully, but these errors were encountered: