I am building an MSIX application for windows 10 with a .wapproj project. On some machines (primarily laptops it seems), the application does not start after the user clicks it in the start menu. Instead nothing happens until the user either clicks on the start menu again, or on the windows search bar. Once the user interacts with either of these the application instantly starts up. Our testers have tried waiting for up to half an hour so it is not an issue with loading times. On machines that are affected the issue seems to reproduce every time. The application can be downloaded here (https://application-downloads.azurewebsites.net/) if anyone wants to try to reproduce this for themselves.
I apologise for this question being somewhat vague and perhaps more appropriate to a bug report but I am totally stumped and don't even know who to report it to. On one hand I can't see how my code could possibly cause this, but on the other I have never seen this issue in any other application (it is worth noting I have not been able to find another sideloaded msix application to test with). Even if it is not an issue with my code I don't know if it is a problem with the MSIX framework, the appinstaller application or windows itself.
Any suggestions are appreciated.
Update - Answer:
For a description of why this happens, see the accepted answer. The fix proposed there, of using periodic update checks instead of updating on application start, is not acceptable to me as starting an out of date client can cause catastrophic failures when it connects to the server. Luckily, due to another equally dumb issue with microsoft's appinstaller system, I already had a fallback system built (for when users have a desktop shortcut). You can find the code for this here: https://github.com/MicrosoftDocs/msix-docs/issues/59#issuecomment-832260691
if you run that code at the start of your application you can disable the windows update system for your application altogether, and have the update run manually.
Although it was not really acknowledged as bug by Microsoft, there seem to be many users affected by the problem: https://techcommunity.microsoft.com/t5/msix/winforms-exe-in-msix-package-does-not-startup-after-auto-update/m-p/965978/highlight/false
A workaround is to disable the check for updates on startup and to use background updates instead. Drawbacks of periodic updates: