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
Yes it's no problem if you download the .msix or .msixbundle. The issue is with the .appinstaller file and the misleading XML error.

We pretty much want to use msix for the automatic updates so that's not a lot of use for us especially as in some cases we are installing on client machines. Asking them to re-start their computer or stop and start a service isn't really a workable solution.

Hi everyone,

If anyone is interested, I have a workaround that I'm currently testing.

So, the idea is to do basically parse your .appinstaller file, download the .msixbundle locally, and launch it. Sure it sucks, but it's the best workaround I could come up with, knowing this crappy bug.
(the idea is - if you download and launch the .msixbundle, it works).
If anyone's interested, I can share the code (it's C#)


You would need to update your code:


protected override async void OnLaunched(LaunchActivatedEventArgs e) {
  if (setup_kit_util.has_update_downloaded_locally() && await setup_kit_util.launch_update_kit()) {


and somewhere in your code's initialize routine, add this:

await Task.Run(async () => await setup_kit_util.download_update_task());



I was discussing something along these lines as a possible work around earlier today although it feels like if you are going to this effort might as well just roll your own bespoke updating system.

However if you do the work in parsing the .appinstaller file I would be interested :).


I don't consider parsing appinstaller a good solution, but if you want to use it as a workaround you can use a parser from my repo instead of reinventing the wheel 

I've already done the work.
Parsing is easy - I only need to look for the current version of your kit in the .appinstaller.
Then see if your current version matches that. If it's higher, that means there's a new version on server -- download and install it.

Here's the code:


LATER EDIT: Clearly this only deals with your part of the equation. If you have dependencies that need to be updated, things will get a lot more complicated.


A WORKING SOLUTION ("no parsing required") - We also ran into this issue recently within our organization so I coded an asynchronous method to stop and start the Delivery Optimization service before the call to CheckUpdateAvailabilityAsync(). Note - Our application  runs under the context of the currently logged in user, therefore we had to set a global policy to allow users in the USERS group to stop and start the service name DoSvc . Additionally, these methods will also allow you to take complete control of leveraging MSIX to check for updates whenever you require, and the app will relaunch post update. It will work from desktop shortcuts, and when an MSIX app is pinned to the taskbar (normally MSIX will not update in these scenarios). I call these methods from a timed event that is configured via app settings per environment.

        private async Task CheckForUpdateAsync()
            if (!string.IsNullOrEmpty(_appSettingsProvider.ApplicationVersion))
                _logger.Info($"The current installed application version is: {_appSettingsProvider.ApplicationVersion}");

            _logger.Info("Checking for update...");

                var packageManager = new PackageManager();
                var installedPackage = packageManager.FindPackageForUser(string.Empty, Package.Current.Id.FullName);
                if (installedPackage != null)
                    var tasks = new List<Task>
                        Task.Run(() => RestartDeliveryOptimizationService())
                    await Task.WhenAll(tasks);

                    var result = await installedPackage.CheckUpdateAvailabilityAsync();
                    ProcessPackageResult(result, installedPackage);
            catch (InvalidOperationException ex)
                _logger.Info("AutoUpdater was unable to determine the installed package, which is typically due to debugging in VisualStudio. " + ex);
            catch (Exception ex)
                _logger.Error("An error occurred while checking for the availability of a package update. " + ex);
        /// <summary>
        /// Restarts the Delivery Optimization Service to ensure updates succeed. Currently a work around for a known issue. - CM
        /// </summary>
        private void RestartDeliveryOptimizationService()
                var service = new ServiceController("DoSvc");
                var timeout = TimeSpan.FromMinutes(1);
                if (service.Status != ServiceControllerStatus.Stopped)
                    service.WaitForStatus(ServiceControllerStatus.Stopped, timeout);

                service.WaitForStatus(ServiceControllerStatus.Running, timeout);
            catch(Exception ex)
                _logger.Error("There was a problem starting DoSvc." + ex.InnerException.ToString());
        private void ProcessPackageResult(PackageUpdateAvailabilityResult result, Package installedPackage)
                if (result != null && (result.Availability == PackageUpdateAvailability.Available || result.Availability == PackageUpdateAvailability.Required))
                    _logger.Info("A package update is available.");
                    _timer.Enabled = false;

                    var appInstallerUri = installedPackage.GetAppInstallerInfo().Uri;
                else if (result.Availability == PackageUpdateAvailability.Unknown)
                    _logger.Warn("The package update availability status = Unknown.");
                else if (result.Availability == PackageUpdateAvailability.Error)
                    _logger.Warn($"The package update availability status = Error. {result.ExtendedError.Message}");
                    _logger.Warn($"No update information associated with app DisplayName:{installedPackage.DisplayName}, FullName:{Package.Current.Id.FullName}");
            catch(Exception ex)
                _logger.Error("An error occurred while processing the package update. " + ex);

Still getting this on 21H1 although 20H2 seemed ok. Sigh, come on Microsoft what happened to "Developers, developers, developers"?
Has this been addressed?
Automatic Updates still fail unless the DoSvc service is restarted.


This is caused by a bug in the Delivery Optimization subsystem of Windows. I provide an explanation of what seems to be happening and an easy workaround here:

I've tested the workaround a bit with my own app and it seems to resolve the issues. Auto updates are reliable after this. I hope it helps you all!