Browser subprocess crashes on startup due to invalid handle

[danpaul88]

In the process of upgrading an older project to the newest version of CefSharp I've run into a bit of a roadblock - the CefSharp.BrowserSubprocess process is crashing almost immediately upon startup with an invalid handle exception. From EventViewer;

Application: CefSharp.BrowserSubprocess.exe
CoreCLR Version: 7.0.323.6910
.NET Version: 7.0.3
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.IOException: The handle is invalid.
   at System.ConsolePal.SetConsoleOutputEncoding(Encoding enc)
   at System.Console.set_OutputEncoding(Encoding value)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)

A bit stumped as to what is causing this - any ideas? For reference the hosting application is net6.0-windows and it's just creating an instance of the WPF control ChromiumWebBrowser.

<UserControl
	x:Class="MyNamespace.CefWebHostView"
	xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
	xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
	xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
	xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
	xmlns:cef="clr-namespace:CefSharp.Wpf;assembly=CefSharp.Wpf"
	xmlns:local="clr-namespace:MyNamespace.Cef"
	mc:Ignorable="d">

	<d:UserControl.DataContext>
		<x:Type Type="local:CefWebHostViewModel" />
	</d:UserControl.DataContext>

	<Grid>
		<cef:ChromiumWebBrowser
			Address="{Binding Address, Mode=TwoWay}"
			Title="{Binding PageTitle, Mode=OneWayToSource}"
			AllowDrop="True"
			WebBrowser="{Binding WebBrowser, Mode=OneWayToSource}"
			DataContext="{Binding}"  />
	</Grid>

</UserControl>

[amaitland]

The CefSharp.BrowserSubprocess.exe shipped is actually a .Net Core 3.1 executable, generally it should RollForward and run on newer runtimes. Your application is targeting .Net 6.0, the exception seems to be trying to run the exe using 7.0. Using the Windows 10 Sandbox testing with clean .Net 6 and .Net 7.0 installs both work as expected. I'd need additional information to know what's going on.

Self Hosting the BrowserSubProcess is an alternative, allowing you to match the same runtime as your application is built. There are quite a few examples of how to implement this here on GitHub issues/discussions.

WPF is a little more complex than WinForms, not particularly difficult. To make this easier to find I've created a new set of instructions for Self Hosting at https://github.com/cefsharp/CefSharp/wiki/SelfHost-BrowserSubProcess

Please try the instructions out and report back.

Generic references:

• https://blog.magnusmontin.net/2020/01/31/custom-entry-point-wpf-net-core/#:~:text=To%20create%20a%20custom%20entry,with%20a%20static%20Main%20method.
• https://stackoverflow.com/a/14903778/4583726

[danpaul88]

Fair enough hiding the post, I simply shared it as a solution to the issue I was having with it. Didn't find any WPF examples when I searched but possibly didn't hit on the right combination of search terms as I was mainly looking for an answer to the crashing issue.

FWIW it does seem to work fine - it doesn't actually create any visible window because it blocks in OnStartup until the browser subprocess returns and then immediately shuts down the WPF application, so I'm not sure it would have actually created the message loop at that point, but it did seem inefficient if nothing else to have all the WPF overhead spinning up for no reason.

I'll have a look at the updated instructions in the next few days and get back to you 👍

[amaitland]

I was mainly looking for an answer to the crashing issue.

I've not seen that particular crash before, I'd need an example that reproduces the problem to know what's going on.

FWIW it does seem to work fine

I still wouldn't recommend it

so I'm not sure it would have actually created the message loop at that point

The Application.Run documentation has an example of providing your own entry point. If you look in your obj folder for a file called something like App.g.cs you can see the generated code for the default entry point.

When Run is called, Application attaches a new Dispatcher instance to the UI thread. Next, the Dispatcher object's Run method is called, which starts a message pump to process windows messages. Finally, the Dispatcher object calls the Application object's the OnStartup method to raise the Startup event. Consequently, the application execution model has been established by the time you handle Startup, at which point the application is considered to be running.

Excerpt from Remarks section of https://learn.microsoft.com/en-us/dotnet/api/system.windows.application.run?view=windowsdesktop-7.0#system-windows-application-run

See also https://github.com/dotnet/wpf/blob/release/6.0/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Application.cs#L147

I believe you'd be blocking the dispatcher (message loop) at this point in the applications execution.

[danpaul88]

I believe you'd be blocking the dispatcher (message loop) at this point in the applications execution.

Oh definitely, but as I didn't need the dispatcher to do anything else that didn't matter at the time -was just throwing together a bare bones make-it-work solution to meet a tight deadline. As I alluded to in my original answer, I'm well aware it's not the best way to do it, but it did work for me with the time constraints I had on the day.

Thanks for the link to the remarks though, I had intended to go look that up at some point as it's always handy to know what's going on under the hood and I've never had cause to dig into how Application works before now.

I've not seen that particular crash before, I'd need an example that reproduces the problem to know what's going on.

I'll try to put a repro together at some point, but it's likely related to the way we're running the WPF app that contains the CefSharp control, which is within a WPF app whose window has been setup as a child window of a control within another WPF app (long story!). So while the app itself is very simple (just a CefSharp browser control in a window) the overall environment within its window exists is likely causing an unusual problem for the browser subprocess.

That said, we run a lot of apps in this same environment and this is the first time we've come across such an issue, so if I can distil the guts of what's going on into a small repro case I'll let you know.