WPF crashes in combination with TeamViewer (and hardware acceleration) starting v136

[Mik4sa]

Is there an existing issue for this?

• I have searched both open/closed issues, no issue already exists.

CefSharp Version

138.0.170

Operating System

Windows Server 2016

Architecture

x64

.Net Version

.NET 4.7.2 / .NET 4.8

Implementation

WPF

Reproduction Steps

This is reproducible with the MinimalExample for v138: https://github.com/cefsharp/CefSharp.MinimalExample/tree/b0ef1b1e4a1d6bfa60cf3d0eab851f590440941a
Note: You have to use the example for Wpf (Wpf.HwndHost is also crashing). WinForms is not crashing.

This is also reproducible with the default Visual Studio template of a wpf application and just adding the default ChromiumWebBrowser (from CefSharp)

<Window x:Class="CefSharpWpfTeamViewer.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:local="clr-namespace:CefSharpWpfTeamViewer"
        xmlns:wpf="clr-namespace:CefSharp.Wpf;assembly=CefSharp.Wpf"
        mc:Ignorable="d"
        Title="MainWindow" Height="450" Width="800">
    <Grid>
        <Border Grid.Row="1" BorderBrush="Gray" BorderThickness="0,1">
            <wpf:ChromiumWebBrowser x:Name="Browser" Address="www.google.com"/>
        </Border>
    </Grid>
</Window>

---

This was also reprocued on Windows Server 2019. I wasn't able to reproduce it on Windows 11. Other systems were not tested.
Note: The client in all tests was always a Windows 11 machine. The server systems (2016 and 2019) were hosted in a virtual machine. The other Windows 11 system was a physical one.

Expected behavior

The application should not crash when working remote with TeamViewer.

Actual behavior

Some of our customers use our application while being connected with TeamViewer. When starting the minimal example for example it's instantly crashing.
Being connected over RDP the minimal example is not crashing and everything works normaly. Once we switch over to TeamViewer (while the application is still opened) the minimal example is crashing again, instantly.

IMO there are no relevant errors or anything similar. More details in "other information".

Regression?

This worked until v135. Starting with v136 the application is crashing.

Known Workarounds

The only thing that helped was disabling the hardware acceleration of WPF (being it by a global registry key or inside our application)

• https://stackoverflow.com/a/2169657
• https://stackoverflow.com/a/10087146

While this works this is no solution for us/our customers.
Note: Disabling the hardware acceleration in TeamViewer doesn't solve anything. The app is still crashing.

Does this problem also occur in the CEF Sample Application

No

Other information

Before I'm going into detail: I wasn't able to reproduce it with the cefclient. Trying on Windows Server 2016 the following versions were generally crashing (while being connected over RDP, TeamViewer wasn't involved there):

• cef_binary_135.0.22+g442c600+chromium-135.0.7049.115_windows64_client
• cef_binary_136.1.6+g1ac1b14+chromium-136.0.7103.114_windows64_client

The version cef_binary_138.0.17+gac9b751+chromium-138.0.7204.97_windows64_client (which is used in v138 from CefSharp) was starting again on Windows Server 2016, but I was never able to reproduce the behaviour in combination with TeamViewer.
So my guess is thats a combination of CefSharp v136, WPF (with enabled hardware acceleration (default)) and TeamViewer.

---

While digging into this problem / crash we could see that our application (and the samples here) crash once TeamViewer gets involed. When TeamViewer is "activated" it's injecting a dll (tv_x64.dll) into our application which results in the same moment into a crash. A crash which we can't handle. We guess that TeamViewer has to inject there own dlls to make the things like remote control work in general.

While troubleshooting and searching the web we found other error reports which showed that TeamViewer makes sometimes trouble, just in the way it works (injecting .dlls in our application for example). These reports are quite old though, nothing new sadly.

• https://stackoverflow.com/a/72205291
• https://teamviewerforums.com/index.php?topic=3959.0

While I think that the actual problem lies in TeamViewer itself and should be fixed there I'm wondering if there is something that we can fix on the CefSharp or even CEF side. And the fact that this problem is likely to be very old and known to TeamViewer leads me to believe that TeamViewer will not provide any help or solution.

Some more details:
The debug.log content from minimal example:

[0731/121145.332:INFO:cef\libcef\common\crash_reporting.cc:209] Crash reporting enabled for process: browser
[0731/121145.441:INFO:cef\libcef\common\crash_reporting.cc:209] Crash reporting enabled for process: gpu-process
[0731/121145.457:INFO:cef\libcef\common\crash_reporting.cc:209] Crash reporting enabled for process: utility
[0731/121145.457:INFO:cef\libcef\common\crash_reporting.cc:209] Crash reporting enabled for process: utility
[0731/121145.582:INFO:cef\libcef\common\crash_reporting.cc:209] Crash reporting enabled for process: gpu-process
[0731/121145.644:INFO:cef\libcef\common\crash_reporting.cc:209] Crash reporting enabled for process: renderer
[0731/121145.660:INFO:cef\libcef\common\crash_reporting.cc:209] Crash reporting enabled for process: renderer

The crash of the minimal example isn't resulting in any entries in the event viewer of Windows. But my test app is:

[amaitland]

Note: You have to use the example for Wpf (Wpf.HwndHost is also crashing). WinForms is not crashing.

This is odd given that HwndHost uses the same browser implementation as WinForms.

Before I'm going into detail: I wasn't able to reproduce it with the cefclient.

What command line args did you use to test cefclient with?

So my guess is thats a combination of CefSharp v136, WPF (with enabled hardware acceleration (default)) and TeamViewer.

136 was a very minor upgrade, really not much other than upgrading to the latest version at the time.

v135.0.220...v136.1.40

You can Git bisect to see exactly which commit broke, I suspect it was the one upgrading CEF.

While I think that the actual problem lies in TeamViewer itself and should be fixed there I'm wondering if there is something that we can fix on the CefSharp or even CEF side.

I don't have Sever 2016 instance (or any server instance currently) or a TeamViewer license. You or someone from the community would need to debug.

The crash of the minimal example isn't resulting in any entries in the event viewer of Windows.

If it crashed then the crash reporting should have created a dmp.

https://github.com/cefsharp/CefSharp/wiki/Trouble-Shooting#crash-reporting

https://github.com/cefsharp/CefSharp/wiki/Trouble-Shooting#loading-native-symbols-for-easier-diagnosis

You need to get a call stack of the crash to know more.

But my test app is:

I don't speak German (I'm guessing it's German from the image). Please provide text instead of images of errors/exceptions. See https://idownvotedbecau.se/imageofanexception/