Version 1.7 regression: Exception thrown from an async method crashes the app and won't be caught by the unhandledException event

[HotCakeX]

Describe the bug

This is a regression in version 1.7 where an exception thrown from an async method crashes the entire app even if unhandled exceptions are handled by the App class.

Steps to reproduce the bug

When this method is run as a result of a click from the UI, it will crash the entire app. (It works fine if the method is not async).

private async void BrowseForFilesSettingsCard_Click(object sender, RoutedEventArgs e)
{
	throw new InvalidOperationException("test");
}

even though the App class is set to capture it

this.UnhandledException += App_UnhandledException;

private async void App_UnhandledException(object sender, Microsoft.UI.Xaml.UnhandledExceptionEventArgs e)
{
	Logger.Write(ErrorWriter.FormatException(e.Exception));	
	e.Handled = true;
	await ShowErrorDialogAsync(e.Exception);
}

Expected behavior

The unhandled exception event handler in the app class must catch it and log the error.

This problem doesn't happen in version 1.6.250228001

Screenshots

No response

NuGet package version

Windows App SDK 1.7.0: 1.7.250310001

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 24H2 (22621, October 2024 Update)

IDE

Visual Studio 2022-preview

Additional context

No response

[Balkoth]

Please provide a minimal repo.

[HotCakeX]

Please provide a minimal repo.

Sure, i narrowed it down and updated my post.

[Balkoth]

Can confirm, 1.7.0 just crashes while latest 1.6 "handles" this exception.

[lhak]

This is still an issue with 1.7.1 and makes debugging applications from Visual Studio very challenging (app just crashes if native debugging is not enabled). It also breaks libraries that log the exceptions.

Interestingly, it looks like catching unhandled exceptions still works for C++ apps, but is broken for C# apps. Maybe @Scottj1s can help here as in #6153?

[HotCakeX]

This is still an issue with 1.7.1 and makes debugging applications from Visual Studio very challenging (app just crashes if native debugging is not enabled). It also breaks libraries that log the exceptions.

Interestingly, it looks like catching unhandled exceptions still works for C++ apps, but is broken for C# apps. Maybe @Scottj1s can help here as in #6153?

Not only that, i use UnhandledException in my app to handle all exceptions, even those i intentionally throw to properly display message to user. This issue is preventing me from using WinAppSDK 1.7.x entirely. This is a high severity issue.

[lhak]

I looked at the stack traces when an exception is thrown comparing appsdk 1.6 and 1.7. I think I found the issue! In 1.6, the DispatcherQueueSynchronizationContext.Post() method looks like this:

public override void Post(SendOrPostCallback d, object state)
  {
    if (d == null)
    {
      throw new ArgumentNullException("d");
    }
    m_dispatcherQueue.TryEnqueue(delegate
    {
      try
      {
        d(state);
      }
      catch (Exception ex)
      {
        ExceptionHelpers.ReportUnhandledError(ex);
      }
    });
  }

and in 1.7:

 public override void Post(SendOrPostCallback d, object state)
    {
        if (d == null)
        {
            throw new ArgumentNullException("d");
        }

        m_dispatcherQueue.TryEnqueue(delegate
        {
            d(state);
        });
    }

So the exception is no longer caught in 1.7 and passed to the UnhandledException handler. I can confirm that using a custom DispatcherQueueSynchronizationContext restoring the 1.6 behaviour fixes this issue.

[zhuxb711]

So why the code reviewer do not notice such breaking changes? Someone need to stand out and explain the reason