Winforms .exe in MSIX Package Does Not Startup After Auto Update

[ChreesM]

We are deploying a classic Winforms .exe via MISX. Approximately 20% of the time, the application does not start automatically after an auto update completes. After an update and failed start, we can trigger the application to startup by just typing random text into the Windows search bar. Another way we can trigger it to start is to re-launch the application via the start menu item, but of course two instances will then be running. 

We are testing with 5 separate workstations that have Windows 10 1903. I have logging in the Main method of the application in program.cs, so I can see that nothing attempts to execute after the auto update until the user intervenes. This has lead me to believe that there is nothing in the application itself causing the issue, but rather the MSIX framework or a configuration option. 

The appinstaller file -

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller Uri="{AppInstallerUri}"
              Version="{Version}"
              xmlns="<a href="<a href="<a href="http://schemas.microsoft.com/appx/appinstaller/2018" target="_blank">http://schemas.microsoft.com/appx/appinstaller/2018</a>" target="_blank"><a href="http://schemas.microsoft.com/appx/appinstaller/2018</a" target="_blank">http://schemas.microsoft.com/appx/appinstaller/2018</a</a>>" target="_blank"><a href="<a href="http://schemas.microsoft.com/appx/appinstaller/2018</a" target="_blank">http://schemas.microsoft.com/appx/appinstaller/2018</a</a>" target="_blank"><a href="http://schemas.microsoft.com/appx/appinstaller/2018</a</a" target="_blank">http://schemas.microsoft.com/appx/appinstaller/2018</a</a</a>>>">
  <MainBundle Name="{Name}"
              Version="{Version}"
              Publisher="{Publisher}"
              Uri="{MainPackageUri}"/>
  <UpdateSettings>
    <OnLaunch HoursBetweenUpdateChecks="0" ShowPrompt="true" UpdateBlocksActivation="true"/>
    <AutomaticBackgroundTask/>
    <ForceUpdateFromAnyVersion>true</ForceUpdateFromAnyVersion>
  </UpdateSettings>
</AppInstaller>

The appxmanifest -

 
<?xml version="1.0" encoding="utf-8"?>
<Package
  xmlns="<a href="<a href="<a href="http://schemas.microsoft.com/appx/manifest/foundation/windows10" target="_blank">http://schemas.microsoft.com/appx/manifest/foundation/windows10</a>" target="_blank"><a href="http://schemas.microsoft.com/appx/manifest/foundation/windows10</a" target="_blank">http://schemas.microsoft.com/appx/manifest/foundation/windows10</a</a>>" target="_blank"><a href="<a href="http://schemas.microsoft.com/appx/manifest/foundation/windows10</a" target="_blank">http://schemas.microsoft.com/appx/manifest/foundation/windows10</a</a>" target="_blank"><a href="http://schemas.microsoft.com/appx/manifest/foundation/windows10</a</a" target="_blank">http://schemas.microsoft.com/appx/manifest/foundation/windows10</a</a</a>>>"
  xmlns:uap="<a href="<a href="<a href="http://schemas.microsoft.com/appx/manifest/uap/windows10" target="_blank">http://schemas.microsoft.com/appx/manifest/uap/windows10</a>" target="_blank"><a href="http://schemas.microsoft.com/appx/manifest/uap/windows10</a" target="_blank">http://schemas.microsoft.com/appx/manifest/uap/windows10</a</a>>" target="_blank"><a href="<a href="http://schemas.microsoft.com/appx/manifest/uap/windows10</a" target="_blank">http://schemas.microsoft.com/appx/manifest/uap/windows10</a</a>" target="_blank"><a href="http://schemas.microsoft.com/appx/manifest/uap/windows10</a</a" target="_blank">http://schemas.microsoft.com/appx/manifest/uap/windows10</a</a</a>>>"
  xmlns:rescap="<a href="<a href="<a href="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities" target="_blank">http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities</a>" target="_blank"><a href="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities</a" target="_blank">http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities</a</a>>" target="_blank"><a href="<a href="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities</a" target="_blank">http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities</a</a>" target="_blank"><a href="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities</a</a" target="_blank">http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities</a</a</a>>>"
  IgnorableNamespaces="uap rescap">
  <Identity
    Name="IMSPolicy.local"
    Publisher="CN=Foo, O=Foo, L=MyTown, S=MyState, C=US"
    Version="1.0.14.0" />
  <Properties>
    <DisplayName>MyApp</DisplayName>
    <PublisherDisplayName>FooPublisher</PublisherDisplayName>
    <Logo>Images\StoreLogo.png</Logo>
  </Properties>
  <Dependencies>
    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.0.0" MaxVersionTested="10.0.0.0" />
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.14393.0" MaxVersionTested="10.0.14393.0" />
  </Dependencies>
  <Resources>
    <Resource Language="x-generate"/>
  </Resources>
  <Applications>
    <Application Id="App"
      Executable="$targetnametoken$.exe"
      EntryPoint="$targetentrypoint$">
      <uap:VisualElements
        DisplayName="MyApp Dev"
        Description="MyApp application package"
        BackgroundColor="transparent"
        Square150x150Logo="Images\Square150x150Logo.png"
        Square44x44Logo="Images\Square44x44Logo.png">
        <uap:DefaultTile Wide310x150Logo="Images\Wide310x150Logo.png"  Square71x71Logo="Images\SmallTile.png" Square310x310Logo="Images\LargeTile.png"/>
        <uap:SplashScreen Image="Images\SplashScreen.png"  BackgroundColor="white"/>
      </uap:VisualElements>
    </Application>
  </Applications>
  <Capabilities>
    <Capability Name="internetClient" />
    <rescap:Capability Name="runFullTrust" />
  </Capabilities>
</Package>

[#2]

Hi Christophe,

For apps packaged with Conveyor [1] we have a workaround:

1. We default to background updates, which don't have this issue.

2. We have a tiny Win32 app that drives the package manager via the WinRT/C++ API and then starts the app once complete. If a packaged program wishes to force an update and knows one is available e.g. from a server poll, it simply invokes the bundled EXE and then quits. The stub EXE then drives the install/upgrade process whilst showing a progress bar and app logo, and relaunches the app when done.

This gives a similar experience to the built-in "check on start" mode, but with these caveats:

1. It's a feature of Conveyor, not MSIX. Therefore you must use Conveyor to package your app to get it.

2. It's not yet a fully launched/documented feature. You'd probably want our help to activate it. We should launch it soon though.

3. It's up to your app to notice there's a new version available and trigger the update process. For example by doing a quick poll whilst showing a splash screen. We don't block startup like the AppInstaller integration will do, because you may wish to overlap the update check with things like logging in to a server, instead of adding app latency every single time.

You can see a short looping video of what the installer EXE looks like on our website: https://hydraulic.software/

[#3]

Hi everyone,
We stumbled across this problem recently, and we may have found a solution to this that I wanted to share.

We had the problem that on starting the app the update dialog would take quite the time to do its check, then closes and nothing happens. Only clicking the start menu would cause the app to start. We tested pinning the app to the taskbar, which would cause the app to start sooner, but the update dialog to be slow still.
One colleague with windows 10 had no issue with the update dialog, which would immediately close, but still the app would not start unless clicking the start menu.

We have just switched from a signing certificate issued by our company CA to a code signing certificate that we paid for. And now it just works. For everyone in out team the update dialog is only there a short time, and then the app starts, without needing to click the start menu.
I am not proficient with certificates, but I would guess some step in the validation process ran into a timeout before and now does not, and it also solved the startup issue. Maybe someone that still has the issue can test if this solves their issue also? If so, we may have a more precise starting point to take up investigation again.

[#4]

I have a Winforms / WPF app in an MSIX/Appx package.

After some release of Windows, it has gotten very slow to launch.  So slow, I had to stop providing it to customers.  On the dev machine, it's 5 seconds before the app shows the splash screen and goes into main and starts loading.  On customers machines it takes about 30 seconds before Windows gives the application control.

I don't believe this has to do with auto updating, as the application doesn't use it.

The benefit of these app packages is that it solves DLL stomping.

But, the app has a large number of DLLs.  Is it possible that Windows is scanning and hashing all these DLLs before launch?

@JMarianczuk 

[#5]

Is there any news?

[#6]

@Lars_Pedersen 

Hi,

We are actively looking into this issue. We were able to repro it, but the repro is not 100%.

We are still analysing what can be causing this and what can be done to fix it.

I will share an update, once I have it. Thanks for your feedback and patience.

Regards,

Sushant

MSIX PM

[#7]

@Sushant_Bansal Any update?

[#8]

I'm losing hope that they will ever fix this bug.