We are not aware of any of such issues. Can you try to drag and drop a simple HTML file into the TabbedBrowser and see if it works? Also can you check the "Debug UI" tool in the drop down menu works?

Hi,

This should not be an installation issue. Can you try to run it in debugger, then pause the progress and then examine all threads and see if any thread is hanging where your code calls into our code but does not return?

Thanks

Is it possible for you to provide remote access to one of your system that has this problem? We are not able to reproduce the problem here.

Unfortunately it still did not fix the issue on my development computer. I compiled and ran on a different computer and it worked there. The 2016 version still works on my development computer as well (compiled). When I type www.google.com in the address bar and hit enter, nothing happens, it just says 'ready' in the status bar.

Windows 10 Professional 64 bit. Intel Core 2 Duo laptop.
When i run 2016 version and go to www.google.com, it says 'We've detected you're using an older version of Chrome'. I checked my Chrome browser and it is updated.

That code worked, however, it takes a LONG time before the page loads (www.google.com), up to 20 seconds. Not going to work for my solution right now. Why is this needed when 2016 didn't need it?

I have Windows Security essentials and ESET NOD32 AntiVirus installed as well (because that is what a lot of our customers are using). Disabling both did not make any difference. Corrected: it does go faster on my main i7 system.

This usually is caused by third party security software. What happens is, we call Windows system APIs, and security software would intercept such APIs calls in order to perform certain scans/checks and that can seriously slow things down. We have no control over such slow down because the vast majority of the time is spent by their code.

Most security software provide a way for you to "whitelist" certain application/dlls. That will skip extensive checks for applications from trusted source thus speed things up. So that might be what you want to look into.

If you want us to look into it, we will need remote access to both systems: One that is "normal" and one that is very slow. We will need administrative privileges on both systems as most likely we will need to change settings in order to pin point the exact location of the bottleneck. We can not fix what we can not see --- without access to the system, it will be shooting in the dark for us and there is virtually no chance for us to hit the target.



Our product is completely self contained. It does not have anything to do with the Chrome browser installed on the computer. However because it's built from the same source code the Chrome browser is built from, it would appear as Chrome browser to any web server. Our 2016 version is built from Chromium V49 code base, so Google would see it as a Chrome V49 thus it says "We've detected you're using an older version of Chrome". This means the V49 engine EO.WebBrowser 2016 uses is too old for Google, it does not mean the actual Chrome browser on your machine is old. EO.WebBrowser 2017 is based on Chromium V54, which is fairly new so it no longer shows this message.

There isn't much we can do on our end. There are numerous third party AntiVirus programs and they all have their own proprietary scanning/detecting logic, so it's not practical for us to work around them when the issue is on their end. Further more, all those programs themselves are constantly changing/updating, so even if we somehow worked it out for one version, it can break again in their next version.

The easiest way for you to do is to whitelist our DLLs/your application, we are not familiar with this particular program but most AntiVirus program provide a way for you to do so. This way instead of disabling it for everything, you would just be disable them only for our DLL or your application. Additionally, many AntiVirus programs maintain a default whitelist based on digital signatures. So if you can contact them to add our digital signature to their database then that will save you trouble further down the road with this same program.

Hi,

As already explained in our previous reply, there isn't a lot we can do on such issues because NOD32 is black box to us and it is virtually not possible for us to have code that specifically written to satisfy NOD32 since there are many different kind of such programs out there and they constantly change and update too.

Having that said, you can try the EnableEOWP property we mentioned in one of our previous reply and see if that helps. By default we use Windows rundll32.exe to start child process. Setting this property to true switchs it to our own eowp.exe file. Depending on exactly what NOD32 does not like, this might make a different.

If it still doesn't work, you may want to contact the support for NOD32 to see if they can provide you anything. Please feel free to provide our support contact to them and we will be happy to work with them if they work with us.

Thanks!