App on Microsoft Store runs fine on most user systems but fails to run on others with a stowed exception being reported in MS Partner Center

[JosHuybrighs]

This is probably not the right place to have this discussion but I don't know where else I can bring this up.
I have a desktop app on the Microsoft Store that uses the WinAppSDK and runs successfully on most of the user's computers.
For some systems however the Microsoft Partner Center's health section for the app shows a lot of 'stowed exceptions' occurring when the application is being started.

The stack trace is only:

0 Microsoft.ui.xaml.dll   DirectUI::FrameworkApplication::StartDesktop    0x0000000000195D30
1 Microsoft.ui.xaml.dll   DirectUI::FrameworkApplicationFactory::Start    0x0000000000000070

Some have a minidump file attached which when analyzing with WinDbg shows:

STACK_TEXT:  
0000022b`ddafc7c0 00007ff9`4f7bcbef combase!RoOriginateLanguageException+0x5f
STACK_COMMAND:  *** Stowed Exception v2 ***; .exr -1; dpp 0x22bddafce20 L0x2; dt 0x22be437e168 combase!STOWED_EXCEPTION_INFORMATION_V2 -r; dps 0x22bddafc7c0 L0x2; *** Nested 'LEO1' @ 0x22BBCAFD628 ***; *** NOSOS *** ; ** Pseudo Context ** StowedPseudo ** Value: 25533b22ce0 *
FAULTING_SOURCE_LINE:  onecore\com\combase\winrt\error\error.cpp
FAULTING_SOURCE_FILE:  onecore\com\combase\winrt\error\error.cpp
FAULTING_SOURCE_LINE_NUMBER:  1517
FAULTING_SOURCE_SRV_COMMAND:  https://dev.azure.com/microsoft/OS/_apis/git/repositories/os.2020/items?path=/onecore/com/combase/winrt/error/error.cpp&versionDescriptor.versionType=commit&versionDescriptor.version=d1ef9e76dc48ba4fc8ee663062ec9a2cec78ee77&versionDescriptor.options=none&download=true&api-version=2.0
SYMBOL_NAME:  combase!RoOriginateLanguageException+5f
MODULE_NAME: combase
IMAGE_NAME:  combase.dll
FAILURE_BUCKET_ID:  STOWED_EXCEPTION_NOSOS_8000ffff_combase.dll!RoOriginateLanguageException

I understand that the error is most likely due to an unhandled exception within a WinRT or COM API which my application is calling.
To trap those exceptions the app constructor takes care of this like so (I am using MS AppCenter to track faults):

public App()
{
    sAppInstance = this;
    this.InitializeComponent();

    // Initialize logger
    EnableLogging();

    // Enable AppCenter
    EnableAppCenter();

    // Subscribe for unhandled exceptions
    UnhandledException += (object sender, Microsoft.UI.Xaml.UnhandledExceptionEventArgs e) =>
    {
        e.Handled = true;
        AppUnhandledException(e.Exception);
    }; 
    TaskScheduler.UnobservedTaskException += (object sender, UnobservedTaskExceptionEventArgs e) => AppUnhandledException(e.Exception);
   ...
}

AppUnhandledException(e.Exception) makes a large string of the stack and sends it in chunks to MS AppCenter.

I don't get anything however in MS AppCenter that relates to DirectUI::FrameworkApplication::StartDesktop.

So, are there any suggestions how to deal with this?
I just saw myself that it is probably better to do EnableLogging() (it accesses ApplicationDataContainer in local settings to see if logging is enabled) after the registration for unhandled events and so I will do that in the next update of the app and see what it gives.

In the mean time however what remains important: on most user's system this error doesn't come up. Why on others? The app is deployed selfcontained and so I have to expect that there shouldn't be any wrong or missing DLLs in the package.
Or is it not that simple?

I keep thinking that a WinAppSDK/WinUI desktop app needs certain dlls in Windows that are not part of the package but aren't necessarily available on a user's system. If so, shouldnt there be an error when the app is being installed?

[RDMacLachlan]

Created Issue #4861 to support investigation on this challenge. Please view this Issue for any follow-up.