Multiple AppDomains error "Cannot pass a GCHandle across AppDomains".

[brock8503]

Hey team,

I recently stumbled upon this pretty nasty gotcha when trying to host our browser control inside a plugin system that loads a new AppDomains per plugin. When the native libcef.dll makes a call back into managed there is an exception thrown "Cannot pass a GCHandle across AppDomains".

I found that there have been several post written about this problem-
http://lambert.geek.nz/2007/05/29/unmanaged-appdomain-callback/
http://www.lenholgate.com/blog/2009/07/error-cannot-pass-a-gchandle-across-appdomains.html

Highlight from these posts-
"Consequently, when calling managed code from unmanaged code, the compiler has to pick one AppDomain to use, and it appears to pick the first one."

To test this issue

• Create a new WPF application
• Change App.xaml Build Action to Page (right-click Properties->Build Action->Page)
• Add file below with main - Startup.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using CefSharp;

namespace MultipleAppDomains
{
    class Startup
    {
        [STAThread()]
        static void Main()
        {
            AppDomain domain = AppDomain.CreateDomain("another domain");
            CrossAppDomainDelegate action = () =>
            {
                var settings = new CefSettings
                {
                    RemoteDebuggingPort = 8088,
                    BrowserSubprocessPath = "CefSharp.BrowserSubprocess.exe",
                    LogSeverity = LogSeverity.Verbose

                };

                if (!Cef.Initialize(settings))
                {
                    // Do Something
                }
                App app = new App();
                app.MainWindow = new MainWindow();
                app.MainWindow.Show();
                app.Run();
            };
            domain.DoCallBack(action);
        }
    }
}

I'd like to get the discussion going and come up with a good course of action.

[jornh]

@brock8503 I guess we have found another place where this now bites us: #366. So now we may have to pay more attention to your request for discussion 😜

In the time since you posted did you get any wiser on how to resolve or workarond this on your own?

[brock8503]

@jornh Looks like you stumbled upon the exact error that a few others did with xunit. It was mentioned in the sources above.

In my mind we need to revisit libcef_wrapper and probably create a new native-manage wrapper with the thunk layer proposed in the above articles. Or for every callback we will need to add the thunk redesign in cefsharp.dll.

I am curious in studying how the c# interop marshaling handles this.

[brock8503]

@jornh @perlun Sorry for going dark the last month, lots of code to ship on our end. Did we make any progress on this issue or is it something we still are looking to fix?

[jornh]

@brock8503 no problem! Of course you need to work on what pays your bills 😄 Great to see you around again though!

If it makes you feel any better I don't think any one else had any progress on this one either. We are currently trying to see if we can polish things enough up to take off the -pre label. So it's still on the todo.

[herebebeasties]

See also #248 by @joaompneves for the CEF1 branch, which was deemed a little over-intrusive. Might be portable to CEF3?

[msiddiqi]

I see the same issue :(