Issue with CefSharp Version 127.3.50 in Kiosk Mode under Alternate Shell

[Youngoder]

I have developed a simple program that opens a browser window, displays a URL, and refreshes it every 120 seconds. The program runs on a terminal that is automatically started via a .bat file in Kiosk Mode (using Alternate Shell -->https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.WindowsLogon2::CustomShell) to prevent non-admins from making changes.

The program works flawlessly with CefSharp Version 126.2.180, but starting with Version 127.3.50, I encounter the error "Breakpoint encountered in the source program." Interestingly, the program works perfectly when a user logs in manually to the terminal and starts the program.

For troubleshooting, I tried the following:

Debugging with MessageBoxes: Added MessageBoxes at key steps in the program, but it didn’t help.

cef_log.txt: The log file provided no additional insights.

Windows Event Viewer: It didn’t show any relevant information.

VC++ Version: 2019.

Testing with different .NET Framework versions: Both .NET Framework 4.6.2 and 4.8 showed no improvement.

The terminal's operating system is Windows 10 Enterprise LTSC, Version 21H2.

Development environment: C# in Visual Studio 2022.

Has anyone experienced similar issues related to CefSharp, Alternate Shell, or Kiosk Modes? Are there any known changes introduced in version 127.3.50 that might cause this behavior?

[amaitland]

See https://github.com/cefsharp/CefSharp/wiki/Trouble-Shooting#unmanaged-crashes-when-the-process-dies

Has anyone experienced similar issues related to CefSharp, Alternate Shell, or Kiosk Modes?

I haven't had the need to try either.

Are there any known changes introduced in version 127.3.50 that might cause this behavior?

There are major upstream changes in this time period. https://github.com/cefsharp/CefSharp/releases/tag/v127.3.50

M127 is old and unsupported. How does M131 behave?

[Youngoder]

Thank you for the response and the provided information.

I’ve now tested the program with CefSharp Version 131.3.50, and unfortunately, the same issue persists: the program fails to run when started through the Alternate Shell (Kiosk Mode), but works flawlessly when launched manually after logging into the terminal.

Key Points:
Implemented all required code changes:

Migrated to the Chrome Bootstrap, as Alloy Bootstrap is no longer supported.
Set CefSharpSettings.RuntimeStyle = CefRuntimeStyle.Chrome explicitly.
Verified that all paths (CachePath, RootCachePath, etc.) are absolute.
Updated the initialization logic to handle Cef.IsInitialized (now bool?).
Verified VC++ 2019 is installed and correctly configured.
Debugging efforts:

Added cef_log.txt, which provided no useful information.
Added MessageBoxes throughout the program for debugging; no insights gained.
Examined the Windows Event Viewer logs, which revealed no relevant details.
Behavior comparison:

The issue only occurs in Alternate Shell (Kiosk Mode).
When running manually after login, the program works perfectly on all tested versions (127.3.50 and 131.3.50).
System configuration:

Operating System: Windows 10 Enterprise LTSC, Version 21H2.
.NET Framework: Tested on both 4.6.2 and 4.8.
Development environment: Visual Studio 2022.
Request for Assistance:
Could this issue be related to changes introduced in the Chrome Bootstrap or how Chromium handles process initialization under the Alternate Shell environment? Are there additional debugging tools or configurations for identifying problems specific to Alternate Shell or Kiosk Mode?

Thank you for any further insights or suggestions!

[amaitland]

Migrated to the Chrome Bootstrap, as Alloy Bootstrap is no longer supported.
Set CefSharpSettings.RuntimeStyle = CefRuntimeStyle.Chrome explicitly.

Bootstrap is different to style. Allow style is still supported. Try switching back to Alloy styling.

Could this issue be related to changes introduced in the Chrome Bootstrap or how Chromium handles process initialization under the Alternate Shell environment?

Possible. M126 was the first version to switch to using the Chrome Bootstrap by default, so it's not clear that it's specific to the bootstrap. It might be related to styling if you switched from Alloy to Chrome.

Are there additional debugging tools or configurations for identifying problems specific to Alternate Shell or Kiosk Mode?

Haven't used either, so cannot provide any specific guidance.

If you can I'd be enabling crash reporting as per link above.

[mikller]

I have exactly same issue, 126.2.180 is last working version.

Setting CefSharpSettings.RuntimeStyle = CefRuntimeStyle.Alloy does not work for me.

I tested every available version to 132.3.11 and still having this issue - does not work in kiosk mode.

It is very easy to configure "kiosk shell", I am using freeware portable product:
https://www.mirabyte.com/en/frontface/lockdown-tool/

You only need to create standard Windows account and in this program, in "Startup & Shutdown" section set path for app which should replace Windows Shell (App based on CefSharp in this case). That's all, the issue should appear.

The only log I have found is from Windows Event Log:
Faulting module name: libcef.dll, version: 129.0.11.0
Exception code: 0x80000003

But that tells me nothing.
Do we have any progress in diagnosis or workaround?

[photofinale]

We're also experiencing the same with recent releases: libcef.dll exception code 0x80000003 at startup.

We're not using a different shell, simply having our app launched by Windows at startup via the Registry (Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run).

Similar to reports above, we only get the crash when the app is launched automatically; it runs fine when launched manually. Introducing an extended delay (30s) before CEF is initialized and used, as a test, made no difference, the crash remained.

We have just managed to get a crashpad dump, trying to figure out how to decode that now.

[photofinale]

Fyi, we did observe the same beavhior when testing with the MinimalExample WinForms app, though it was intermittent.

We were not able to successfully analyze our minidumps in WinDBG, just could never get symbols loaded successfully for chrome_elf.dll (tried both the symbol server and downloaded symbols).

The simple workaround for us was to introduce a tiny intermediate app. That app gets launched by Windows at startup and it then launches our CEF app, and the exception no longer occurs.

[amaitland]

we did observe the same beavhior when testing with the MinimalExample WinForms app, though it was intermittent.

Are you able to try with the CEF Sample Application (cefclient)?

https://cef-builds.spotifycdn.com/cef_binary_135.0.20%2Bge7de5c3%2Bchromium-135.0.7049.85_windows64_client.tar.bz2

Then launch with the following command line args:

cefclient.exe --multi-threaded-message-loop --no-sandbox --use-alloy-style

If that doesn't work then can you try just

cefclient.exe

If the crash reproduces with either of those then we'll need to raise an issue at https://github.com/chromiumembedded/cef/issues

just could never get symbols loaded successfully for chrome_elf.dll (tried both the symbol server and downloaded symbols).

I don't believe CEF currently distributes symbols for chrome_elf.dll currently. Chrome Early Loading Framework (ELF), https://chromium.googlesource.com/chromium/src/+/master/chrome/chrome_elf/

If the exception is coming out of chrome_elf.dll, it's likely that would need to be fixed in CEF (possibly even Chromium).

[photofinale]

Thanks for the troubleshooting suggestions, Alex.

The crash was not reproducible with the cefclient app (with or without the args).

Also, with the CefSharp WinForms minimal example, I only caught a crash twice in probably two dozen reboots, whereas our app was consitently crashing within cef startup every single reboot.

The intermediary app launcher workaround has allowed us to move on, but hopefully we can circle back at some point and spend a bit of time whittling down our app to see what differences between it and the WinForms tester lead to the startup crashes.

[amaitland]

Also, with the CefSharp WinForms minimal example, I only caught a crash twice in probably two dozen reboots, whereas our app was consitently crashing within cef startup every single reboot.

Interesting. I'm guessing the log file is empty when it crashes?

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

Which is potentially one of the differences, the MinimalExample has crash reporting enabled by default.

https://github.com/cefsharp/CefSharp.MinimalExample/blob/master/CefSharp.MinimalExample.WinForms/crash_reporter.cfg

Crash Reporting does I believe hook in with ELF, so maybe it's somehow related to the crash? (Speculating on this one)

https://chromium.googlesource.com/chromium/src/+/HEAD/chrome/chrome_elf/crash/crash_helper.cc

Another thing to check is your application has an app.manifest with Win 10 compatibility entry.

https://github.com/cefsharp/CefSharp/wiki/Quick-Start-For-MS-.Net-4.x#40-add-appmanifest-to-your-application

https://github.com/cefsharp/CefSharp.MinimalExample/blob/master/CefSharp.MinimalExample.WinForms/app.manifest
https://github.com/cefsharp/CefSharp.MinimalExample/blob/master/CefSharp.MinimalExample.WinForms/CefSharp.MinimalExample.WinForms.net472.csproj#L17

The intermediary app launcher workaround has allowed us to move on, but hopefully we can circle back at some point and spend a bit of time whittling down our app to see what differences between it and the WinForms tester lead to the startup crashes.

As cefclient works, it should be just a matter of working out what's different. Hopefully I'll have some time next week to see if I can make the MinimalExample stop working.