On WebView getting disposed, it hangs the rendering thread - without any possibility for restoring it

Description
When the WebView disposes one of the active processes, at the same time as another is starting, it will cause the rendering of any further WebViews to be broken. This problem persists until the entire application is restarted -regardless of us killing all active processes and then starting new ones, or removing all graphic elements referencing any WebView.
The problem only occurs if the WebView is at the same time displayed in a different resolution than the one it was 'born' in. For example when someone starts the program on one computer and then later remotes in to view the same app but on a different screen.
It also occurs when a laptop is connected to a secondary monitor, especially if the new monitor then becomes the primary picture - thus forcibly moving the app into a new resolution - and back again.

This is a pretty major issue for us, as large parts of our clients are either working remotely, utilizing a laptop or both.

This has been a long bug hunt, but we have finally nailed it into a minimal reproducible example. The example forces a Dispose() on the WebView when the control hits the Unloaded event, and then immediately builds a new one on the Loaded event. In the two following examples Unloaded and Loaded will be triggered by real-world examples, caused by resolution changes, forcing a redraw of the window containing the WebView.

Version
SDK: 1.0.1108.4 Stable (and most previous versions - we update quite often)
Runtime: 99.0.1150.30 Evergreen
Framework: WPF
OS: Windows 10.0.19044 Build 19044

Repro Steps
Method 1

1. Choose a computer with 2 monitors (These must not be of the same make/type, since that will not trigger a change in resolution)
2. Restart the computer
3. Build and start the attached application
4. Drag the window from the first screen [S1], to the second screen [S2]
5. Change the zoom level of the second screen [S2] to 125%
6. The applications window rendering will now freeze

This can be replicated for Zoom level 150% as well

ATT: After each Zoom level has been used once, the problem cannot be replicated on that level again until the computer has been restarted!

Method 2

1. Choose a computer to which a remote connection can be made and one to make the connection from (both computers must have a dedicated graphics card - they must not share both graphics card and screen make/type)
2. Restart the main computer
3. Build and start the attached application
4. Lock the current computer
5. Remote from the second computer to the first
6. The applications window rendering will now freeze

By swapping the order of computers the problem can be replicated ad infinitum, by just restarting the application.

MainWindow.xaml
MainWindow.txt

WebViewWrapper.cs
WebViewWrapper.txt

Oddities
The reason the problem was so hard to nail was that originally we did not call Dispose() explicitly, which then meant that the WebView would dispose when the related Garbage Collector (not the one controlled by the Application!) would pass by. Then we added the Dispose call on Unloaded as a way to get rid of them on our terms, which only helped to exacerbate the problem.
In general we never have more than one WebView per window.

No errors are thrown, from either WPF nor the WebView component. Even with the most verbose output from WPF everything is acting as expected, the error is solely in the rendering part. Windows Activity Log does not report anything either.

Only windows containing an active WebView will be affected by the rendering freeze. Our application allows users in separate windows to browse PDF files (WebView) and chat on them (no WebView) - when the freeze occurs the users can still interact with the chat windows, and see changes happening in these.
In some cases the freeze only affects a newly created WebView, and any WebViews created after this - WebViews in windows created prior to this still function as expected.

When a window is frozen, destroying all active WebViews within it will unfreeze that window, but creating a new WebView in that window or re-enabling the old one will immediately re-freeze that window.

Frozen windows are only frozen on the rendering part, if you know where the buttons are you can still interact as usual with the window, even going so far as dragging it to other places.

We have tried to remedy the problem by creating methods for clearing the WebView but nothing seems to unload the problematic state it has entered. We have tried:

• Removing all active WebViews
• Then killing any remaining processes
• Then clearing all user data folders related to the WebViews (with and without delay)
• Then unloading the Library - kernel32.FreeLibrary (with and without delay)
• Then reloading the Library - kernel32.LoadLibraryW (with and without delay)
• Then starting a completely new WebView (with and without delay)
• It still freezes.

AB#38452343

Start with the attached MainWindow.xaml and WebViewWrapper.cs minimal reproduction, then run the two monitor and remote-connection scenarios described in the issue. Trace the Unloaded Dispose and Loaded recreation sequence around the resolution change. Done means newly created WebViews continue rendering after moving between resolutions or displays without requiring an application restart.