Forum Discussion

StephenWhiteD3G's avatar
StephenWhiteD3G
Iron Contributor
Jun 16, 2020

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:


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.

  • Mo_Velayati's avatar
    Mo_Velayati
    Copper Contributor
    Has this been addressed?
    Automatic Updates still fail unless the DoSvc service is restarted.
  • yowl00's avatar
    yowl00
    Copper Contributor
    Still getting this on 21H1 although 20H2 seemed ok. Sigh, come on Microsoft what happened to "Developers, developers, developers"?
  • ChreesM's avatar
    ChreesM
    Brass Contributor

    StephenWhiteD3G 

    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...");
    
                try
                {
                    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()
            {
                try
                {
                    var service = new ServiceController("DoSvc");
                    var timeout = TimeSpan.FromMinutes(1);
                    if (service.Status != ServiceControllerStatus.Stopped)
                    {
                        service.Stop();
                        service.WaitForStatus(ServiceControllerStatus.Stopped, timeout);
                    }
    
                    service.Start();
                    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)
            {
                try
                {
                    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;
                        Process.Start($"ms-appinstaller:?source={appInstallerUri}");
                        Application.Exit();
                    }
                    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);
                    _logger.Error(ex.Message);
                    _logger.Error(ex.InnerException.ToString());
                }
            }



  • JulesB's avatar
    JulesB
    Copper Contributor

    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?

    • GToison's avatar
      GToison
      Copper Contributor
      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)
      • JulesB's avatar
        JulesB
        Copper Contributor
        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.
  • annaojdowska's avatar
    annaojdowska
    Copper Contributor

    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. 

      • GToison's avatar
        GToison
        Copper Contributor

        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.

  • LuKePicci's avatar
    LuKePicci
    Brass Contributor

     

    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).

    • StephenWhiteD3G's avatar
      StephenWhiteD3G
      Iron Contributor
      LuKePicci

      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.
      • LuKePicci's avatar
        LuKePicci
        Brass Contributor
        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.
  • 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

    • StephenWhiteD3G's avatar
      StephenWhiteD3G
      Iron Contributor





      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.

      • StephenWhiteD3G's avatar
        StephenWhiteD3G
        Iron Contributor
        @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.

Resources