Open fidothe opened 9 months ago
Logs related to the failure of the initial Windows 11 winget
:
WinGet-2023-12-12-17-23-51.554.log WPM-2023-12-12-14-19-12.715.log WPM-2023-12-12-17-20-29.341.log
Output from Add-AppxPackage
:
PS C:\Users\matt> Add-AppxPackage https://github.com/microsoft/winget-cli/releases/latest/download/Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle
Add-AppxPackage : Deployment failed with HRESULT: 0x80073D02, The package could not be installed because resources it
modifies are currently in use.
error 0x80073D02: Unable to install because the following apps need to be closed
Microsoft.DesktopAppInstaller_1.17.10691.0_arm64__8wekyb3d8bbwe.
NOTE: For additional information, look for [ActivityId] fd8de5a3-2cfe-0000-8146-90fdfe2cda01 in the Event Log or use
the command line Get-AppPackageLog -ActivityID fd8de5a3-2cfe-0000-8146-90fdfe2cda01
At line:1 char:1
+ Add-AppxPackage https://github.com/microsoft/winget-cli/releases/late ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (https://github....bbwe.msixbundle:String) [Add-AppxPackage], Exception
+ FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand
If I install VisualStudio Community 2022 through the Store app, after installation is complete the command line winget
then functions correctly, so presumably the updated packages are installed in a different order or manner. Unfortunately, what I wanted to use winget
for was to install VS 2022 and other project dependencies from a configuration .yaml
...
Based on what I see here, I expect WinGet is failing to update the source due to its inability to connect to the CDN:
The Add-AppxPackage seems to fail because it's waiting for the source update to complete.
If the first action taken on the OS is to update "App Installer" via the Microsoft Store, or to install WinGet from the GitHub releases, I would expect that to work.
We're still working on a few of these "chicken and egg" scenarios to get WinGet updated as part of the OS bootstrapping process without the expected ~15-minute delay after first login.
Based on what I see here, I expect WinGet is failing to update the source due to its inability to connect to the CDN:
That's what I thought - but I thought you might want the logs, too.
The Add-AppxPackage seems to fail because it's waiting for the source update to complete.
If the first action taken on the OS is to update "App Installer" via the Microsoft Store, or to install WinGet from the GitHub releases, I would expect that to work.
I just reset my VM back to a snapshot from the earliest point after setup has finished and Windows been activated, and running Add-AppxPackage
did not work then either.
We're still working on a few of these "chicken and egg" scenarios to get WinGet updated as part of the OS bootstrapping process without the expected ~15-minute delay after first login.
Interestingly, looking at the logs I can see that when I attempted to install the .msixbundle
after the reset, I had not run any winget
commands at all, but Windows Package Manager had attempted to update itself (I presume the 15 minutes having expired). There was a Windows Package Manager Service process running that I hadn't started manually. Once I killed that, running the Add-AppxPackage
completed fine. Is it possible that the attempt to update itself is suffering from the CDN problem, but leaving a hanging process that, in turn, prevents manual installation of the updated package?
I presume that the act of installing VS Community from the MS Store forces that hung self-updating WPM process to die, because it (VS) wants to update it too.
I had this exact same issue on a new install of W11. Only thing that worked was ending the Windows Package Manager Service process that was still running for some reason.
Has anyone found a work around? Hitting this same issue but do not have any Windows Package Manager Service process running
Brief description of your issue
I am unable to update sources, install packages, or even install the most recent
winget
release.msixbundle
on a fresh install of Windows 11 Pro Arm 64 running on a VM on an M1 Mac under Parallels. This seems to be closely related to (or a duplicate of) a number of other issues, but I thought I would open this because of the Arm 64 issue, and because I have logs to attach.Steps to reproduce
winget source update
Add-AppxPackage https://github.com/microsoft/winget-cli/releases/latest/download/Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle
Expected behavior
For either the initial winget command to succeed or fail with an error message, and for the installation of the
.msixbundle
to succeed.Actual behavior
winget source update
fails weirdly, with no output but a stopped spinner and the following PS prompt coloured blue, the same as the spinner.Add-AppxPackage ...
fails with an error about resources being in use:Environment