Jun 15 2020 09:34 PM - edited Jun 16 2020 08:08 AM
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:
Microsoft-Windows-AppXDeploymentServer/Operational
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?
Edit:
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.
Sep 10 2020 07:39 AM
Sep 10 2020 11:18 AM - edited Sep 10 2020 11:19 AM
@gug_82
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.
Sep 17 2020 04:46 AM - edited Sep 17 2020 04:47 AM
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).
Sep 17 2020 08:03 PM
Sep 17 2020 11:57 PM
Oct 14 2020 11:35 AM
@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.
https://techcommunity.microsoft.com/t5/msix-deployment/error-0xc00cee23-when-minor-version-gt-10/td-...
Oct 20 2020 08:56 AM
Nov 09 2020 01:53 AM
Hi,
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.
Jan 14 2021 10:02 PM
@annaojdowska Hi, I have the same problem. Hopefully MS will fix it sometimes in this decade.
Feb 25 2021 12:55 AM
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.
Mar 11 2021 03:13 AM
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
Mar 11 2021 07:02 AM - edited Mar 11 2021 07:03 AM
@GToison
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.
Mar 11 2021 07:47 AM
Mar 11 2021 07:56 AM
Mar 11 2021 08:22 AM
Jun 01 2021 03:27 AM
Hi,
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?
Jun 01 2021 06:21 AM
Jun 01 2021 07:08 AM
Jun 01 2021 07:37 AM
Jun 02 2021 03:21 AM - edited Jun 02 2021 03:39 AM
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.