We are experiencing issues with our implementation of Eo.WebBrowser (version 23.3.4.0).

Occasionally, the web engine crashes, causing all Eo.WebBrowser instances to close unexpectedly. Unfortunately, this issue occurs randomly, and we have not identified a specific scenario to reproduce it.

If you're aware of any way to reproduce the issue, please let us know. We've found that refreshing the window (ctrl+shft+f5) in our case, brings the view back but we're unable to test it. We have collected the crash log file, which is provided below. Despite our efforts, we have been unable to consistently reproduce the issue. Here are the logs we have:

---

02 Apr 2025 14:25:21,180 [1] ERROR - EO.Base.Runtime exception occurred.

---

02 Apr 2025 14:25:21,181 [1] ERROR - ExceptionType:Exception
ErrorMessage: Channel disconnected
Stack Trace:
at EO.Internal.vqfa`3.cieo()
at EO.Internal.vqfa`3.rsnp()

---

02 Apr 2025 14:25:21,183 [1] DEBUG - EoWebBrowserControl.OnWebViewClosed https://abc.com: WebView was closed. Reason: EngineCrash

---

02 Apr 2025 14:25:21,216 [1] ERROR - EO.Base.Runtime exception occurred.

---

02 Apr 2025 14:25:21,217 [1] ERROR - ExceptionType:Exception
ErrorMessage: Channel disconnected
Stack Trace:
at EO.Internal.vqfa`3.cieo()
at EO.Internal.vqfa`3.rsnp()

---

02 Apr 2025 14:25:21,219 [1] DEBUG - EoWebBrowserControl.OnWebViewClosed https://cde.com: WebView was closed. Reason: EngineCrash

---

02 Apr 2025 14:25:21,276 [1] ERROR - EO.Base.Runtime exception occurred.

---

02 Apr 2025 14:25:21,277 [1] ERROR - ExceptionType:Exception
ErrorMessage: Channel disconnected
Stack Trace:
at EO.Internal.vqfa`3.cieo()
at EO.Internal.vqfa`3.rsnp()

---

02 Apr 2025 14:25:21,278 [1] DEBUG - EoWebBrowserControl.OnWebViewClosed https://efg.com: WebView was closed. Reason: EngineCrash

---

02 Apr 2025 14:25:21,310 [1] ERROR - EO.Base.Runtime exception occurred.

---

02 Apr 2025 14:25:21,311 [1] ERROR - ExceptionType:Exception
ErrorMessage: Channel disconnected
Stack Trace:
at EO.Internal.vqfa`3.cieo()
at EO.Internal.vqfa`3.rsnp()

---

02 Apr 2025 14:25:21,313 [1] DEBUG - EoWebBrowserControl.OnWebViewClosed https://xyz.com: WebView was closed. Reason: EngineCrash
-------------------------------------------------------

We have exactly the same problem. Unfortunately, the crash is infrequent and we have problem reproducing ourselves.
This is the stack trace for customers having this problem:
EO.Base.Runtime.pchr Channel disconnected
bij EO.Internal.ftgs`3.gdrh()
bij EO.Internal.ftgs`3.egxj()

I received two identical logs for two customers having this problem regularly, with timestamps 20250117112702 and 20250526115701 (Central European time). We use a Runtime.Exception handler, but crash reports are currently disabled. Many customers have the problem, but not all of them are willing to enable logging, or our CS did not ask them to do that.

We currently ship this version of EO components: 24.2.81.0
Customers say that the issue started happening when we upgraded to that EO version.
Previous versions we used: 24.1.93.0, 24.1.46.0

Tomorrow I'll create a new version of our software using EO:
- Using latest EO components:
- Allow to enable crash reporting and using unique key as per your requirement
We have already asked one of the customers regularly experiencing this crash to retest with that version.

Hi,

I have upgraded to EO components version 25.2.36.0 and have been testing with runtime crash. I can reproduce a similar crash as the customers experience, simply by killine eowp.exe while the web view is running. Then my Exception log shows this:

20250801131352 EO.Base.Runtime.slnj Channel disconnected
at EO.Internal.pyiw`3.lvyu()
at EO.Internal.pyiw`3.ujaj()

My goal is to save runtime crash data locally as well as sending it to Essential Objects. Reason why I want to code it like that is that many of our customers use environments with restricted internet access, so that sending the crash data has a high chance of failing in their environments. However, in my first test, it did not work as expected. I do get the exception log, but I also added a CrashDataAvailable event handler and that was never called:

EO.Base.Runtime.CrashDataAvailable += OnRuntimeCrashDataAvailable;
...
private static void OnRuntimeCrashDataAvailable(object sender, EO.Base.CrashDataEventArgs e)
{
try
{
string sCrashDataFilePath = Path.Combine(Common.LogPath, "EOCrashData-" + DateTime.Now.ToString("yyyyMMddHHmmss") + ".log");
File.WriteAllBytes(sCrashDataFilePath, e.Data);
string sMessage = "EO Runtime crash data written to file " + sCrashDataFilePath;
if (!string.IsNullOrEmpty(e.Message))
sMessage += Environment.NewLine + "Message: " + e.Message;
Trace.WriteLine(sMessage);
}
catch (Exception ex)
{
Trace.WriteLine(ex);
}
}

Did you receive crash data? The crash was at 2025-08-01 13:13:52 CEST, that is 11:13:52 UTC. I have set the ApplicationID to "DecosJoinNow-25.5.633.13000". A production build of the software will differ in the version number, but the prefix "DecosJoinNow-" will be the same.

I'll check if I do receive the CrashDataAvailable event when EO.Base.Runtime.EnableCrashReport is false.

Hi,

You will certainly reproduce the "Channel disconnected" by killing one of the child processes. However, that's a manufactured problem and it's not the real problem. This is like reproducing a "disk failure" error by pulling the hard drive out. There is no point of it.

The real problem is the child process crashed on its own unexpectedly. For example, it could be an access violation error due to a code error trying to write a buffer that has already been released. This will trigger the crash handler to try to capture information about the moment of the crash -- while the process is still technically "alive" (but in "coma"), once that information is captured, you will get CrashDataAvaliable event. This data may help us to locate the code that did that, we can then try to find out how it happened. In another word, the purpose of the crash data is to find out the root cause of the crash.

However if the process is just killed outright, everything about the process is already gone instantly, there is nothing left to collect/examine any more. Furthermore, even if information were available --- we already know the root cause of the crash is because you manually killed the process ---- so there is no point of collecting crash data in this case.

Thanks

Hi,

EnableCrashReport controls whether crash data to our server. CrashDataAvaliable handler allows you to save the crash data locally. These two work independently from each other. Usually people would set EnableCrashReport to false once they handle CrashDataAvaliable if they want to save and send the crash data manually instead of having it sent automatically.

One way you can simulate a crash is to load Url http://eounittest/crash.

Thanks!