GPU process crashes inside of gl::CreateWindowsOnThread

[alervd]

In my project, I've updated CEF from 3.1979 (2015 year) to the latest 127.1.5.3024 (35f74ccdefd23b2d3b00129dc781fc429675ec79).

And now GPU process is crashing with the following stack trace:

libcef.dll!gl::'anonymous namespace'::CreateWindowsOnThread(base::WaitableEvent * event, HWND__ * * child_window, HWND__ * * parent_window) Line 107
[Inline Frame] libcef.dll!base::OnceCallback<void ()>::Run() Line 156
libcef.dll!base::TaskAnnotator::RunTaskImpl(base::PendingTask & pending_task) Line 203
[Inline Frame] libcef.dll!base::TaskAnnotator::RunTask(perfetto::StaticString event_name, base::PendingTask & pending_task, base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl::<lambda_4> && args) Line 90
[Inline Frame] libcef.dll!base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::LazyNow * continuation_lazy_now) Line 484
libcef.dll!base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork() Line 346
libcef.dll!base::MessagePumpForUI::DoRunLoop() Line 260
libcef.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * delegate) Line 85
libcef.dll!base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool application_tasks_allowed, base::TimeDelta timeout) Line 657
libcef.dll!base::RunLoop::Run(const base::Location & location) Line 136
libcef.dll!base::Thread::Run(base::RunLoop * run_loop) Line 338
libcef.dll!base::Thread::ThreadMain() Line 413
libcef.dll!base::'anonymous namespace'::ThreadFunc(void * params) Line 131
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()

So, it's crashing itself on a purpose here: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/ui/gl/child_window_win.cc#108. Because CreateWindowEx returns NULL due to an unknown reason.

I've tried to use --use-angle command line switch and it works fine now.

Unfortunately, this issue can't be reproduced using cefclient/cefsimple projects. Maybe it's some setting inside of my app which causes CEF to behave so weirdly. Unfortunately, I was not able to find it out. Anyway, I still do believe that it's some sort of CEF/Chromium bug. Any ideas why CreateWindowEx fails to create a window? It's very weird. Is it possible that cefclient/cefsimple projects uses some setting which avoids the use of this CreateWindowEx?

Versions (please complete the following information):

• OS: Windows 10
• CEF Version: 127.0.6533.89.

I'm using CEF Automated Builds (Standard Distribution). (https://cef-builds.spotifycdn.com/index.html).

[magreenblatt]

Maybe it's some setting inside of my app which causes CEF to behave so weirdly.

How does your app differ from the CEF sample apps?

[alervd]

Maybe it's some setting inside of my app which causes CEF to behave so weirdly.

How does your app differ from the CEF sample apps?

I don't know really. I've tried to find this difference which could be causing this issue and failed.

The only I can say is that my app's GPU process is launched using this command line:

D:\Work\Source\myapp\x64\Debug\myapp.exe" --type=gpu-process --no-sandbox --log-severity=disable --user-agent="Mozilla/5.0 (Windows NT 10.0; CEF/3.2272.2035) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 SoftwareInformer/1.6.1400" --lang=en-US --user-data-dir="C:\Users\user\AppData\Roaming\My App\WbaCache\CEF" --gpu-preferences=WAAAAAAAAADgAAAMAAAAAAAAAAAAAAAAAABgAAEAAAA4AAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAIAAAAAAAAAA== --field-trial-handle=2644,i,7482553779535433432,1946915803014080895,262144 --disable-features=BackForwardCache,CalculateNativeWinOcclusion,DocumentPictureInPictureAPI --variations-seed-version --mojo-platform-channel-handle=2628 /prefetch:2

while the cefclient's one is launched using this one:

"D:\Work\Source\1\build\tests\cefclient\Debug\cefclient.exe" --type=gpu-process --start-stack-profiler --enable-chrome-runtime --user-data-dir="C:\Users\user\AppData\Local\CEF\User Data" --gpu-preferences=WAAAAAAAAADgAAAMAAAAAAAAAAAAAAAAAABgAAEAAAA4AAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAIAAAAAAAAAA== --field-trial-handle=1924,i,7649616447415122149,783464029087748152,262144 --variations-seed-version --enable-logging=handle --log-file=1756 --mojo-platform-channel-handle=1920 /prefetch:2

Maybe this is caused by --disable-features thing? I don't know where it comes from and how to remove it.

[magreenblatt]

It looks like you're running with --no-sandbox and Alloy bootstrap (lack of --enable-chrome-runtime flag). The Alloy bootstrap is deprecated, see #3685.

Can you reproduce the issue in CEF sample apps using --no-sandbox --disable-chrome-runtime?

[magreenblatt]

Closing this issue as WontFix for the following reasons:

• Related to the Alloy bootstrap, which is deprecated.
• Crash is in Chromium (not CEF-specific).
• A workaround exists (add --use-angle command line switch).

[alervd]

Can you reproduce the issue in CEF sample apps using --no-sandbox --disable-chrome-runtime?

No, I can't.

[em-tg]

Hello, the CEF CAPI example project appears to be affected by this bug. This is not using the alloy bootstrap (I don't think the alloy bootstrap is an option in 129?). The crash happens in the same place mentioned by @alervd. The debugger shows that CreateWindowEx returns NULL but GetLastError() returns ERROR_SUCCESS. --use-angle prevents the crash.

I am able to reproduce on a Windows 10 computer with an NVidia graphics card, compiling the example project under Visual Studio 2022. cefsimple does not have the same bug, nor does the CAPI example project when compiling under MinGW. Another bizarre difference between the two compilers is that only the MinGW build respects the system dark mode preference, but I don't know if that's related, since --use-angle doesn't affect it.

You can test this using my fork of the CAPI example project by commenting out the line in cef_app.h that adds use-angle to the list of switches.

[amaitland]

GPU detection on windows requires an app.manifest with a Windows 10 compatibility entry.

Example https://source.chromium.org/chromium/chromium/src/+/main:build/win/compatibility.manifest;l=1?q=compatibility.manifest&sq=&ss=chromium

[em-tg]

Thanks a bunch! Adding a manifest seems to have fixed the issue. I'm not sure how I would have figured that out on my own, though. Is this requirement documented somewhere?

[alervd]

@amaitland Thank you! This solves issue.

[magreenblatt]

Is this requirement documented somewhere?

The compatibility.manifest is included as part of the CEF binary distribution and mentioned in the Tutorial.