CefSharp/Cef libcef.dll stack overflow (0xC00000FD)

Question

CefSharp Winforms Version 43.0.0.0, libcef.dll 3.2357.1287.

When selecting text in a text box, and then hitting a key on the on screen keyboard (does not happen on the normal keyboard), I sometimes get a stack overflow in libcef.dll.

I am ripping my hair out trying to isolate the cause. One thing that is slowing me down is the inability to connect a proper pdb file to the dll. Despite downloading all variations of it from CefBuilds.

I have various crash dumps, and was wondering if anybody else has had experience troubleshooting this kind of thing. WinDBG may as well be chinese, with DebugDiag being much easier to follow, but without the valid pdb file neither are any use at all.

I cannot recreate the issue in the winform example application, so its definitely local to us, so I am currently ripping code out left right and center to isolate the cause, but would really appreciate some guidance on how to load the pdb file into debugdiag to stop this:

Despite this:

libcef.dll version:

For anyone interested, this is the current crashing thread's stack trace:

... and on and on and on...

I guess the main question is does anybody know what could be causing the stack overflow? (This problem existed in 41.0.0 in the winform example application, now it only exists within our own application in 43.0.0).

With a secondary question of why aren't the pdb files loading in debugdiag.

Edit. I am compiling in 32bit, and it appears there is no pdb file for the 32 bit edition of libcef.dll v3.2357.1287. In fact, according to cefbuilds.com this file does not exist.

Answer 1

It appeared that although I couldn't re-create the issue using the winform example's main form, I could whilst using its SimpleBrowserForm.cs.

This allowed me to compare the different implementations.

In the main form, once the browser control is initialised, a hacky message loop interceptor is created, to pass internal WM_MOUSEACTIVATE events up to the parent container. This appears to be an effort to ensure that if a context menu is open at the time the click is received, it will be closed by the click event (chromium suppresses internal mouse clicks it seems).

private void OnIsBrowserInitializedChanged(object sender, IsBrowserInitializedChangedEventArgs args)
    {
        if (args.IsBrowserInitialized)
        {
            ChromeWidgetMessageInterceptor.SetupLoop((ChromiumWebBrowser)Browser, (message) =>
            {
                const int WM_MOUSEACTIVATE = 0x0021;
                const int WM_NCLBUTTONDOWN = 0x00A1;

                if (message.Msg == WM_MOUSEACTIVATE) {
                    // The default processing of WM_MOUSEACTIVATE results in MA_NOACTIVATE,
                    // and the subsequent mouse click is eaten by Chrome.
                    // This means any .NET ToolStrip or ContextMenuStrip does not get closed.
                    // By posting a WM_NCLBUTTONDOWN message to a harmless co-ordinate of the
                    // top-level window, we rely on the ToolStripManager's message handling
                    // to close any open dropdowns:
                    // http://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/ToolStripManager.cs,1249
                    var topLevelWindowHandle = message.WParam;
                    PostMessage(topLevelWindowHandle, WM_NCLBUTTONDOWN, IntPtr.Zero, IntPtr.Zero);
                }
            });
        }
    }

Anyway, with this weird little hack in place, my stack overflow crash goes away.

I have raised a github ticket to try get the underlying issue resolved, but for now this is preventing the issue.