WinUI 3 app window with WebView2 crashes when closing

[JaiganeshKumaran]

Describe the bug

When you have a WinUI 3 window containing a WebView2, closing it causes a crash.

Steps to reproduce the bug

1. Put a WebView2 instance in a WinUI 3 window.
2. Close the window.
3. See the app crashing.

Expected behavior

The app shouldn't crash.

Screenshots

No response

NuGet package version

WinUI 3 - Windows App SDK 1.3 Experimental 1: 1.3.230202101-experimental1

Windows version

Windows 11 (21H2): Build 22000

Additional context

Exception thrown at 0x00007FFCAE1C7B5C (KernelBase.dll) in GlanceBrowser.exe: WinRT originate error - 0x80000013 : 'The given object has already been closed / disposed and may no longer be used.'.
onecore\com\combase\winrt\error\restrictederror.cpp(767)\combase.dll!00007FFCB1D1D160: (caller: 00007FFCB1D273FC) ReturnHr(4) tid(2670) 8000FFFF Catastrophic failure
onecore\com\combase\winrt\error\restrictederror.cpp(767)\combase.dll!00007FFCB1D1D160: (caller: 00007FFCB1D273FC) ReturnHr(5) tid(2670) 8000FFFF Catastrophic failure
Exception thrown at 0x00007FFCAE1C7B5C in GlanceBrowser.exe: Microsoft C++ exception: winrt::hresult_error at memory location 0x000000D53918B990.

template <typename D> auto consume_Microsoft_Web_WebView2_Core_ICoreWebView2_3<D>::TrySuspendAsync() const
{
    void* operation{};
    /* this line */ check_hresult(WINRT_IMPL_SHIM(winrt::Microsoft::Web::WebView2::Core::ICoreWebView2_3)->TrySuspendAsync(&operation));
    return winrt::Windows::Foundation::IAsyncOperation<bool>{ operation, take_ownership_from_abi };
}

[Scottj1s]

@DmitriyKomin Any ideas here? Possible 1.3 regression?

[mlynch]

Also seeing this behavior in 1.3.0: More info and call stack with symbols: #6872 (comment)

[DmitriyKomin]

Duplicate of #6872, fixed in WinAppSDK 1.3.1 (1.3.230502000)

@mlynch - with the fix, an exception wrapping HR 0x80000013 (RO_E_CLOSED) can still get raised but will be swallowed in the XAML level. So you'd get still get a debugger break if you have "Break on first-chance exceptions enabled" setting in the debugger, but you can continue safely (or disable the setting). Also, you'll still see the crash if DebugSettings.FailFastOnErrors is on (off by default). Outside of these special circumstances you should not be seeing this error any more.