Microsoft Technical Takeoff: Windows and Microsoft Intune
Oct 24 2022 07:00 AM - Oct 27 2022 12:00 PM (PDT)

Windows 10 2004 - MSIX Not Updating -Please check whether the Msixvc support services are installed.


We use MSIX for one of our LOB applications at my organization. We recently updated some machines to Windows 10 2004 to test it before rolling it out to the rest of the company. One problem we have noticed is that repeatedly that if we update an MSIX package on these systems and then issue a second update, the second update always fails. The event viewer logs multiple errors, most just being generic "the msix package failed to install", etc. However, there is one peculiar one. We found it under:


Event Id 497

Error 0x80070002: Opening the Msixvc package from location AppName_x64.msixbundle failed. Please check whether the Msixvc support services are installed.

In addition, this is logged under AppXDeployment - Operational:


Event ID: 302
Failed to start system service: appxsvc with error: 0x8007045B

We could not find any documentation on this error anywhere on MSDN.

To work around this, we have to restart the machine. Afterwards it is able to update the MSIX package.

Is this a known issue with Windows 10 2004?

Can anyone here provide more information or can they provide any suggestions on how to stop this from happening?


We also had a user go ahead and update their machine to Windows 10 2004 without notifying us and now they are getting the same problem as well.

Edit #2:

I also left this in the feedback hub in Windows 10; if there are any additional channels that I should use, please let me know.

48 Replies
Hey man! I spent one day to find out why it happens on some PCs only with Windows 10, v2004. at the end of day I found your comment, and **bleep**! restarting pc helps!! Thank you!


I'm glad to hear it helped.

I submitted a bug for this also in Microsoft Collaborate, but it doesn't look like any significant changes have been made yet though. Also, I had a one on one with someone at Microsoft about this and a few other things a couple of weeks back and they said that this problem will only get resolved with an OS update. I had a feeling that was the case.

Also, if you have the option of keeping your users from updating to 2004, that is what they encouraged. But if not, restarting is really the only work around right now.


Somehting similar is happening here, 2004 as well. I'm getting AppInstaller failures with Unknown error (0x80d05011). It is related to msixbudles as I can easily get appinstaller back into a working condition switching back to non-bundle packaging. It is the same with either flat bundles or regular ones.


The issue doesn't occur if I install the msixbundle directly without .appInstaller.


Also I found the default App.packagelayout template from Visual Studio to have missing configuration name in the end of FileName attribute. This means thegenerated misxbundle file will have no "_Debug" or "_Release" strings in the end of filenames. However, looking inside the generated .appinstaller file msixbundle URL, I see configuration names are there, and so the .appinstaller will fail to lookup for the bundle. Of course the above mentioned error doesn't solve even patching this trivial filename mismatch, and also exists when no App.packagelayout file is provided (and so filename matches correctly).


Can you provide any additional information on how you managed to switch to a non-bundle package? I think we tried that, and we still had the error when trying to perform a subsequent update with the app installer.
I simply removed the App. package layout file and selected Never for "Create bundle?" in app package creation wizard. Mine is a simple application and doesn't really needed a bundled layout. Different packages for each cpu architecture will be created.

@Sharla_Akers @StephenWhiteD3G  @davidanthoff  @marcinotorowski  I am also getting the 0xC00CEE23 errors. I see those when my Minor version number is >= 10. If I decrease the version to 9 things work perfectly. For whatever reason, App Installer may not like version numbers greater than 9.

we have the same problem. On Windows 10 2004 MSIX updates fail with errors same as mentioned in the previous comments.

This issue is critical for us because we use MSIX and .appinstaller files in production and more and more our users are switching from Windows 10 1909 to 2004. 

@annaojdowska Hi, I have the same problem. Hopefully MS will fix it sometimes in this decade.

We had the same problem (with 20H2), our application's .msix was hosted on a webserver through the http (not https) protocol.

After switching to https it worked so I suspect that the Application Installer Service is using https to talk to the server, even if the url is http:// . Since the protocol is incorrect it can't download the .msix file and reports that it is corrupted.

After further testing the https switch was a red herring and the .appinstaller still fails to pick up the updated .msix.

However we have found that stopping (or restarting) the "Delivery Optimization" (DoSvc) service mitigates the problem because then we can update.


So essentially we need to kill the service on all computer before updating the msix, otherwise the update will fail.


@annaojdowska This is not a great solution and it would be good to get some feedback from Microsoft on this issue


I have been told by one of the people on the app consult team that this problem should have been fixed in Windows 10 20H2, but judging from your previous comment, this is not the case. That is a shame.

It's also shame that this happened since MS put a lot of effort into promoting MSIX. We really did want to use it but after this problem, we ended up going back to MSI and creating our own app updater and we haven't had any problems. It also sped up our pipelines and all our users now prefer our in-house updater versus the app installer. 

AppInstaller + MSIX worked great for us on Windows 10 1909 but broke after upgrading to 20H2.

What's particularly frustrating is the error reporting: these error codes and messages are not very helpful. For instance we tried adding the version number to the URL of the .msix but then appinstaller complained that the XML was invalid (error 0xC00CEE23).

We also had some users reporting that error when trying to update our application:

App installation failed with error message: Windows cannot perform the RegisterByPackageFamilyName operation because it could not find Microsoft.Office.C2RX_8wekyb3d8bbwe in the repository. Make sure Microsoft.Office.C2RX_8wekyb3d8bbwe has been staged or was installed by another user. (0x80070002)

Our application does not have any dependency with Office...

As you said MS put a lot of effort into it, but right now appinstaller is broken for us and these error messages are not helping
That sounds like what we had; it was fine for the most part on 1909, but after that it became too unreliable and a poor user experience, so we had no choice but to abandon it (roll backs / re-imaging were out of the question).

Out of curiosity, did you try the work around that @LuKePicci posted up above? I didn't have a chance to try it myself since we had moved on from MSIX by the time he posted it, but it sounded promising (if you don't need to make the package an app bundle).
Our appinstaller file only has a <MainPackage> and the .msix is built with makeappx (and then signed with signtool). The .msix installs correctly.
It is actually a Java application so we don't build in Visual Studio.


It's nearly a year later than the original post on this and I am now having this issue. Has there been a fix for it or not?

We still have the issue, we also tried upgrading to Windows 10 21H1 but that did not help.
The only workaround we have found was to kill the "delivery optimisation" service (or rebooting the computer)
That seems unbelievable if it is as basic a problem as it seems. I assume very few people must be using MSIX to deploy their applications so MS have abandoned the technology.
@JulesB @GToison

Agreed, I feel like this problem and the slow pace to get it resolved has made it seem like MSIX is no longer a priority. There also still seems to be a lot of friction regarding transitioning from MSI to MSIX for various devs/studios/publishers/etc, so you are right that the adoption has been anemic. This is really a separate topic though... but in the context of this problem, it isn't encouraging.

As far as what I have found out - the ticket I have with Microsoft for this bug in the Partner Center got closed as "resolved". Based on the ticket close notes, there was a code fix applied on 4/13/2021 that "works around" this problem but it only seems to work if the URI's used by the app bundle are different from the previous version. Beyond that, they said that they are working on a full-term solution with the "DO Team" (not sure who that is).

At this point I am thinking that we will not see the app installer fix until 21H2. Also I am not sure if the code fix containing the work around is even available in 21H1 since 21H1 seemed to have been finalized months ahead of time due to its disappointing number of new additions versus what is available in the current dev branch / release preview of Windows 10.

I suspect that the DO in "DO team" is the delivery optimisation.
At least in our case the .msix file is fine: if we download it separately we can install it without any problem.
The issue seems to be in the system that downloads that file.