CefSharp.BrowserSubProcess.Core WCF pipe failure on certain workstations

[anthonydoy]

Hello, I am looking for some advice on how to troubleshoot this issue.

Our application is using CefSharp version 73.1.130. The issue only occurs on a small number of internal workstations within our organization. Worth noting, we are also seeing the same error with CefSharp version 92. Another strange thing is that it the issue is consistent, but only when the web apps are launched through certain navigations. Other navigations work consistently for these users.

We use RegisterJsObject to register a javascript object with browser. If I understand correctly, asynchronous binding is preferred moving forward.

The issue presents as strange/unexpected behavior in the hosted web application due to failure to retrieve context from the host WinForms application. The behavior would suggest a failure to register/bind the js object with the RegisterJsObject method. However, that method is not throwing an exception.

Enabled Cef logging showed the following error:

ERROR:JavascriptRootObjectWrapper.cpp(34)] IBrowserProcess is null, unable to bind object

After looking into the code, it appears the location that the value pointed to by "IBrowserProcess" is set is in WcfEnabledSubProcess::OnBrowserCreated (https://github.com/cefsharp/CefSharp/blob/cefsharp/73/CefSharp.BrowserSubprocess.Core/WcfEnabledSubProcess.cpp). I was able to build CefSharp and add additional logging to that method.

On my workstation (I'm not affected by the issue), I get through OnBrowserCreated with no exceptions. However, on my coworkers workstation I see the following line is failing:

       channelFactory->Open();

        auto browserProcess = channelFactory->CreateChannel();
        auto clientChannel = ((IClientChannel^)browserProcess);

        try
        {
            clientChannel->Open();   <-- FAILS

            browser->ChannelFactory = channelFactory;
            browser->BrowserProcess = browserProcess;
        }
        catch (Exception^)
        {
        }
    }

`

With the error:

There was an error reading from the pipe: The pipe has been ended. (109, 0x6d)

Has anyone seen this issue before? I'm not sure how much this will help, but does anyone know if it's possible to enable WCF tracing with the CefSharp.BrowserSubProcess.exe? I was told this may be similar to #915 and to run our app as an admin on the problem workstation to troubleshoot, however this causes issues for our application as it is not meant to be launched with admin privileges. I'm just looking for any advice on how to pinpoint the workstation issue. Thanks!

[amaitland]

Issue #915 is the only one that I recall, sounds like exactly the same behaviour. That's where I'd start, see if there's another application running that uses WCF NetNamedPipeBinding.

[anthonydoy]

Thanks @amaitland! I tried using the following code to identify WCF services running on my coworker's workstation and my own workstation. Unfortunately, the list of WCF services matched. Do you know of a better way to identify WCF NetNamedPipeBinding running on a workstation?

var category = new PerformanceCounterCategory("ServiceModelService 4.0.0.0", Environment.MachineName);
var instances = category.GetInstanceNames();
foreach (var instance in instances)
{
    Console.WriteLine(instance);
}

[amaitland]

I don't recall specifically, was a long long time ago. If you've read #915 and all the linked articles then you should have all the information available at the time. Fire up your favourite search engine and see suggestions others have.

My advice would be to run through all the standard debugging things. Compare list of installed programs, disable antivirus, check event logs, create an isolated demo and seeing if running as admin fixes the problem as originally reported. There are utilities for viewing what named pipes are currently active, one of those might be worth a try.

You can also build CefSharp from source and add extra logging if you need to.

It's possible the issue you are seeing is unrelated to #915. To me it sounds the same and that's the only issue I recall.