Winforms Application crashes when WebView2 and CefSharp are used at the same time with WebView2 v121

[TurmCoder]

Is there an existing issue for this?

• I have searched both open/closed issues, no issue already exists.

CefSharp Version

120.2.70

Operating System

Windows 10

Architecture

x64

.Net Version

.Net 4.7.2

Implementation

WinForms

Reproduction Steps

We have the same problem in our main application, but for reproduction purposes I created a very small windows forms test solution, consisting only of a window with a docked tablelayoutpanel inside to show both controls side by side. the exact same error occurs.
It started with Microsofts rollout of webview2 121. With webview2 120 this problem does not occur.
Microsoft stopped the rollout of webview2 and re-released it on the second of february, but we have the same problem with both versions of webview 121.

This happens only when having webview2 121 installed. Be warned, that downgrading webview2 is quite hard,
so when testing this, try webview <=120 first, before updating through windows installer or the resource download from the Microsoft update catalog:
https://www.catalog.update.microsoft.com/Search.aspx?q=Microsoft%20Edge%20WebView2%20Runtime

using System;
using System.Windows.Forms;

namespace WindowsFormsApp1;

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
    }

    private void Form1_Load(object sender, EventArgs e)
    {
        var browser = new CefSharp.WinForms.ChromiumWebBrowser("https://www.google.com");
        browser.Dock = DockStyle.Fill;
        tableLayoutPanel.Controls.Add(browser, 0, 0);
        
        var webView2 = new Microsoft.Web.WebView2.WinForms.WebView2();
        webView2.Dock = DockStyle.Fill;
        webView2.Source = new Uri("https://www.google.com");
        tableLayoutPanel.Controls.Add(webView2, 1, 0);
    }
}

Expected behavior

Both controls should load and render any html.

Actual behavior

If both controls are enabled, the process crashes with following error in console:
[0202/152150.230:FATAL:hwnd_util.cc(64)] 1400
This is also the only information, that is logged into the debug.log file.

Trying to try/catch this, does not work. The client directly closing. In the windows event viewer, I can then find:

Faulting application name: WindowsFormsApp1.exe, version: 1.0.0.0, time stamp: 0xe06b492d
Faulting module name: libcef.dll, version: 120.2.7.0, time stamp: 0x65a1d154
Exception code: 0x4000001f
Fault offset: 0x044cfcd1
Faulting process id: 0x40ac
Faulting application start time: 0x01da55e34d557372
Faulting application path: C:\devel\System3\WindowsFormsApp1\bin\Debug\WindowsFormsApp1.exe
Faulting module path: C:\devel\System3\WindowsFormsApp1\bin\Debug\libcef.dll
Report Id: 8170fe33-095e-4aac-970d-3b3aafd7aabc
Faulting package full name: 
Faulting package-relative application ID: 

When removing or commenting one or the other control, the test application runs and loads without problem.s

Regression?

No response

Known Workarounds

Downgrading WebView2 to 120 is "a workaround" but not feasible for our hundreds of customers,
because it is deployed through windows update and they are not that tech-savvy.

Does this problem also occur in the CEF Sample Application

Not Tested

Other information

I placed the libcef.dll.pdbs of version 120.2.7 next to the libcef.dll.
It did not add any additional line to the debug.log.

[TurmCoder]

I need to add one information, that I stumbled upon minutes ago.
when switching the lines of code for webview2 and cefsharp in the provided examplecode, so that webview2 is initialized and loaded first, everything is working fine.
But this can hardly be translated to a fix in our case, because our main application is more complicated where depending on the user workflow he needs this CefSharp control prior to the WebView2 control or vice versa.
And because we don't know why this is a problem starting with webview2 v.121 we can not take the right action to perhaps mitigate this.

[salvadordf]

Allow me to add that this issue also affects other CEF and WebView2 wrappers.

[salvadordf]

I can reproduce this issue in the opposite creation order but I use CEF 121 and my system still has WebView2 120.
I'll create an issue in the WebView2 Feedback repository.

[salvadordf]

Added the issue : MicrosoftEdge/WebView2Feedback#4343

[salvadordf]

After further investigation I could see that this issue only happens when the application uses different versions of Chromium and Edge.
CEF 120 + Webview2 120 -> Not affected.
CEF 121 + Webview2 121 -> Not affected.
CEF 120 + Webview2 121 -> Affected.
CEF 121 + Webview2 120 -> Affected.

[JScheitelBEPC]

We have the same problem - as our users get updated to Webview2 121 - our winforms application broke - it uses CEF 120. It seems that rollback of the Webview2 is not possible in our environment. Assuming we will need to wait for an updated CEFSharp Nuget package that uses CEF 121 to resove this issue. Thank you so much for tracking this and for everything you do @salvadordf !

[Rubix982]

Same issue here. I have,

1. Chromium: Version 121.0.6167.161 (Official Build) (64-bit)
2. Microsoft Edge for Business: Version 121.0.2277.106 (Official build) (64-bit)

For us, the application simply hangs and closes the application entirely. This is the error message in event viewer. Below is a stack trace,

Faulting application name: Test.exe, version: 8.0.0.179, time stamp: 0x6331eb0e
Faulting module name: libcef.dll, version: 107.1.4.0, time stamp: 0x635333e6
Exception code: 0x80000003
Fault offset: 0x00000000015df362
Faulting process id: 0x31a4
Faulting application start time: 0x01da5b27b1480102
Faulting application path: C:\Users\saif.islam\Projects\Test\Transfer\Test\bin\Debug\net6.0-windows\Test.exe
Faulting module path: C:\Users\saif.islam\Projects\Test\Transfer\Test\bin\Debug\net6.0-windows\runtimes\win-x64\native\libcef.dll
Report Id: 0d83f936-75db-4f2d-9ee7-4c8e628d97ab
Faulting package full name: 
Faulting package-relative application ID: 

I cannot find anything by using try/catch. I could not exactly decipher what 0x80000003 meant I should have to do. An unrelated change to the control that uses the CEF seems to have broken the application.

[JScheitelBEPC]

I did try to add the matching libcef.dll.pdb to get the windbg stack trace, it always pointed at a time function no matter what I tried.

EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 00007ffb8a47124a (libcef!cef_time_from_basetime+0x0000000001628e0a)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000001
NumberParameters: 1
Parameter[0]: 0000000000000000

PROCESS_NAME: xxxx.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
EXCEPTION_CODE_STR: 80000003
EXCEPTION_PARAMETER1: 0000000000000000

STACK_TEXT:
00000005dbbfd6f0 00007ffb8ff9561f : 0000fd76f0ab2f0b 00007ffc695234f1 0000000000000000 00007ffb94f2e55e : libcef!cef_time_from_basetime+0x1628e0a
00000005dbbfdbe0 00007ffb8a688fda : 00007ffb40000600 0000000000000000 0000000000000000 0000000000000301 : libcef!CrashForExceptionInNonABICompliantCodeRange+0x18420ff
00000005dbbfdd60 00007ffb8ad83964 : 0000011cf6e62c00 0000000000000000 000004b000000780 00007ffb94f2e644 : libcef!cef_time_from_basetime+0x1840b9a
00000005dbbfdee0 00007ffb8aac638a : 00000000000e0e92 00000005dbbfe140 00000005dbbfe100 00000930000f6d00 : libcef!GetHandleVerifier+0x16aa94
00000005dbbfe020 00007ffb8b0a7da8 : 000009300051b800 00007ffb8b0a794a 00000005dbbfe138 00000005dbbfe147 : libcef!RelaunchChromeBrowserWithNewCommandLineIfNeeded+0x22505a
00000005dbbfe110 00007ffb8aa86371 : 000009300059c780 00007ffb8b0b58b1 0000093000000000 00007ffb8c9b9a93 : libcef!GetHandleVerifier+0x48eed8
00000005dbbfe1a0 00007ffb8aa91910 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : libcef!RelaunchChromeBrowserWithNewCommandLineIfNeeded+0x1e5041
00000005dbbfe2b0 00007ffb88dad806 : 00007ffb88d54c04 00007ffb8d19768b 00007ffb8d286e47 00007ffb8d18d25a : libcef!RelaunchChromeBrowserWithNewCommandLineIfNeeded+0x1f05e0
00000005dbbfe520 00007ffb88e731f8 : 00000005dbbfe9b0 00000930001219e0 00000005dbbfe920 00007ffc490bfc9e : libcef!cef_zip_reader_create+0x7fbf6
00000005dbbfe850 00007ffb88d306ba : 000000ff00000000 ffffffffffff0000 0000000000000000 0000000000000000 : libcef!cef_time_from_basetime+0x2adb8
00000005dbbfea30 00007ffb88d30267 : aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaa : libcef!cef_zip_reader_create+0x2aaa
00000005dbbfeae0 00007ffb88d549e4 : 000009300018dc90 00000005dbbff048 000009300018dc90 00007ffb88cd3465 : libcef!cef_zip_reader_create+0x2657
00000005dbbfef80 00007ffb88d546e7 : 00001820002c9300 00007ffb8d19ed32 00001820002c9300 aaaaaaaaaaaaaaaa : libcef!cef_zip_reader_create+0x26dd4
00000005dbbfefe0 00007ffb88d54c04 : 0000001851b0954e 0000feb3d204fc34 00000005dbbff298 00007ffb8d19bdc5 : libcef!cef_zip_reader_create+0x26ad7
00000005dbbff1f0 00007ffb8d19768b : 0000000000000000 0000000000000000 0000000000000000 00001820002228d0 : libcef!cef_zip_reader_create+0x26ff4
00000005dbbff270 00007ffb8d286e47 : 00000005dbbff480 00007ffb8d1913b4 00000005dbbff490 00007ffb8d1913b4 : libcef!GetHandleVerifier+0x257e7bb
00000005dbbff3b0 00007ffb8d18d25a : 00007ffc68d8a3e0 0000000000000000 00001820002c9a80 00007ffb8d1b36d9 : libcef!GetHandleVerifier+0x266df77
00000005dbbff6f0 00007ffb8a46d52d : 0000000000000008 fffffffffffffffe 0000000000000000 0000feb3d204f574 : libcef!GetHandleVerifier+0x257438a
00000005dbbff8a0 00007ffb8ac1a499 : 00000005dbbff9e0 00007ffb8d6cafbf 00000005dbbffae0 0000000000000000 : libcef!cef_time_from_basetime+0x16250ed
00000005dbbff900 00007ffb8a47c588 : 0000000000000038 fffffffffffffffe 0000000000000000 00000005dbbffa40 : libcef!GetHandleVerifier+0x15c9
00000005dbbff980 00007ffb88d9de3e : 0000182000251d60 00000005dbbffacf 0000000000000001 00001820002b82a0 : libcef!cef_time_from_basetime+0x1634148
00000005dbbffa90 00007ffb8a4aa1c4 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : libcef!cef_zip_reader_create+0x7022e
00000005dbbffb50 00007ffc67f57344 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : libcef!cef_time_from_basetime+0x1661d84
00000005dbbffbe0 00007ffc695426b1 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0x14
00000005dbbffc10 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x21
STACK_COMMAND: ~9s; .ecxr ; kb
SYMBOL_NAME: libcef+1628e0a

[Rubix982]

Thanks for sharing your stack trace! I was using DotTrace, and I noticed that all the UI freezes were being led on from native/system level code, particularly calls to FPushMessageLoop. I believe the issue is related to threading and overloading the process' resources.

I think I'm going to get the latest cefsharp and libcef versions to make sure this breaking change can go away. If it fails, I'll think I'll look into the code myself in the upcoming weekend because my product has a demo on Monday. 😭

[JScheitelBEPC]

BTW - what they said above about controlling the order that they get initialized - that worked for me to get our app back in service until an updated CefSharp is released.

[Rubix982]

Interesting. Our application is very vast and various flows for visualization in WinForms that use CefSharp, would take some time to do.

Also, I see that Alex is working on this issue as we speak, a66c360, so I hope this issue gets resolved quickly.

[ralish]

We first saw this issue around February 5th on one of our software products and the symptoms are exactly as described.

A few notes that may help from our own investigation:

• We first saw the issue with the release of Edge WebView2 v121.0.2277.98 (released Feb 1st, 2024)
• The immediately prior 120.x series release is not affected: v120.0.2210.167 (released Jan 31, 2024)
• I don't believe we tested on the only earlier 121.x series release: v121.0.2277.83 (released Jan 25th, 2024)

Running CEF v109.1.11+g6d4fdb2+chromium-109.0.5414.87 the full stack trace of the crashing thread with symbols:

Call Site
libcef!base::ImmediateCrash [Y:\work\CEF3_git\chromium\src\base\immediate_crash.h @ 144] 
libcef!logging::LogMessage::~LogMessage+0x521 [Y:\work\CEF3_git\chromium\src\base\logging.cc @ 938] 
libcef!gfx::`anonymous namespace'::CrashOther+0x5f [Y:\work\CEF3_git\chromium\src\ui\gfx\win\hwnd_util.cc @ 65] 
libcef!gfx::CheckWindowCreated+0xa2 [Y:\work\CEF3_git\chromium\src\ui\gfx\win\hwnd_util.cc @ 226] 
libcef!gfx::WindowImpl::Init+0x213 [Y:\work\CEF3_git\chromium\src\ui\gfx\win\window_impl.cc @ 251] 
libcef!views::HWNDMessageHandler::Init+0x11d [Y:\work\CEF3_git\chromium\src\ui\views\win\hwnd_message_handler.cc @ 456] 
libcef!views::DesktopWindowTreeHostWin::Init+0x1cc [Y:\work\CEF3_git\chromium\src\ui\views\widget\desktop_aura\desktop_window_tree_host_win.cc @ 209] 
libcef!views::DesktopNativeWidgetAura::InitNativeWidget+0x1f1 [Y:\work\CEF3_git\chromium\src\ui\views\widget\desktop_aura\desktop_native_widget_aura.cc @ 575] 
libcef!views::Widget::Init+0x961 [Y:\work\CEF3_git\chromium\src\ui\views\widget\widget.cc @ 442] 
libcef!CefWindowDelegateView::Init+0x15a [Y:\work\CEF3_git\chromium\src\cef\libcef\browser\native\window_delegate_view.cc @ 67] 
libcef!CefBrowserPlatformDelegateNativeWin::CreateHostWindow+0x4f8 [Y:\work\CEF3_git\chromium\src\cef\libcef\browser\native\browser_platform_delegate_native_win.cc @ 286] 
libcef!AlloyBrowserHostImpl::CreateHostWindow+0x20 [Y:\work\CEF3_git\chromium\src\cef\libcef\browser\alloy\alloy_browser_host_impl.cc @ 1451] 
libcef!AlloyBrowserHostImpl::CreateInternal+0x225 [Y:\work\CEF3_git\chromium\src\cef\libcef\browser\alloy\alloy_browser_host_impl.cc @ 196] 
libcef!AlloyBrowserHostImpl::Create+0x344 [Y:\work\CEF3_git\chromium\src\cef\libcef\browser\alloy\alloy_browser_host_impl.cc @ 133] 
libcef!CefBrowserHostBase::Create+0x6e [Y:\work\CEF3_git\chromium\src\cef\libcef\browser\browser_host_create.cc @ 172] 
libcef!CefBrowserHost::CreateBrowserSync+0x3bd [Y:\work\CEF3_git\chromium\src\cef\libcef\browser\browser_host_create.cc @ 149] 
libcef!`anonymous namespace'::CreateBrowserHelper::Run+0xc4 [Y:\work\CEF3_git\chromium\src\cef\libcef\browser\browser_host_create.cc @ 32] 
libcef!base::OnceCallback<void ()>::Run+0x19 [Y:\work\CEF3_git\chromium\src\base\functional\callback.h @ 174] 
libcef!base::TaskAnnotator::RunTaskImpl+0x180 [Y:\work\CEF3_git\chromium\src\base\task\common\task_annotator.cc @ 155] 
libcef!base::TaskAnnotator::RunTask+0x25 [Y:\work\CEF3_git\chromium\src\base\task\common\task_annotator.h @ 84] 
libcef!base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl+0x405 [Y:\work\CEF3_git\chromium\src\base\task\sequence_manager\thread_controller_with_message_pump_impl.cc @ 449] 
libcef!base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork+0x4aa [Y:\work\CEF3_git\chromium\src\base\task\sequence_manager\thread_controller_with_message_pump_impl.cc @ 300] 
libcef!base::MessagePumpForUI::DoRunLoop+0x229 [Y:\work\CEF3_git\chromium\src\base\message_loop\message_pump_win.cc @ 216] 
libcef!base::MessagePumpWin::Run+0x75 [Y:\work\CEF3_git\chromium\src\base\message_loop\message_pump_win.cc @ 80] 
libcef!base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run+0xd5 [Y:\work\CEF3_git\chromium\src\base\task\sequence_manager\thread_controller_with_message_pump_impl.cc @ 612] 
libcef!base::RunLoop::Run+0xde [Y:\work\CEF3_git\chromium\src\base\run_loop.cc @ 143] 
libcef!CefMainRunner::RunMessageLoop+0x85 [Y:\work\CEF3_git\chromium\src\cef\libcef\browser\main_runner.cc @ 281] 
libcef!CefUIThread::ThreadMain+0x10e [Y:\work\CEF3_git\chromium\src\cef\libcef\browser\main_runner.cc @ 176] 
libcef!base::`anonymous namespace'::ThreadFunc+0x110 [Y:\work\CEF3_git\chromium\src\base\threading\platform_thread_win.cc @ 127] 
KERNEL32!BaseThreadInitThunk+0x1d
ntdll!RtlUserThreadStart+0x28

Immediately prior to the crash you can see the following log output:
[0211/101116.724:FATAL:hwnd_util.cc(64)] 1400

1400 as a decimal Windows error code has the symbolic value ERROR_INVALID_WINDOW_HANDLE, which seems relevant given the window initialisation code near the top of the stack and immediately prior to the crash.

That's about where we got to before we switched focus to implementing a workaround versus determining the root cause, but maybe it's of help to others pursuing this issue.

[amaitland]

Immediately prior to the crash you can see the following log output:
[0211/101116.724:FATAL:hwnd_util.cc(64)] 1400

The CreateWindowEx called resulted in an error. https://source.chromium.org/chromium/chromium/src/+/main:ui/gfx/win/window_impl.cc;l=219;drc=7025c360a96319db787feb39a64f3a490e710bfe;bpv=1;bpt=1

As the change in behaviour appears to originate from WebView2 which is closed source, someone will need to convince the MS devs to investigate further. (This issue also isn't CefSharp specific as stated above).

[Rubix982]

To add, I also get hwnd_util.cc(64)] 1400.

[Rubix982]

@amaitland, the latest stable release, 121.3.70, resolves my issue! I have to thank you a lot for resolving this gigantic issue. The new release works in my case and is no longer crashing my application.

[JScheitelBEPC]

121.3.70 resolved my issue as well, thank you so much for your hard work @amaitland !