Crash on shutdown

[ray007]

My application is working quite nicely most of the time, but when I shutdown/restart Windows I get an error like

"The instruction at "0x........" referenced memory at "0x0000003d". The
memory could not be read.

Click Ok to Terminate the application
Click Cancel to Debug the application 

for each instance still running. Closing the application normally shows no problem.
Any idea what's going on here?

Info Update: the WPF Example application shows the same problem.

[ray007]

And another update: I just pulled the current master and the WPF example app didn't show the problem anymore with my last test (just 1, more testing pending).
Could we please get a new nuget package?

[amaitland]

See #617 for into on our MyGet feed. Our CI server produces Nuget packages for every commit on master.

The official release of 39 is coming, there's still a few too many outstanding issues for a release just yet. More info can be found here https://github.com/cefsharp/CefSharp/milestones/39.0.0

[ray007]

Thanks for the hint.
I tried the package from MyGet but unfortunately it didn't help.
Testing the Wpf example app from here again I found it also still exhibits the problem - most of the time.

Btw: why does the package on MyGet depend on an oder version of the CEF redist packages than the one on NuGet?

[amaitland]

Did you try 39.0.0-CI687? That should be the latest MyGet package. It uses CEF 3.2171.1972.

[ray007]

Ah, seems I just misinterpreted the warning about CEF 3.2171.1979 package not being compatible.

[amaitland]

Are you manually calling Cef.Shutdown() when you application window closes?

[ray007]

I do.
But it doesn't seem to make a difference either way.

[amaitland]

Do you have some sort of logging before and after to make sure it is actually being called? If it's called, everything should clean it's self up.

(Need to make sure it's called on the same thread as Initialize is called)

[ray007]

Hmm, I've added to log calls immediately before and after the Cef.Shutdown() call, but the second line never makes it into the log. I'll try to call it earlier to see if that changes anything.

End of the debug-log is as follows:

[0212/140407:VERBOSE1:ipc_sync_channel.cc(386)] Canceling pending sends
[0212/140407:WARNING:message_in_transit_queue.cc(18)] Destroying nonempty message queue
[0212/140407:VERBOSE1:ipc_sync_channel.cc(386)] Canceling pending sends
[0212/140407:VERBOSE1:ipc_sync_channel.cc(386)] Canceling pending sends
[0212/140407:VERBOSE1:ipc_sync_channel.cc(386)] Canceling pending sends
[0212/140407:ERROR:gpu_process_transport_factory.cc(437)] Failed to establish GPU channel.
[0212/140407:VERBOSE1:ipc_sync_channel.cc(386)] Canceling pending sends
[0212/140407:ERROR:gpu_process_transport_factory.cc(461)] Lost UI shared context.

[ray007]

Calling Cef.Shutdown() earlier didn't change anything.
It doesn't ever return - the log-call directly after is not executed and the surrounding try-catch also doesn't catch anything.

[ray007]

Info update:
for every single one of my shutdown problems there is an entry in the windows event log:

Application: MyApp.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: exception code c0000005, exception address 063A543A
Stack:

though the exception address at the end varies.

[amaitland]

If you close your application gracefully are the exceptions appearing?

[ray007]

If I normally close the application everything is fine.
The problem only happens when initiating a shutdown or reboot of the system.
And the CefSharp.Wpf.Example app has the same problem most of the time...

[amaitland]

And the CefSharp.Wpf.Example app has the same problem most of the time...

Have you tried debugging the example? Does the debugger stay attached long enough to see anything useful?

[ray007]

Did a fresh git pull half an hour ago and tested again with CefSharp.Wpf.Example.
Unfortunately I've been unable to trigger the problem with a debugger attached.

Since you're asking: does that mean you cannot reproduce the problem?

[amaitland]

Since you're asking: does that mean you cannot reproduce the problem?

Personally I have a huge list of other tasks to complete so I haven't had time to look at this further.

It sounds like we need some sort of logging to see what's going on under the hood.

[jankurianski]

@ray007 Is it as simple as the following, or is there more to it?

1. Start CefSharp.Wpf.Example.exe
2. Shutdown windows.

Exact steps are a necessity here, as no-one is keen on shutting down their dev computer many times 😄 Also useful is information on timing if it is relevant - i.e. waiting for page to load, or immediately attempting shutdown.

[ray007]

@jankurianski I usually choose Restart instead of Shutdown, but yes, that's it.

I'm not aware of additional timing-related issues, but since my resources are local/close by the page was always loaded when initiating a shutdown. But there may well be something timing-related, since I managed to reboot one time without the problem - the rest is by now probably a 3 digit number.

The good news is, if you're quick enough you can Cancel the shutdown when asked by Windows, saved me a few reboot cycles...

[amaitland]

Can you confirm if the same problem exists with the WinForms version? That will help narrow the scope, if it's a generic CefSharp issue, or just related to the WPF control.

[ray007]

Surprisingly (for me) the WinForms example doesn't have the problem.

[amaitland]

Likely it's related to the OSR rendering then, at least that's where I'd start looking.

[ray007]

OSR? Like OffScreen Rendering? If the Wpf code depends on the Offscreen code I don't yet see how.
I'm afraid I need a better pointer to help looking/debugging/logging/...

[amaitland]

OSR = OffScreen Rendering, both OffScreen and WPF use the same underlying principal. CEF renders the frame to a bitmap.

Place to start looking is https://github.com/cefsharp/CefSharp/blob/master/CefSharp.Core/Internals/RenderClientAdapter.h

[ray007]

Sorry, my C++ skills are too ancient and rusty for that.

The good news is, I've got a workaround for the problem that I can live with for now. I've added

protected override void OnSessionEnding(SessionEndingCancelEventArgs e)
{
    System.Diagnostics.Process.GetCurrentProcess().Kill();
}

to my App.xaml.cs, and while most times I still get an error-entry in the windows event log, the ugly error dialog is gone with that...

[amaitland]

Sorry, my C++ skills are too ancient and rusty for that.

I find it very disappointing that you'd give up so easily 😦

[canton7]

I'm also seeing this on logout, not just on shutdown

[canton7]

Thanks for the workaround, @ray007

[tbowers]

For my education, why is this .Shutdown() needed? Is this not something that could be encapsulated into the CEF sharp wrapper itself on Application exit event?

[amaitland]

Is this not something that could be encapsulated into the CEF sharp wrapper itself on Application exit event?

We make a best effort to Shutdown() gracefully, see https://github.com/cefsharp/CefSharp/blob/master/CefSharp.Core/Cef.h#L56

You need to make sure you call Shutdown() on the same thread Initialize() was called. So sometimes you need to handle the case manually.

In the upcoming 39 release, creating an instance of ChromiumWebBrowser will initialize Cef if you haven't already. So the framework tries to take care of this for you. Sometimes it's just not enough.

If your app hangs during exit, I'd typically recommend calling Shutdown() manually, then you can see if the call hangs. Sometimes executing tasks on the Cef threads can also cause problems. see #872 (comment) for one such issue.

[amaitland]

@Bodekaer Your probably aware of this already, so Ignore if you are. This issues affects MailBird.

[Bodekaer]

Thanks for the heads up Alex.
FYI @myrnazhou

[mohdimas]

Ok thanks @Bodekaer

[amaitland]

For future reference https://msdn.microsoft.com/en-us/library/system.windows.application.sessionending.aspx

[amaitland]

Also https://msdn.microsoft.com/en-us/library/system.appdomain.processexit.aspx

Note: The total execution time of all ProcessExit event handlers is limited, just as the total execution time of all finalizers is limited at process shutdown. The default is two seconds. An unmanaged host can change this execution time by calling the ICLRPolicyManager::SetTimeout method with the OPR_ProcessExit enumeration value.

[amaitland]

If anyone is interested this appears to be fixed in the 2272 branch. I've only tested on a single Windows 8.1 machine, so this isn't definitive.

(I wouldn't recommend switching to 2272 as the API is undergoing some changes and isn't likely to be finalised for a few weeks).