App crash when using WebRTC after 40 sec (Custom build)

[akhudairy]

We have a custom .Net desktop app that uses CefSharp. But we replace the chromium dlls provided in nuget with our own custom build to add MP4 support. In our app we use WebRTC with a bit help of .Net SignalR to create one to one video calls. When we use the original chromium dlls the call is established and all is good, but once we use our custom built dlls the call is established at first but then after 30-40 seconds white screen appears and we see the following error in event viewer/Windows logs/Application

Faulting application name: CefSharp.BrowserSubprocess.exe, version: 84.4.10.0, time stamp: 0x5f45f0d1
Faulting module name: libcef.dll, version: 84.4.1.0, time stamp: 0x5f1b375b
Exception code: 0x4000001f
Fault offset: 0x02c34080
Faulting process id: 0x4604
Faulting application start time: 0x01d6d156a204962e
Faulting application path: C:\SSCollection\SelfService\SelfService\SelfServicePackage\KioskApplication\CefSharp.BrowserSubprocess.exe
Faulting module path: C:\SSCollection\SelfService\SelfService\SelfServicePackage\KioskApplication\libcef.dll
Report Id: 8996b665-1874-479e-a097-346b97cf86ff
Faulting package full name:
Faulting package-relative application ID:

We also see this warning in Event Viewer just before it
Unable to open the job object \BaseNamedObjects\WmiProviderSubSystemHostJob for query access. The calling process may not have permission to open this job. The first four bytes (DWORD) of the Data section contains the status code.


-----------------------------------------------------------------------------------------------------------------
More information:
We use chromium 84.4.1
Branch 4147

We used the following to update the code \code\chromium_git\update.bat
set GN_DEFINES=is_official_build=true proprietary_codecs=1 ffmpeg_branding=Chrome symbol_level=2 enable_precompiled_headers=false
set GN_ARGUMENTS=--ide=vs2019 --sln=cef --filters=//cef/*
python ..\automate\automate-git.py --download-dir=d:\code\chromium_git --branch=4147 --depot-tools-dir=d:\code\depot_tools --no-distrib --no-build

We used the following to run the build \code\chromium_git\chromium\src\cef\create.bat
set CEF_USE_GN=1
set GN_DEFINES= proprietary_codecs=true is_official_build=true ffmpeg_branding=Chrome symbol_level=2 enable_precompiled_headers=false
set GN_ARGUMENTS=--ide=vs2019 --sln=cef --filters=//cef/*
call cef_create_projects.bat

Operating System:
Windows 10 64 bit

After build we get the following files and folders from \chromium\src\out\Debug_GN_x86 (our app is 32 bit)
locales
swiftshader
cef.pak
cef_100_percent.pak
cef_200_percent.pak
cef_extensions.pak
chrome_elf.dll
d3dcompiler_47.dll
devtools_resources.pak
icudtl.dat
libcef.dll
libEGL.dll
libGLESv2.dll
snapshot_blob.bin
v8_context_snapshot.bin

[magreenblatt]

What is the symbolized call stack for the crash? Try using Release binaries instead of Debug.

[akhudairy]

What is the symbolized call stack for the crash? Try using Release binaries instead of Debug.

Hi magreenblatt. Thanks for your hints.
I wasn't sure how to find symbolized call stack, and also am not sure how to do the build to get the release binaries. I did some search and didn't find clear documentation on that.


However, I was able now to test using CefClient.exe, and the problem didn't happen. So somehow it seems related to the CefSharp Wrapper, or maybe to the argument flags we pass. It is also clear for us now that the problem only happens when we transmit the video, but we tried audio only and it didn't crash.

I will post an update here if we solve the issue.

[amaitland]

As the binaries included with `CefSharp` work as expected it's unlikely a bug in `CefSharp. I'd strongly recommend you build a `Release` version and use that rather than a debug build.

`CefSharp` is distributed with builds that come from https://cef-builds.spotifycdn.com/index.html#windows32

Use the settings listed at https://bitbucket.org/chromiumembedded/ ... figuration to build an official release.

[akhudairy]

As the binaries included with `CefSharp` work as expected it's unlikely a bug in `CefSharp. I'd strongly recommend you build a `Release` version and use that rather than a debug build.

`CefSharp` is distributed with builds that come from https://cef-builds.spotifycdn.com/index.html#windows32

Use the settings listed at https://bitbucket.org/chromiumembedded/ ... figuration to build an official release.

Yes I agree with you. After more investigation. We noticed this only happens when we use Camera stream, while using audio stream doesn't break. The other issue, is that we have multiple instances of CefSharp Browser (and we do apply the recommendations regarding having multiple instances) .. So when the call happens using a certain instance it breaks after 20-40 seconds, but using the other instance works. We have been trying to analyse and check what is different, like which thread is initializing the instance, and which thread is sending the load url command, but we couldn't spot what difference is causing the issue.

If we find this, I will update this log for the record.

[amaitland]

Have you tested with a release build yet?

[akhudairy]

Have you tested with a release build yet?

Hi. If you mean a release build of CefSharp, we do use a release build of CefSharp. But as for cef, I couldn't find how to build it in release mode and still include the codec support.

I am following the steps in https://bitbucket.org/chromiumembedded/ ... ckStart.md

I am not sure if it is about changing this command (ninja -C out\Debug_GN_x86 cef) with somthing like (ninja -C out\Release_GN_x86 cef) .. but strange enough while the first one worked fine, the second one keeps giving me lots of errors like

C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt\corecrt.h(10,10): fatal error: 'vcruntime.h' file not found
#include <vcruntime.h>
^~~~~~~~~~~~~
1 error generated.

Ofcourse I do have the correct Windows Kit version for CEF 84, which is Win 10.0.18362 SDK .. I am assuming since debug build worked fine.


---
Update 3/Jan/2020
Okays so I think my conclusion was right about how to build release, using (ninja -C out\Release_GN_x86 cef) and although it might be obvious, I think it would have been better to be mentioned explicitly in Master build documentation. The errors I had seems related to MSVC version, which I added another question about in the support forum.

Build is going on now. I will update this thread later if the release build solves the crash or not. (that is hopefully I do get a full working release build)

[akhudairy]

Problem Solved after applying amaitland advice and using the release build. We did another release build and and also added codec support to it, and so far all looks good.