ToastNotificationManager.CreateToastNotifier() crash the app if user change their username without signing out

[HO-COOH]

Describe the bug

My app recently get a user report of crashing. After checking the log, I found it crashes in toast notification related apis. His pc was connected to a domain, and has its username changed, without manual rebooting / manual signing out his account. Some quick experiment found out that if you launch the app first then change your username, calling ToastNotificationManager.CreateToastNotifier() will throw exception.

This is very corner case, but I think it should be documented (or don't throw exception). The majority of the WinRT api can still function normally in this case.

Steps to reproduce the bug

1. Create a winui3 C++ app packaged
2. Use this code:

    void MainWindow::myButton_Click(IInspectable const&, RoutedEventArgs const&)
    {
        myButton().Content(box_value(L"Clicked"));

        winrt::Windows::Data::Xml::Dom::XmlDocument doc;
        doc.LoadXml(LR"(<toast>
  
  <visual>
    <binding template="ToastGeneric">
      <text>Hello World</text>
      <text>This is a simple toast message</text>
    </binding>
  </visual>
  
</toast>)");
        winrt::Windows::UI::Notifications::ToastNotification toast{ doc };
        
        winrt::Windows::UI::Notifications::ToastNotificationManager::CreateToastNotifier()
            .Show(toast);

        MessageBox(NULL, L"", L"finished", 0);
    }

3. Build and run the app
4. Change the username (you can simply run netplwiz to do that)
5. Click the button to send a toast, observe the crash

Expected behavior

No response

Screenshots

No response

NuGet package version

Windows App SDK 1.6.3: 1.6.241114003

Packaging type

Packaged (MSIX)

Windows version

No response

IDE

Visual Studio 2022

Additional context

Windows 11 23H2

[DarranRowe]

I have a question here, C++/WinRT translates the COM errors to C++ exceptions, specifically winrt::hresult_error.

Is this a case of not handling the C++ exception? Does the debugger output show that there is a winrt::hresult_error going uncaught, and does the debugger output that should end up there from RoOriginateError not appear or is it not giving anything useful?

If this is a case of why isn't the uncaught exception handler not catching the exception, then this exception is actually being thrown in the window procedure in Windows API parlance. What this means is that in the message pump, the message has been obtained from the message queue using GetMessage and has been dispatched to the window procedure using DispatchMessage, in doing this, there was a brief side trip into kernel mode and then the call to the window procedure came after transitioning back from kernel mode to user mode. This means that any exception thrown in the event handlers has to transition back across kernel mode. In older versions of Windows, that user mode to kernel mode transition will act like an unhandled exception and so the process will be terminated there. As far as I know, it is only Windows 11 24H2 where the exception will properly be transported across kernel mode and get caught on the main thread. So this seems to require OS support, or it hasn't been back ported yet.