Welcome Guest Search | Active Topics | Sign In | Register

Intermittent “Failed to register DLL data” when starting EO.WebEngine after app idle Options
dayers
Posted: Tuesday, February 17, 2026 12:32:14 PM
Rank: Newbie
Groups: Member

Joined: 2/17/2026
Posts: 6
I’m running into a strange intermittent issue with EO.WebBrowser in a WPF application (.NET 8).

Very rarely, I get the following exception:

Quote:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
---> System.Exception: Failed to register DLL data.
at EO.Internal.xeym.rcvg.evav(Type[] nrl, xeyo[]& nrm)
at EO.Internal.xeym.qqkd(Boolean& nmu, Type[] nmv, String nmw, String nmx)
at EO.Internal.xeym.lwry(Type[] nmr, String nms, String nmt)
at EO.Internal.xeyn.lwry(String nsj, String nsk)
at EO.Internal.uxnc.uptr()
at EO.Internal.uxnc.fxro.avnn()
at EO.Internal.xeuc.qdnb(Action lvb)
at EO.Internal.uxnc.kglc(WindowsIdentity hi)
at EO.WebEngine.Engine.Start(WindowsIdentity user)
at EO.WebEngine.Engine.Start()
at EO.Internal.uxnc.uptq()
at EO.Internal.qthw..ctor(WebView d)
at EO.WebBrowser.WebView.Create(IntPtr hWnd)
...


What’s strange
The app launches fine. If I do not wait and go straight to launching the EO browser code there is very rarely any issue.
EO browser functionality works normally.
If I leave the application idle for ~5–10 minutes without interacting with any EO browser components, then try the execution, the exception consistently occurs.
Once it starts happening, I must close the main app via task manager.

It appears to be failing during: EO.WebEngine.Engine.Start()
Specifically with: System.Exception: Failed to register DLL data.

Possibly related to Engine lifetime / delayed initialization ?

Questions

What exactly triggers “Failed to register DLL data” inside EO?
Could this be related to Windows identity or session changes after idle?
Is it recommended to explicitly call Engine.Start() at application startup instead of lazy-starting on first WebView creation?
Are there known issues with EO after long idle periods?

Any insight would be greatly appreciated especially if someone has seen this pattern before.
eo_support
Posted: Tuesday, February 17, 2026 1:24:11 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,474
Hi,

Can you clarify which of the following 2 situations is your situation?

1. Start your application and use EO.WebBrowser code (which works fine), then wait for 5 to 10 minutes, then use it again, then it fails;
2. Start your application, never use EO.WebBrowser code, wait for 5 to 10 minutes, then use EO.WebBrowser code for the first time and it fails;

Thanks!

dayers
Posted: Tuesday, February 17, 2026 1:29:02 PM
Rank: Newbie
Groups: Member

Joined: 2/17/2026
Posts: 6
Hello,
It is situation #2 for me.
I would like to note this happens on the newest version as well as the version I first detected it in (25.2.1)
eo_support
Posted: Tuesday, February 17, 2026 4:16:04 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,474
Hi,

This might be a low memory situation. EO.WebBrowser requires a large chunk of continously memory block when it first initialize. This usually is not an issue when application just starts. However after the application has been running for a while, it's memory space can become fragmented to the point where such large continous memory block no longer exist. This would cause EO.WebBrowser fails to intialize.

However our past experience is when this occurs the code would fail at a different location with a different stack trace. We have not seen this particular stack trace for this reason before. As such if there is anyway to reproduce this problem or if you can provide a test system that we can access remotely it would be very helpful for us to get to the bottom of this issue.

Thanks!
dayers
Posted: Tuesday, February 17, 2026 4:47:35 PM
Rank: Newbie
Groups: Member

Joined: 2/17/2026
Posts: 6
I will see if your request is possible to complete.
However, I have seen this issue occur even after start up even without waiting, just with much less frequency. It just seems that waiting will definitely trigger the hang.

We have seen instances of installing the app and immediately running into the hang, and sometimes it never happens at all, it has been very tricky to reproduce until I accidentally discovered leaving the app idle also triggers it.

I also have what looks like an encrypted Webview*.txt crash file I cannot understand.

Just to also be sure, .NET 8 is fully supported/compatible?
eo_support
Posted: Wednesday, February 18, 2026 8:24:51 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,474
dayers wrote:
I also have what looks like an encrypted Webview*.txt crash file I cannot understand.

Please send those to us through our contact us page and we will see what we can find there.

dayers wrote:
Just to also be sure, .NET 8 is fully supported/compatible?

Yes. .NET 8 is fully supported (on Windows only).
dayers
Posted: Wednesday, February 18, 2026 2:23:54 PM
Rank: Newbie
Groups: Member

Joined: 2/17/2026
Posts: 6
Thanks, I'll work on submitting those.

I have noticed that our app is 32bit and historically I see the EO exe's inside Task Manager also said 32bit, and now they say 64 bit. Is this problematic?
eo_support
Posted: Monday, February 23, 2026 10:04:41 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,474
Hi,

It could be. We highly recommend you to run both your application and the browser engine in 64 bit mode due to the following reasons:

1. For debug purpose, it's better for your application to match the bitness of the browser engine. For example, to run your application in 32 bit mode and the browser engine in 32 bit mode, or to run your application in 64 bit mode and the browser engine in 64 bit mode. Mixing bitness is fully supported at runtime but in case of a crash, our crash report code would only be able to capture very basic information due to the bitness mismatch. The crash report would include more useful information if the bitness matches. This is important in your case;

2. Choosing between 32 bit and 64 bit, 64 bit is a better option because it gives you a much larger usable memory space. This again can be the root of the issue you are running into;

So if it's possible we recommend you to switch your application to 64 bit mode. If that is not possible, then you can try to switch the browser engine to 32 bit mode. Note the 32 bit mode browser engine requires a different setup file that is not publically available on our download page. So if you do decide to give 32 bit a try please let us know so that we can provide you the download location of the 32 bit build.

Thanks!
dayers
Posted: Monday, February 23, 2026 1:09:18 PM
Rank: Newbie
Groups: Member

Joined: 2/17/2026
Posts: 6
Thank you for the response.
I do not think 64-bit is going to be an option for our application at the moment.

I am working on setting up a build I received from support, but I would also like to try this 32-bit build as well. Is following up via the same email chain I have the best way to obtain this build?
eo_support
Posted: Monday, February 23, 2026 1:17:07 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,474
Hi,

We have just sent the x86 build download link to you through private message. If you have any questions, you can either reply here or our email.

Thanks!
dayers
Posted: Wednesday, February 25, 2026 11:20:43 AM
Rank: Newbie
Groups: Member

Joined: 2/17/2026
Posts: 6
Hi,
Sadly this issue I have is still present. When I idle, then launch EO's code, I get this blank white screen even on the 32-bit version.
Seems I have to downgrade to a working build.


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.