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

Iron Contributor



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.

48 Replies

Hi @StephenWhiteD3G,

 

Could you please send us the link to your Feedback Hub item so we can take a closer look?

 

What kind of LOB application do you have? I notice the error contains 'MSIXVC' and MSIXVC is an extension of MSIX that is specifically designed for games that are published through PC GamePass; it is not used for non-game scenarios.

 

Best,

Sharla





Hi Sharla,

The LOB app is a WPF application using the Desktop Bridge targeting .NET Core 3.X.

Here is the feedback hub link:

https://aka.ms/AA8r372


I also noticed today that the App Installer project did not have itself set to target 2004. I am going to make this adjustment and let you know if this changes anything tonight when we run our next update for production.

Edit / Update: Unfortunately adjusting the App Installer to target 2004 did not make any changes. Also we found that if the user tries to go to the web page generated by the app installer project and clicks get the app, they get an error saying that it cannot open the MSIX Bundle. Either they have to restart their machine or they have to download the MSIX Bundle manually and run it.

@Sharla

One other addendum:

If we try to run the app installer on a computer that is on the fast ring, it gets a different, albeit misleading error:

0x8008020C. The specific error text for this failure is: error 0xC00CEE23: The XML in the .appinstaller file is not valid: Line 18, Column 13, Reason: '>' expected.


The same error shows up in the Microsoft-Windows-AppXDeploymentServer/Operational log.

However if I open up the app installer file and inspect it, it doesn't have any obvious signs of having any invalid XML, and again, it runs fine if I restart the machine or download the MSIX Bundle and run that directly.

It's almost like there's some other app installer file getting stuck somewhere and its running that instead of the one that I intend to run...?

I'm surprised I am the only one who has reported this; if you need any additional details, please let me know, this has us baffled. I think we can use a work around but I need to check a couple of different things. The obvious work around right now is to have the user restart their machine before updating, but obviously that gets old fast.

hi @StephenWhiteD3G,

 

Can you file feedback from impacted machines and the specific apps that fail to install? The feedback you filed previously doesn't have the logs we need to investigate further.

 

Best, 

Sharla 

Hi Sharla,

I thought I did, but I'll do my best to get a repro going on one of them ASAP. Thanks for letting me know they were missing.



Hi again Sharla,

I submitted another report using my organization account instead of personal account from a machine that is affected (my work PC actually). Please let me know if the diagnostics and the recording uploaded.

Here is the new feedback hub link:

https://aka.ms/AA8qzzo

Thanks again for your help, I hope we can get to the bottom of this soon.


P.S. As an experiment, I am going to remove the AutomatedBackgroundTask element in the app installer file on the next update for the org and see if that changes anything. I have a hypothesis that may be the cause of the problem, as I found earlier today that if I deployed an update locally and then quickly opened the app from the start menu, it was able to see and install the update without any problems and I was also able to uninstall and reinstall the app multiple times in a row without any errors. 

Hi Sharla,

I just wanted to follow up and see if you were able to see anything or if you had a chance to look at this again yet. If you haven't, I understand. The users have been given guidance to use the bundle file until we can find a better solution regarding this, but its still a huge problem. :( 

As far as other things we have tried, I adjusted our CI/CD pipeline in Azure to apply version numbers to the .wapproj file that has a zero for the last number, but that didn't result in any changes. I was hoping it would help since the YAML we were using was adding version numbers that had a number in the last digit (one of the examples we found on MSDN showed that it was supposedly safe to do this, but the MSIX documentation says it must stay as Zero and we recalled that Visual Studio doesn't allow you to change it when creating the app installer via the wizard).

We also tried turning off the "Automatic Background Task" setting in the app installer, but that hasn't seemed to make any difference either.

I'm currently trying to see if Process Monitor or Process Explorer can provide any more details as to what may be not responding correctly in Windows when these errors occur, but unfortunately I haven't had any success yet.

Again, please let me know if you or anyone on your team have any updates. 

Small update, but unfortunately still no other work arounds found on our end besides having the user download and run the full MSIXBundle.

We have a test environment for the the LOB app that uses MSIX / App Installer as well. For some reason, this one appears to not have the errors occur when it is run and then updates are provisioned and applied subsequently. However, the biggest difference between the test and live environments is that the test environment uses a local file share on the company file server for hosting the files for the app installer and MSIX bundle.

The live environment uses an Azure Blob storage (which you probably saw from the feedback hub video; hopefully you were able to get that). The live is due to the fact we use Azure DevOps and Pipelines and we found it to be the best way to automate delivery and deployment.

Hopefully someone on your end may be able to see more than me; but my guess is the problem may be due to the way App Installer or some component of MSIX in Windows 10 2004 is handling the URIs of UNC paths versus HTTPS? Again, this is just a stab in the dark.


Sharla,

Edit #2: Well, the idea I had earlier about HTTP turned out to be incorrect. The app installer errors out on subsequent package updates when using either HTTP or HTTPS endpoints.

One thing I noticed is that this cryptic error gets logged in the event viewer whenever the problem occurs, I am not sure if this indicates there is a bug in the App Installer process itself, but it is making me wonder:

Suspending
Error: Unknown HResult Error code: 0xefffffff
Function: Windows::ApplicationModel::Store::Preview::InstallControl::AppInstallManagerImpl::OnSuspend
Source: onecoreuap\enduser\winstore\installservice\lib\appinstallcontrol.cpp (476)

Skipping license manager: PFN Microsoft.DesktopAppInstaller_1.0.41331.0_x64__8wekyb3d8bbwe
Function: InvokeLicenseManagerRequired
Source: onecoreuap\enduser\winstore\licensemanager\apisethost\activationapis.cpp (373)

 

Note: I can also see these errors in the output if I try to debug App Installer using VS when the error occurs. For what it is worth, I also tried restarting all of the services that App Installer is calling (Windows Store Install Service, Game Service, Client Licensing and App X Service, but unfortunately that doesn't seem to clear the state for it.)



Sharla,

This is probably going to be my last response to this since I am not sure what else you need and I have not heard any response from you. 

Anyways, from my findings:

- On the users PCs that are running Windows 2004, they do NOT have the Microsoft.GamingServices package installed, which is what I presume is causing the MSIXC Support Service error message.  I can see that when I run the app installer using the debugger in VS or NirSoft's debug tool, it shows that app installer is interacting with that service for some reason.

 

- The users PCs that are running Windows 2004, they get the error at some point regardless as to whether or not they are installing using .appinstaller or plain .msix. Sometimes the users get it even right after starting their PC.

 

- On the fast ring PC, which has the Gaming Service installed, it gets a different error on subsequent installs or updates, saying that the XML is invalid for the app installer file, even saying its bad at line 1 column 0, which doesn't make any sense. I haven't been able to get any errors directly installing from an .msix file though on the fast ring PC.

 

- The problem ONLY seems to occur when trying to install the .msix or .appinstaller files using HTTP/HTTPS. UNC / Local file paths seem to work fine.



At this point we probably are going to try waiting another week and a half, but if we do not get any more indication or see anything change soon, we probably will have to take the software off the Desktop Bridge. We cannot role all 145+ PCs back to 1903 at this point. 

I have to admit, I am disappointed that I haven't received any responses since you asked me to submit information through the app center. A simple "we are looking at it" would have sufficed. I am sure you understand my frustration though and please do not take this as an insult; I greatly appreciate everything you do at MS. Needless to say, I am surprised other people haven't stumbled upon this problem yet, which makes me almost wonder if we're the only ones using .msix / .appinstaller in production. :( 

Thanks, and hopefully this will get resolved before we have to make the decision to leave the Desktop Bridge. 

Hi @StephenWhiteD3G 

 

Apologies for the delay here. We've passed on your Feedback Hub submission and logs to the Dev team for further investigation. We'll let you know as soon as we get more details on the issue and any potential ways to address it.

 

Cheers,

Tanaka

Hello again @Tanaka_Jimha!

Thanks for the update, I really appreciate it. And again, please don't interpret my last response as being upset with Sharla, after all she helped get the ball rolling on this. :) 

I'll let the people on my end know that the issue is being looked into and will let them know we should hold off on making any chances to our CI/CD or deployment until I hear back. 

Thanks again!

Quick update on this one, although I am not sure if it really helps or not -

 



On build 20161 it now shows a different exception in the app installer when it has the issue occur:

Common::Deployment::MsixvcStagingSession::GetManifestReader in MsixvcStagingSession failed with error 0x80070570.

 



The AppXDeployment-Server Event Viewer Log also has this exception:

Appinstaller operation failed with error code 0x80070570. Detail: The file or directory is corrupted and unreadable.

 

 

 

And the Microsoft-Windows-Store Event Viewer log has theses exceptions:

 

XvcDataSource_GetManifestStream [XBL:]\https://myAzureBlobContainer.z13.web.core.windows.net/MSIX_Test/MyApp_X64.msixbundle
Function: XvcUtilities::GetUserDataStreamFromXvc
Source: (1008)

 

XvcDataSource_GetManifestStream [XBL:]\https://myAzureBlobContainer.z13.web.core.windows.net/MSIX_Test/MyApp_X64.msixbundle
Function: XvcUtilities::RetryOnFailure
Source: (69)


XvcDataSource_GetManifestStream [XBL:]\https://myAzureBlobContainer.z13.web.core.windows.net/MSIX_Test/MyApp_X64.msixbundle
Error: The file or directory is corrupted and unreadable.
Function: XvcDataSource::GetManifestStream
Source: (106)

I'm also getting these kinds of errors. Specifically:

 

App installation failed with error message: error 0xC00CEE23: The XML in the .appinstaller file is not valid: Line 26, Column 7, Reason: '>' expected. (0xc00cee23)

 

I get this error an a system where I had a previous version of the appinstaller installed (but now uninstalled in the meantime). If I try exactly the same link on a fresh new system in a VM, it all works.

@davidanthoff 

App installation failed with error message: error 0xC00CEE23: The XML in the .appinstaller file is not valid: Line 26, Column 7, Reason: '>' expected. (0xc00cee23)

 

I have seen this error a few times, though not regularly nor attached to any reproducible condition I could imagine of. In my case it had nothing to do with the hosting server, the XML file of .appinstaller definition nor the application itself, which were always OK (correct downloads, MIME types, validated XML, working manual installation etc.). 

 

For me, sadly the "simplest" workaround always did the trick - the problem was gone after rebooting the machine, no other changes done. I would say this could have been a caching issue, if not for the fact that some deliberate changes on the live .appinstaller content were reflected by the messages of the appinstaller window (changing line numbers). Anyway, I am curious to see if this behaves like this on your machine(s) - if the reboot works then there are at least two of us with exactly the same issue :)

That's pretty much what has been happening on my end. Seems to start happening as soon as you install an update with app installer. Like you said, after that it is like something gets cached and/or not properly cleaned up and then the only option is to restart Windows to get it to do whatever it needs to do to clean up the state.

@StephenWhiteD3G 

 

Yes, a system restart also solves this reliably for me.

 

To me this just looks like a bug in AppInstaller. Would be great if someone from MS could confirm that and let us know about any plans to fix this and how such a fix might be distributed. As it stands right now, this bug essentially means we can't use AppInstaller at all, this seems a pretty critical bug in a very core code path?

@davidanthoff @StephenWhiteD3G @marcinotorowski 

 

Just as an update, we are still investigating this issue. Thank you for your patience, we will continue to update you as we learn more. 

 

Best,

Sharla 

FWIW, I am experiencing this issue as well.