Forum Discussion
Winforms .exe in MSIX Package Does Not Startup After Auto Update
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>
<?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>
46 Replies
- 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.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
ChreesM I can repro this 100 % of the time with my own MSIX app, just by pointing the .appinstaller file to a different version.
I have found out that the app actually launches, right when the dialog closes, but it becomes a Background process - only visible in the Task Manager.I believe this is why it is sometimes possible to awaken it by clicking the Start button, searching and so on.
My workaround to this bug is to disable the app from being able to run as a background process at all. Go to Settings -> Background apps to do this.
The dialog closes but the user has to start the app manually. This is also a usability issue because the user is not told they have to start it manually.- I believe this sounds very similar to the problem I'm experiencing here with the so-called "gap" time:
https://techcommunity.microsoft.com/t5/msix-deployment/what-is-the-quot-gap-quot-and-how-do-i-eliminate-it/m-p/2873569
The symptoms I see are identical to what you guys are seeing. The app will appear, but it needs to be prodded along or sometimes it just appears by itself.A bit more info:
- I got Windows into a state where I could reproduce this 100% of the time. The AppInstaller XML used was below.
- The AI log showed no problems, which isn't a surprise as the bug seems to be in the start/taskbar code.
- I didn't see my app EXE in task manager, not as a background task or anything else, and disabling background tasks makes no difference.
- Although I thought this was related to the "gap" in the AppxDeploymentServer logs, I can reproduce this also without any large values in the gap timings.
- In fact there is no timing issue involved here, even though it seemed that way at first. Careful testing shows that in my case, the app will never start until the start menu or search bar is interacted with, at which point it starts immediately. Interacting with other parts of the taskbar doesn't trigger this. It doesn't matter how long I wait after an upgrade - if I don't touch search or start button, the app will not launch after an upgrade.
- If I open the start menu I don't have to re-launch my app from there or do anything else. The mere act of clicking on it will cause the app to launch, and in fact, when it does it will steal focus and thus the start menu will disappear again.
- However after changing my AppInstaller XML to disable the prompt, doing a couple of upgrades, and then changing it back the problem has gone away. Now Windows starts the app after an upgrade successfully. To me this smells like another caching bug: perhaps Windows isn't handling changes to the OnLaunch settings properly and the taskbar/AppInstaller components can get confused about what update modes the app is meant to be using?
XML:
<OnLaunch HoursBetweenUpdateChecks="0" ShowPrompt="true" UpdateBlocksActivation="true"/>
<AutomaticBackgroundTask />
<ForceUpdateFromAnyVersion>true</ForceUpdateFromAnyVersion>I noticed from reading the documentation that the way App Installer is invoked doesn't seem very deeply integrated with Windows. Supposedly the upgrade check is done only if the taskbar is used to launch the app. If you have e.g. a shortcut on your desktop, and use that, then App Installer doesn't get involved at all. Or if any other process starts your app, same thing, the update check isn't done.
Therefore what seems to be happening is something like this:
- The taskbar/start menu code is asked to launch an app controlled by AppInstaller.
- It consults its timeout list and notices it's time to do an update check.
- It passes control to App Installer to do the update and waits for a signal that the update has been completed.
- AI sends that signal (somehow).
- Something goes wrong: the Start code has been put to sleep in a way that it doesn't wake up when the signal arrives.
- Interacting with the taskbar in such a way that the list of app icons is pulled up, re-awakens that part of the code, which then notices the signal from App Installer and continues with the launch of the app.
This doesn't happen on every code path. If an update check is done but no update is required, the launch works OK (but that might be a timing-caused red herring?).
A workaround is to disable the prompt using ShowPrompt="false" and go to fully silent upgrades i.e. with background upgrades only. This means that if an update has just been released and the user starts their app, it will be the old version and the next start will be upgraded, but, this is only a short window of time as after 8 hours Windows will (supposedly) apply the upgrade in the background anyway. Fully silent upgrades are what Chrome uses so this is an acceptable workaround for now - it is only an issue if the app needs to be forcibly upgraded to match e.g. a protocol change on a server.
In that case the app itself may need to figure out by itself if it's fully up to date or not and if not, restart itself to re-load the updated code - possibly monitoring the AppX logs to figure out when Windows has finished applying the upgrade.
A few questions:
- To make sure I understand what's going on, are you launching the app, the update UI pops up, installs the update successfully and at the end of the update the app doesn't launch?
- Can you please share:
C:\Users\<UserName>\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState\AILog.txt from when this issue occurs.
And just to make sure, can you please check Task Manager to see if your app's process is present when the issue occurs.
Thanks
Tanaka
1. Yes, that is correct.
2. attached
3. The application's process does not appear in Task Manager during a hang.
