itman

Given this very long list: https://support.kaspersky.com/15517#block1 of apps that Kaspersky Total Security is incompatible with and the fact that AdGuard is not listed, I assume that KTS is not using the Windows Filtering Platform.
Or perhaps because KTS and AdGuard are both Russian based apps .........................

I tried enabling/disabling various Firefox settings to no avail. Every time Eset alerted.
This gets us to Eset's Web Access protection; namely Protocol filtering. Eset's Protocol filtering uses the built-in Windows Filtering Platform. There are other third party security solutions that also by default, use the Windows Filtering Platform. An example is the installed version of Adguard. And, it does indeed conflict with Eset. Adguard's WFP use must be disabled and, use of its mini-filter network adapter driver be selected instead.

This time when I opened B&PP via Firefox, I did a Ctrl+F5 key combo to clear its cache. Note that FF in B&PP uses a separate profile from normal FF. This time upon closing B&PP, Eset Service memory returned back to approx. 40 MB.
Hope this finally fixed this memory bugger issue with Eset Service.

Well, it just jumped to over 220 MB again!
Reflecting on my system activity just recently, guess what? I opened a B&PP session ....................

Well on my Eset installation, Eset Service is staying at approx. 40 MB, So it appears the issue has been resolved for me.

Well on my Eset installation, Eset Service is staying at approx. 40 MB, So it appears the issue has been resolved for me.

Is your default search engine in Firefox set to Google?
It is possible your Firefox installation is corrupted. Also, uninstalling Firefox does not remove one's existing profile. It must be manually removed prior to reinstalling Firefox.
https://onlinehelpguide.com/why-is-firefox-google-search-not-working/

Note that the search result was returned in HTTP format. This is significant.
If I override FireFox HTTPS everywhere setting, Eset blocks the HTTP web site:

My best guess at this point is whatever is malicious about this URL and related ones is not rendering in HTTPS.

Upon access from Google search results link:

Also Eset phishing protection isn't "bulletproof."
Here's one: hxxps://irs-contact-payments.com/home recently added and verified today at PhishTank web site. Google Safe Browsing caught it. Eset did not.
Now here's one: hxxxps://web-privacy-app.com/ added about 4+ hours ago. Eset did detect this one.
These results parallel my previous test results. Eset needs a few hours to update its phishing blacklist.
   

After my above posting for today, I did the following.
I have noticed recent a lot of Win 10 compattelrunner.exe activity at first system startup. Also large downloads occurring; 50 - 60 MB. So I told Windows to delete my diagnostic history.
When Firefox started, I did the Ctl+F5 key bit to clear Firefox cache.
Since then Firefox memory consumption hasn't went above 40 MB.

After first system startup today, Eset Service using 169 MB. Startup and use of Firefox does not change Eset Service memory usage.
Very strange memory usage behavior going on by Eset.

Looks like there is a problem with Eset memory usage.
I just checked mine in PE and its showing 368 MB Working Set and 229 MB real memory usage. Previously, I never saw real memory usage exceed 50 MB memory usage.

If HMP-A was actually able to teminate ekrn.exe, then there is a problem with Eset's self-protection.

There were past issues with Eset's key scrambling in B&PP:
https://www.hitmanpro.com/en-us/whats-new/hitmanpro.alert
Assumed is Eset did something in the latest releases to have this issue manifest again.
As I see it, it's up to Sophos to make it compatible again.

At this point, I really don't know what is causing this memory spike issue aside that Eset has gremlins within it!
I restart and Eset Service is using <40 MB.
Open and close Firefox multiple times and Eset Service is using <40 MB.
Shutdown the PC and restart 10 mins. later.
Open and close Firefox multiple times and Eset Service is using <40 MB.
-EDIT- Eset Service final increased to Eset Service >200 MB. So the issue is related to something going on in Firefox but I have no clue what that something is.

I just did some tests. the image below and when I restarted my computer and did not open firefox gave this result:

Now another test, I restarted the computer and open firefox, look at the result.


Now I closed firefox later and this value still remains as shown in the image:

Looks like it's not sleep mode after all.
This morning after system startup, Eset Service was using less than 40 MB. After openning Firefox, Eset Service now using 200+ MB.
I don't care about the increased memory use when FF is active. What I don't like is Eset is not releasing the memory after FF is closed.

I did a system restart. Eset service started up at 22 MB and gradually rose to 28 MB.
Opened Firefox and some other apps and memory usage is currently at 30 MB.
As I recollect, I saw Eset Service memory usage spike to the 200+ MB range after a recent MS Office update and it never went down afterwards. I will keep monitoring to see if its leaking memory.

Let's check the obvious. Is LiveGrid Feedback enabled?

I will note that maximum download speed varies dramatically depending on network adapter, connection type used, and computer manufacturing date. As far as computer age goes, this is referencing the motherboard network adapter chip used and the BIOS/UEFI interaction to it. Some motherboards have an internal speed test accessible via the BIOS/UEFI that measures network Ethernet bandwidth between the router and motherboard. This should always be the first test performed to verify that the router is actually serving up 1Gb speed.
The below screen shots are from Google 1 Gb fiber service in regards to their speed test:

https://support.google.com/fiber/answer/6250056#zippy=%2Cmobile-devices-wi-fi%2Ccomputers-ethernet-or-usb-adapter-to-ethernet%2Ccomputers-wi-fi

Looks like the problem has been resolved, folks!
Since the screen shots posted in my last posting were for illustrative purposes only and not chronologically synced to a specific test instance, I decided to repeat the test and post new screen shots.
When I started to retest, Firefox updated to ver. 96.0.3. After that update, I can no longer duplicate what was happening previously.
From everything I am observing when testing after this latest update, Firefox was the "culprit." Prior to the update when Google Safe Browsing blocked a download, Firefox was downloading a .part version of the file to the Downloads folder. LiveGuard then attempted to process this .part file and "everything went downhill" Firefox and LiveGuard wise thereafter. After the Firefox update, no .part file is being downloaded to the Downloads folder when Google Safe Browsing blocks a download and no subsequent LiveGuard processing occurs.
A note of interest here is Firefox still is downloading a .part file to the %Temp% directory. If you manually in FireFox don't remove the Google Safe Browsing blocked download or navigate immediately to another web site, that .part file remains in the %Temp% directory:

Appears LiveGuard is "oblivious" to the existence of this file.

BTW - I did verify at VT the the above .part file is just a renamed version of VbsToExePortable_3.2_Dev_Test_1.paf.exe.
Since it appears LiveGuard is triggering off the download to the %Temp% directory, this brings up LiveGuard bypass possibilities. Something along the lines of a simultaneous payload download to both the Downloads and %Temp% directories?

BTW - I did verify at VT the the above .part file is just a renamed version of VbsToExePortable_3.2_Dev_Test_1.paf.exe.
Since it appears LiveGuard is triggering off the download to the %Temp% directory, this brings up LiveGuard bypass possibilities. Something along the lines of a simultaneous payload download to both the Downloads and %Temp% directories?