WinForms Example CloseChannel Exception

[rcha86]

I'm using CefSharp.39.0.0-pre03. When I run the WinForms Example in Release mode from Visual Studio, more than half the time when I close a tab or even the entire application, I see an exception in BrowserProcessServiceHost.CloseChannel. If launch the EXE from the command line, it shuts down just fine.

The stack trace is as follows:

at System.ServiceModel.Channels.PipeConnection.WriteHelper(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout, Object& holder)
   at System.ServiceModel.Channels.PipeConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
   at System.ServiceModel.Channels.BufferedConnection.WriteNow(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout, BufferManager bufferManager)
   at System.ServiceModel.Channels.BufferedConnection.WriteNow(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout)
   at System.ServiceModel.Channels.BufferedConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
   at System.ServiceModel.Channels.FramingDuplexSessionChannel.CloseOutputSessionCore(TimeSpan timeout)
   at System.ServiceModel.Channels.TransportDuplexSessionChannel.CloseOutputSession(TimeSpan timeout)
   at System.ServiceModel.Channels.TransportDuplexSessionChannel.OnClose(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.OnClose(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Close()

Should I worry about this? It is surrounded with a try-catch block, but is there a better solution?

I am using CefSharp in an ActiveX control (I know. Shoot me, right?). With the ActiveX control, on shutdown, I see a similar communication error when the ActiveX control tries to Dispose itself. The ActiveX process does not close and the BrowserSubprocess for the GPU does not shutdown. I have included a try-catch block as well, but it does not seem to fix the issue. Any thoughts? I'm guessing that it has to do with how the ActiveX shuts down and Internet Explorer closes.

Thanks for the help!

[amaitland]

I'm using CefSharp.39.0.0-pre03. When I run the WinForms Example in Release mode from Visual Studio, more than half the time when I close a tab or even the entire application, I see an exception in BrowserProcessServiceHost.CloseChannel.

Can you provide a detailed list of steps to reproduce? I've built in Release mode, opened and closed 10 times without a problem.

[amaitland]

FYI I marked up your stack trace slightly differently, makes it easier to read. (If you click edit you can see the change I made).

[amaitland]

@rcha86 Any more info you can provide?

[rcha86]

Sorry for the delayed response.

Here are the steps I take to reproduce the issue in Visual Studio.

1. Set the build mode to Release.
2. Right-click on the WinForms.Example project and select Debug -> Start new instance.
3. Open a new tab in the WinForms.Example application.
4. Close the tab you created.

When I see the issue, the application hangs for a few seconds and then there is an exception in BrowserProcessServiceHost.CloseChannel(). The try-catch takes cares of this, but I'm wondering if this is something to worry about. It seems to cause problems for my ActiveX control.

I have since then tried a few things. If I use CefSharp 37.0.0 with CEF 2086.1898, I do NOT see this issue. If I use CefSharp 39.0.0-pre03 with CEF 2086.1898, then I also do NOT see this issue. In both cases, the ActiveX control I have built shuts down without issue. I think there might be some issue with CEF 2171.1979 and CefSharp combination.

[rassilon]

Have you triple checked what thread you create the ActiveX control on? You don't mention what kinds of problems it causes for your ActiveX control. That might help diagnose the problem.

Some of CEF's threads should NEVER have COM objects created on them since they don't pump COM messages.

For example, I needed to play MP3 files with CefSharp.

So I hooked up a SchemeHandler that would create Windows Core Audio COM objects via help from the NAudio project's C# code.

However, if I created the COM object on CEF's IO thread then the program would hang during shutdown because the finalizer of the COM object's RCW (.Net's COM helper object) would block forever on sending a COM message to CEF's IO thread. (Which, unsurprisingly doesn't pump COM messages.)

So, instead I now deal with audio on .Net's thread pool by utilizing the Task class.

Bill

[jankurianski]

So I hooked up a SchemeHandler that would create Windows Core Audio COM objects via help from the NAudio project's C# code.

However, if I created the COM object on CEF's IO thread then the program would hang during shutdown because the finalizer of the COM object's RCW (.Net's COM helper object) would block forever on sending a COM message to CEF's IO thread. (Which, unsurprisingly doesn't pump COM messages.)

Thanks a bunch for sharing this fascinating detail, Bill! 👍

I'm currently experiencing a shutdown hang, but only after ~50 minutes of functional tests in my process, so it's hard to debug. Did you find your error on a hunch, or did you find a way to get the debugger to break during shutdown? VS2012 freezes if I break or 'step over' the last line of my C#'s static void Main() function.

[rassilon]

I used the WinDbg extension sosex from https://www.stevestechspot.com/. One of it's commands is (!rcw if I recall correctly) tells you what RCWs exist, and what their owning .Net object is. Another WinDbg extension command lets you dump the details about the owning object and it was obviously one of the NAudio wrapping objects.

What would happen went something like this:

• Cef.Shutdown() calls GC.WaitForPendingFinalizers (pretend I got the method name right)
• The program hung because the .Net finalizer thread got infinitely blocked on the RCW releasing the COM reference to the Core Audio object.
• I determined it was the Core Audio object via the bit above in the first paragraph.

So, if you app is hanging at shutdown, see what the callstack of the finalizer thread looks like, it might be blocked on releasing that RCW's COM object.

Bill

[amaitland]

Worth creating item 10 in the FAQ? I think this is a nasty gotcha and worth having some official documentation about.

[amaitland]

Anything further before closing this?