After updating Windows 10, Windows can no longer manage any appx packages, and I can't deploy WinUI 3 apps from VS

[kmgallahan]

I just updated Visual Studio to 17.13.0 Preview 1 and Windows to 19045.5131.

Now Visual Studio can no longer deploy WinUI 3 apps, I can't uninstall any apps, the Microsoft Store can't update any apps, and trying a different account also results in the Store malfunctioning.

It seems Windows has lost its ability to manage packages.

@DrusTheAxe From what I've seen you are an expert in this area. Any suggestions for how to approach this?

VS error is:

DEP0900: Failed to unregister application "myappid". [0x80073CFA] 

[Xo3-ToBapbl]

Can confirm. All our devs with win10 22H2 19045.5131, 19045.5011 machines faced with this issue. No problems for devs with win11 23H2 and above.

Just quick note, I think Visual Studio update is not the reason of this issue. We faced it on VS 17.9.7.

Related .NET MAUI topic:
dotnet/maui#25832

[sigroli]

We experienced the same issue and identified Windows update KB5046613 as the cause.

[riesem]

Uninstalling KB5046613 does not help

[kmgallahan]

Every time.

"I think I'll update some packages. I may as well update VS while I'm at it. Oh, it suggests a restart. Ah, Windows wants to update during the restart."

~

"I wonder how much time & money this is going to cost me."

---

Only "solution" I've found is a clean install, which isn't a solution at all. Maybe now that millions are impacted Microsoft will throw together some sort of fix...

[S4nt1ag0]

Same problem here, how you "clean install" ? i am noobie in C# development. Do you click "Clean Solution" and Rebuild ?

[ivanjx]

@S4nt1ag0 clean install the whole OS. while im at it, im installing win11. it seems that win10 is really dying already.

[axa88]

#MeToo right after Windows update.

[dillonricketts]

I had this issue with .NET 8 and Windows 10 22H2 19060.1000.0. Upgrading to Windows 11 was unfortunately the only thing that worked.

[robertbrestle]

I'm currently having this issue on Win10 22H2 builds 19045.5011 and 19045.5131. We started noticing this issue on 11/12.

[subratb]

Please look at this. The discussion started here and lead up to the stated temporary solution.

[kmgallahan]

@subratb That looks like a different issue, and it is a month old. This one is brand new this week.

[StevoSM]

Experiencing the same here. Pretty much dead in the water until a fix is released. All development has been blocked.

[kmgallahan]

@StevoSM You can just stick this in your csproj files to make them unpackaged until a fix is available - unless they require something only packages support.

        <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
        <WindowsPackageType>None</WindowsPackageType>

[johnt-star]

I am now having same issue.

I added the above lines to my project file, first in an existing property group, now in their own as follows:

Restarted Visual Studio, did a Clean and Rebuild Solution, but still get

even though deploy option is set

[kmgallahan]

@johnt-star You need to change your configuration selection to Unpackaged.

[johnt-star]

Thanks kmgallahan!

I no longer get the deployment error dialog after changing to Unpackaged.

Unfortunately after upgrading Visual Studio to the latest version, updating nuget packages where appropriate and installing .Net 9, I am now getting exceptions for things that use to work.

At least I can see what has changed and hopefully resolve them in order to get my app running again.

Appreciate the help!

[kmgallahan]

One thing I had to do was add this to resolve some ref issues:

<OutputPath>$(SolutionDir)bin\$(Configuration)\</OutputPath>

[codendone]

There was an issue in the WinAppSDK 1.6.2 release which affected Windows 10 version 19045 machines. The 1.6.2 release has been pulled to prevent more machines being impacted.

This issue was not caused by an update to Windows and will not be fixed by uninstalling any Windows Cumulative Updates.

There is an upcoming Windows Update which will fix this issue (adding extra safety in Windows), and a release of WinAppSDK 1.6.3 is coming soon with a fix.

Machines in a bad state can also be manually fixed by running these steps:

1. Launch a PowerShell or Command Prompt as Administrator and run these commands:

takeown /F "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x64__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll"
icacls "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x64__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll" /grant Administrators:F
del "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x64__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll"
takeown /F "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x86__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll"
icacls "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x86__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll" /grant Administrators:F
del "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x86__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll"

2. Reboot
3. Launch a PowerShell as Administrator and run these commands:

Get-AppxPackage *WinAppRuntime.Main.1.6* -AllUsers | Where { $_.Version -eq '6000.311.13.0' } | Remove-AppxPackage -AllUsers
Get-AppxPackage *MicrosoftCorporationII.WinAppRuntime.Singleton* -AllUsers | Where { $_.Version -eq '6000.311.13.0' } | Remove-AppxPackage -AllUsers
Get-AppxPackage *Microsoft.WinAppRuntime.DDLM* -AllUsers | Where { $_.Version -eq '6000.311.13.0' } | Remove-AppxPackage -AllUsers
Get-Appxpackage *WindowsAppRuntime.1.6* -AllUsers | Where { $_.Version -eq '6000.311.13.0' } | Remove-AppxPackage -AllUsers
Investigations are continuing and we'll provide further updates when available.

If you have an app project referencing the Microsoft.WindowsAppSDK package version 1.6.241106002, update the project to instead reference version 1.6.240923002. Removing version 1.6.241106002 from your local NuGet cache (such as C:\Users\<username>\.nuget\packages\microsoft.windowsappsdk\1.6.241106002) is also recommended to avoid accidental usage.

Investigations are continuing and we'll provide further updates when available.

[StevoSM]

@codendone Thanks for the update. I don't know how helpful this might be, but we are only on WinAppSDK 1.4 and are experiencing the issue. We have not yet updated to 1.6 at all. In our environment, it must be the result of a Windows update or possibly that combined with a Visual Studio 2022 update.
Note also we cannot run Slack as it is in a state of needing to be updated by the Windows Store app, and the Windows Store app is not able to successfully complete app updates due to this same issue.

[codendone]

@StevoSM There must be a different app on the system which is using 1.6. Running Get-Appxpackage *WindowsAppRuntime.1.6* -AllUsers in an administrative PowerShell can help see those.

[StevoSM]

@codendone Apparently so. Your command revealed 3 results, 2 of which matched the problematic version. I went through your suggestion above and, well, it worked and we're back in business! Thanks so much for your hard work on this and posting those steps!

[Balkoth]

@codendone
Your commands only work on an english OS. Once i got the first block working by replacing "Administrators" with the localized version i am stuck on step 3:

PS C:\WINDOWS\system32> Get-Appxpackage *WindowsAppRuntime.1.6* -AllUsers | Where { $_.Version -eq '6000.311.13.0' } | Remove-AppxPackage -AllUsers
Remove-AppxPackage : Der Remoteprozeduraufruf ist fehlgeschlagen.
Der Remoteprozeduraufruf ist fehlgeschlagen.
In Zeile:1 Zeichen:96
+ ... ere { $_.Version -eq '6000.311.13.0' } | Remove-AppxPackage -AllUsers
+                                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Remove-AppxPackage], COMException
    + FullyQualifiedErrorId : System.Runtime.InteropServices.COMException,Microsoft.Windows.Appx.PackageManager.Commands.RemoveAppxPackageCommand

What now?

[kimpel70]

@codendone Your commands only work on an english OS. Once i got the first block working by replacing "Administrators" with the localized version i am stuck on step 3:

PS C:\WINDOWS\system32> Get-Appxpackage *WindowsAppRuntime.1.6* -AllUsers | Where { $_.Version -eq '6000.311.13.0' } | Remove-AppxPackage -AllUsers
Remove-AppxPackage : Der Remoteprozeduraufruf ist fehlgeschlagen.
Der Remoteprozeduraufruf ist fehlgeschlagen.
In Zeile:1 Zeichen:96
+ ... ere { $_.Version -eq '6000.311.13.0' } | Remove-AppxPackage -AllUsers
+                                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Remove-AppxPackage], COMException
    + FullyQualifiedErrorId : System.Runtime.InteropServices.COMException,Microsoft.Windows.Appx.PackageManager.Commands.RemoveAppxPackageCommand

What now?

@Balkoth ,
i'm also running into this problem, and thanks for the tip regarding 'Adminstratoren'. The solution to your problem is, to copy each line individually and run them through powershell, not the whole block at once.

[kimpel70]

@codendone,
FYI, it is still possible to download the SDK 1.6.2 manually: https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/downloads.
I got to this place, getting the following message (containing the link) while trying to deploy a MauiApp in Visual Studio 2022 for debugging.

DEP0840: Project 'MauiApp.Maui' requires packages 'MicrosoftCorporationII.WinAppRuntime.Main.1.5_8wekyb3d8bbwe' and 
'MicrosoftCorporationII.WinAppRuntime.Singleton_8wekyb3d8bbwe' with version >= '5001.178.1908.0'.
 These packages should be installed on first run, if not please visit http://go.microsoft.com/fwlink/?linkid=2222757 
for installation instructions.

[nidietr-MSFT]

@codendone Your commands only work on an english OS. Once i got the first block working by replacing "Administrators" with the localized version i am stuck on step 3:

PS C:\WINDOWS\system32> Get-Appxpackage *WindowsAppRuntime.1.6* -AllUsers | Where { $_.Version -eq '6000.311.13.0' } | Remove-AppxPackage -AllUsers
Remove-AppxPackage : Der Remoteprozeduraufruf ist fehlgeschlagen.
Der Remoteprozeduraufruf ist fehlgeschlagen.
In Zeile:1 Zeichen:96
+ ... ere { $_.Version -eq '6000.311.13.0' } | Remove-AppxPackage -AllUsers
+                                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Remove-AppxPackage], COMException
    + FullyQualifiedErrorId : System.Runtime.InteropServices.COMException,Microsoft.Windows.Appx.PackageManager.Commands.RemoveAppxPackageCommand

What now?

@Balkoth, this "Remote Procedure Call Failed" error comes from another issue causing AppxSvc crashes during package removal, which was fixed starting the optional update end of October (https://learn.microsoft.com/en-us/windows/release-health/resolved-issues-windows-10-22h2#3421msgdesc). Best would be to deploy the cumulative update from November 2024 (https://support.microsoft.com/en-us/topic/november-12-2024-kb5046613-os-builds-19044-5131-and-19045-5131-44e6c27e-e188-4dd5-8ad2-edde2e235c01).

[clarjon1]

When attempting to run the second group of commands, each one would error out in the style of

Get-AppxPackage: The 'Get-AppxPackage' command was found in the module 'Appx', but the module could not be loaded due to the following error: [Operation is not supported on this platform. (0x80131539)]
For more information, run 'Import-Module Appx'.

After doing some digging, I found this command to force the loading of the module in powershell form

 Import-Module Appx -UseWinPS

Which allowed the commands to run happily.

[paul-d-ray]

Thank you.

Winget stopped working today after working yesterday.
I came across this when searching for the error code.

I did step one and Winget now works.

[dkuenne]

Machines in a bad state can also be manually fixed by running these steps:

1. Launch a PowerShell or Command Prompt as Administrator and run these commands:

takeown /F "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x64__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll"
icacls "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x64__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll" /grant Administrators:F
del "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x64__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll"
takeown /F "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x86__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll"
icacls "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x86__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll" /grant Administrators:F
del "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x86__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll"

For non-english localized systems the SID can be used:

takeown /F "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x64__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll"
icacls "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x64__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll" /grant "$((Get-LocalGroup -SID S-1-5-32-544).Name):F"
del "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x64__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll"
takeown /F "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x86__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll"
icacls "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x86__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll" /grant "$((Get-LocalGroup -SID S-1-5-32-544).Name):F"
del "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x86__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll"

[DeRuiterIndustrieleAutomatisering]

After I ran'Import-Module Appx --UseWindowsPowerShell I could execute most part of the second set of the solution. I was unable to uninstall my WSL2 distribution and that's working again

[DominicMaas]

snip

It doesn't work for self-contained WASDK apps.

Has anyone had experience with this workaround for self-contained WASDK (not self-contained .net) apps? I've got a few end users with this issue. Will get them to run the work-around, but not sure if it'll fix anything in my case.

[codendone]

A simpler solution to fix a machine in a bad state is to run the WinAppSDK 1.6.3 installer multiple times. The installer is available at Latest downloads for the Windows App SDK - Windows apps | Microsoft Learn, with this as right installer for most machines:

• Installer (x64)

Run that installer, which will fail the first time it is run. Run it again which usually succeeds. If necessary, run it again until it succeeds.

We're continuing work on a better fix for broken machines and will provide an update when available.

[GeoSaffer]

Thank you SOOOOOO much @codendone , this work great !!!!!

[developertest02]

Thank you. This was the only thing that worked.

[King-Taz]

Does not work for me using Windows 11. Deploy box still grayed out in VS. Tried to install multiple times, got this return.

Installing license: MSIX_MAINPACKAGE_LICENSE
Install License result : 0x0
Installing license: MSIX_SINGLETONPACKAGE_LICENSE
Install License result : 0x0
All install operations successful.

[ClausAndersen]

del "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.311.13.0_x64__8wekyb3d8bbwe\WindowsAppRuntime.DeploymentExtensions.OneCore.dll"

I had problems deleting this file. It turned about to be because it was in use. That was fixed by stopping the service first:

sc stop AppXSVC

[ClausAndersen]

I can confirm the 1.6.3 does remove the 0x80073CFA error. It does however cause related issues. I cannot re-install Windows Terminal or winget as I am told I already have a newer version. I suspect that these are built as self contained bundles and the bundles then need to be updated with a later version of the SDK. But I cannot confirm this.

See microsoft/winget-cli/issues/4991 and microsoft/terminal/issues/18237.

So this seems to be related fallout. It would be nice if we could get confirmation if it would help these issues if they create new builds using the 1.6.3 SDK redistributable?

[michal1fraczek]

You’ve saved us (admins) so much time, stress, and nerves! @codendone
It’s clear that you’ve rescued more than one company.

Out of two official tickets I raised with MS, only one was resolved, and that with a laughable, useless solution. If we had to rely on them, I don’t even want to think about the chaos we’d be dealing with in the company right now.

From the information I’m receiving (as of today, 22.11.2024, 10:00 UTC+1), yet another company in our country is struggling with the same issue.

How is it even possible that MS leaves companies to deal with this on their own?

We spent countless man-days working on a solution, since last week ! First problems occurs 13.11.2024

Once again, thank you @codendone for this fix (you should get at least $100k from MS for it! 😊).

[ClausAndersen]

So this seems to be related fallout. It would be nice if we could get confirmation if it would help these issues if they create new builds using the 1.6.3 SDK redistributable?

This is actually an easy RTFM fix.

Both issues have been resolved (for me) using Add-AppxPackage with -ForceUpdateFromAnyVersion. They are tangentially related to this issue as they have been affected by the SDK issue.

[kumaresan-cgvak]

Microsoft released a patch OS update for Windows 10 with the fix for the install / uninstall issue.

Users might be unable to update or uninstall packaged apps on Windows 10

Updating the OS to the Below optional update will allow the user to uninstall in case if the corrupted version of the app is there. in certain cases, it automatically removes the corrupted app. allowing us to do a fresh install of the app again.

[codendone]

This discussion post is now available with the summary of the situation and recommended resolutions: #4913. Any further updates will be posted there.

[codendone]

Closing this issue as fixed/mitigated.