CefSharp WinForms, Server 2003... runs once, but never again until reboot?

[murphmar]

Really trying to get this to work for us to replace IE7 in our PowerBuilder application. Everything works great on a Windows 7 or 2012 environment, but on 2003 I'm having a weird issue. Unfortunately we can't go ahead with this unless it's 100% on 2003.

When you run our app and then open the internal window which houses the browser control everything works great, as you would expect. You can close and reopen that internal window as many times as you want and browser will close and reopen as it should. The issue comes when you close the application itself. If you reopen the application and then try to open the internal browser window it will hang until you force close. Nothing seems to repair the problem except for a total system reboot. It works again after that.... once.

If anyone has any input that would be great. I can share whatever might be needed.

Thanks.

[jornh]

CefSharp version?

Do you see the same behaviour with either CefSharp.WinForms.Example or CefSharp.MinimalExample.WinForms?

[murphmar]

CefSharp/CEF built/running from CEF 3.1750.1738

[jornh]

So aka CefSharp 33 - but is it 33.0.* or 33.1:* (with JS Binding) - or better if it's a source build can you point to a commit SHA or branch+time?

Is there maybe a hanging Cefsharp.BrowserSubprocess.exe? Anything different in CEF's debug.log compared to your Win7 or 2012? Differences in .NET or VCRedist versions?

[jornh]

Sorry, I'm shooting a bit high and low with all my questions above. As we speak a WCF related bug is hopefully being resolved see #614 and #626. Most likely though that's something introduced, and fixed, after 33.1.0 (the JS Binding branch, which is now in the CefSharp 37/CEF 3.2062.* based master). So that's why your specific CefSharp version matters so much.

As you can see in Git history a lot has changed under the hood with both a CEF upgrade and local CefSharp-land WCF/JS Binding branch merge related changes. Maybe you should simply try reproducing with our latest CI build/your own source build with current master?

Hoping in the end (some of) all my questions can help you narrow in on the issue. 😧

[murphmar]

Thanks for the response.

Ok, so I replaced what I was using with the 33.0.2 release code. The issue remains. I copied the WinForms.Example app over to the server and I get the same issue with it as well. It runs perfectly until it's closed and you try to open it again. There's no sign of any hanging process after it's closed (BrowserSubprocess or otherwise). Rebooting the server solves it until you close the app and try to run it again.

The contents of the debug.log for the example app:

[1124/074046:ERROR:gpu_info_collector_win.cc(102)] Can't retrieve a valid WinSAT assessment.
[1124/074046:VERBOSE1:pref_proxy_config_tracker_impl.cc(148)] 06758F00: set chrome proxy config service to 06758D20
[1124/074046:VERBOSE1:pref_proxy_config_tracker_impl.cc(274)] 06758F00: Done pushing proxy to UpdateProxyConfig
[1124/074048:ERROR:gl_surface_egl.cc(133)] eglInitialize failed with error UNKNOWN
[1124/074048:ERROR:gl_surface_win.cc(97)] GLSurfaceEGL::InitializeOneOff failed.
[1124/074048:VERBOSE1:gpu_main.cc(265)] gfx::GLSurface::InitializeOneOff failed
[1124/074048:VERBOSE1:gpu_child_thread.cc(126)] Exiting GPU process due to errors during initialization
[1124/074048:VERBOSE1:ipc_sync_channel.cc(385)] Canceling pending sends
[1124/074048:VERBOSE1:ipc_sync_channel.cc(385)] Canceling pending sends
[1124/074048:VERBOSE1:statistics_recorder.cc(295)] Collections of all histograms
Histogram: GPU.CollectContextGraphicsInfo recorded 1 samples, average = 0.0 (flags = 0x1)
0 ------------------------------------------------------------------------O (1 = 100.0%)
1 ...

Histogram: GPU.InitializeOneOffTime recorded 1 samples, average = 1027.0 (flags = 0x1)
0 ...
894 ------------------------------------------------------------------------O (1 = 100.0%) {0.0%}
1062 ...

[jornh]

Good that you are able to reproduce with CefSharp.WinForms.Example ... makes it a lot easier for others to try ... If I get a moment and can find a 2003 server I might take it for a spin.

Is this with the same (virtual) hardware config as your Server 2012? How does the debug.log on Server 2012 compare to the one above?

Just to rule out that it's a graphics card/GPU related problem you can run as e.g.

CefSharp.WinForms.Example.exe --disable-gpu

as described in https://code.google.com/p/cefpython/wiki/CommandLineSwitches#disable-gpu

Also to check that it's not fixed by recent changes in master try with a fresh CefSharp.WinForms.Example as of today. Compared to 33.0.2 quite a bit of work on the IPC/WCF communication has happened and we expect today's master to be fairly close to a new 37.0.0 release

For comparison here's my Win7 debug.log head from recent master both with and without --disable-gpu:

[1124/164442:VERBOSE1:pref_proxy_config_tracker_impl.cc(148)] 05907B40: set chrome proxy config service to 05907960
[1124/164442:VERBOSE1:pref_proxy_config_tracker_impl.cc(277)] 05907B40: Done pushing proxy to UpdateProxyConfig
[1124/164442:VERBOSE1:webrtc_internals.cc(50)] Could not get the download directory.
[1124/164443:ERROR:renderer_main.cc(227)] Running without renderer sandbox
[1124/164443:VERBOSE1:texture_image_transport_surface.cc(380)] Allocating new backbuffer texture
[1124/164443:VERBOSE1:cookie_monster.cc(2116)] WARNING: Unsupported cookie scheme: custom
[1124/164443:VERBOSE1:resource_loader.cc(308)] OnResponseStarted: custom://cefsharp/BindingTest.html
[1124/164443:VERBOSE1:resource_loader.cc(348)] OnReadCompleted: "custom://cefsharp/BindingTest.html" bytes_read = 2652
[1124/164443:VERBOSE1:resource_loader.cc(348)] OnReadCompleted: "custom://cefsharp/BindingTest.html" bytes_read = 0
[1124/164443:VERBOSE1:resource_loader.cc(637)] ResponseCompleted: custom://cefsharp/BindingTest.html
[1124/164446:VERBOSE1:ipc_sync_channel.cc(385)] Canceling pending sends
[1124/164446:VERBOSE1:ipc_sync_channel.cc(385)] Canceling pending sends
[1124/164446:VERBOSE1:ipc_sync_channel.cc(385)] Canceling pending sends
[1124/164446:VERBOSE1:ipc_sync_channel.cc(385)] Canceling pending sends
[1124/164446:VERBOSE1:ipc_sync_channel.cc(385)] Canceling pending sends
[1124/164446:VERBOSE1:ipc_sync_channel.cc(385)] Canceling pending sends
[1124/164446:VERBOSE1:ipc_sync_channel.cc(385)] Canceling pending sends
[1124/164446:VERBOSE1:statistics_recorder.cc(295)] Collections of all histograms
Histogram: AsyncDNS.ConfigChange recorded 1 samples, average = 1.0 (flags = 0x1)
0  O                                                                         (0 = 0.0%)
1  ------------------------------------------------------------------------O (1 = 100.0%) {0.0%}
2  O                                                                         (0 = 0.0%) {100.0%}

Histogram: AsyncDNS.ConfigParseDuration recorded 1 samples, average = 14.0 (flags = 0x1)
0   ... 
14

[murphmar]

Hardware is all over the place on the different servers unfortunately. The 2003 boxes are older machines.

Adding the --disable-gpu command line actually fixes it. I tried it with the example app first, then added it into our own code. It's working within our PowerBuilder app as well. Awesome. I can add that command line with an x64 check for our purposes, so that should fix the issue for me.

That being said, I don't know if this would still be considered an actual issue or just a specific case? This might be more of a workaround.

[jornh]

Excellent that it's isolated 😄

if this would still be considered an actual issue or just a specific case?

Well, it's probably somewhere in between an upstream CEF (or even Chromium) issue and a specific case. I think if you search the CEF Forum http://www.magpcss.org/ceforum/search.php?keywords=disable-gpu&terms=all you can dig more into the issue. Let's just say GPU accelaration with all graphics cards is a huuge issue.

Also note that you can add settings.CefCommandLineArgs.Add("disable-gpu", ""); programatically see #365 (comment) for further.

Finally, I'm not sure if this #207 (comment) is feasible to detect the crash and cleanup somehow to avoid the lockup? ATM I'll leave it up to you if you want to dig into this as we got other things on our plate.

[murphmar]

That's how I have it done, a check to see if it's a 2003 server and, if so, add the CefCommandLineArgs 😄

Thanks again. I'll close this.

[jornh]

👍

[rover886]

@jornh and @murphmar I don't whether commenting on closed issue is correct or not but I am facing the same issue on Windows 2003. I am using cefsharp version 37 (Stable). In my case debug.log file is not generating. I have checked that .NET 4.0 Client Profile is installed on machine as well as VC ++ 11 redistributable is also installed.

After checking Event Viewer I got two errors in it :

Application: MyApp.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.IO.FileLoadException Stack: at MyApp.Program.Main()

Faulting application MyApp.exe, version 1.0.0.0, stamp 5507c7af, faulting module kernel32.dll, version 5.2.3790.3959, stamp 45d70ad8, debug? 0, fault address 0x0000bee7.

[amaitland]

When you run our app and then open the internal window which houses the browser control everything works great, as you would expect. You can close and reopen that internal window as many times as you want and browser will close and reopen as it should. The issue comes when you close the application itself. If you reopen the application and then try to open the internal browser window it will hang until you force close.

@rover886 Are you seeing the exact same issue? It sounds like your app doesn't run at all.