mallard65

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

Hi, BPP module 1258 with fix is on prerelease. Please check it and let me know, if it helps

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?

Great analysis, based on this I'm thinking that the cost charged to have LiveGuard is not worth it. better stick with the EIS. since we are paying a high amount for nothing. or Kaspersky's Cloud solution, has the best result.

Since there were some questions about Eset local real-time processing scanning my test.exe in regards to my original posting I started this thread with, I retested using the following procedure:
1. I disabled Eset real-time scanning for my test.exe file by adding an exclusion for it.
2. I modified my test.exe using PowerShell to add some code to the end of the file resulting in the file hash being changed.
3. I uploaded the test.exe to a file sharing web site.
4. I removed the prior created Eset real-time scanning exclusion for the test.exe file along with deleting the file from my hard disk.
5. I downloaded the test.exe file from the file sharing web site. No LiveGuard submission occurred.
6. When I ran the downloaded test.exe, I received notification the file had been submitted by LiveGrid for Eset AV lab analysis and the process executed successfully.
Therefore, I conclude that something else within Eset is triggering an upload to LiveGuard and unknown files are not being submitted as stated by Eset. Or, my .exe as created bypassed LiveGuard processing.

I have a theory as to why LiveGuard is not detecting my test.exe and other missed downloads I have observed; that is they were only detected after download and submitted to LiveGrid. As much as I would like to believe it was my "stealthy" coding, that is not the reason.
To date, all LiveGuard submissions on my Eset installation have been detected during the in-process file creation phase. For Firefox browser based downloads, it was submission of the .part file in my User account temp directory. For the prior posted archive file attachment example, it was in the User Account temp created sub-directory by 7zip processing.
But what happens if the file downloaded/created locally doesn't involved any intermediate processing during file creation? My suspicion is FireFox for example, only will create a .part place holder file in the User account temp directory for larger file downloads. Otherwise, it will just directly create the download in the user's default download directory.
-EDIT- Also from the fileinfo.com link posted previously is:
As such, it is possible Eset is moving the .part file to the User account temp directory during LiveGuard analysis. In any case, it would appear LiveGuard processing would be dependent upon a .part file being created.

Eset Anti-phishing protection is URL based as noted in this knowledge base article: https://support.eset.com/en/how-anti-phishing-works-in-your-eset-product .
In regards to web based e-mail opened in a browser, it appears that only a known phishing web site which was physically accessed via opening an e-mail link would be blocked.

That's correct. Eicar is detected only if it meets its definition:
https://www.eicar.org/?page_id=3950
Any anti-virus product that supports the EICAR test file should detect it in any file providing that the file starts with the following 68 characters, and is exactly 68 bytes long.
The above file is longer and contains additional characters, breaking the definition of eicar.

If you don't buy a license ESET will stop updating and Windows Defender will activate instead when the engine becomes old. Only this could cause possible performance issues.

We try to push partners into offering upgrade to higher-tier products, however, in the end It's up to each partner if they offer upgrade or not.

If you contact your local ESET distributor / license seller, they should be able to upgrade your license to ESSP while subtracting the price for the remaining period from your current license.

I don't need speech too much, you can see from this video recording i made.
https://mega.nz/folder/K1ETlQZQ#zfHwuYK-ktD2LViXHxt9Zw

Tested with HIPS from Jan 2021, it behaved the same way.
You must create another similar rule for the folder itself, with the target path set exactly to
D:\frog

You cannot use \* at the end of the path. That's why I wrote:
You must create another similar rule for the folder itself, with the target path set exactly to
D:\frog
In this case it'd be D:\Racoon

You must have a custom HIPS rule created for files in a folder. In order to protect the folder itself from renaming, you must create another rule for the folder itself. It does not affect ESET's ransomware or other threat protection in any way.

There are very good reasons for this behavior. Protecting each of the parent folders could lead to serious issues that users are not normally aware of, including problems with applications using ADS for instance.

ESET's products fully support Windows 11.

You have purchased a boxed version of ESET so the code that was supplied with it expired with the new year. Please contact the seller or your local ESET distributor for a new code.

Currently it's not possible to remove it. When opening Internet banking sites, the green border indicates the user that a secure browser is being used and that the payment will be secured by BPP. Without that, users could doubt if a secure browser is active or not.

Good afternoon, I'm here to thank everyone involved in fixing HIPS.
With this fix my computer was consuming less processor.
Thank you for your efforts.

The link Itman showed seems to conflict with what is said on the forums about leaving pre release updates enabled. I presume this is for safety 

We didn't tell that a solution was available. The developer used future tense:
it will work from BPP module 1253.
I guess it was a misunderstanding of "it was fixed". Yes, it was indeed fixed in the code but the second part of the sentence was telling that it will be available in a next version of the module. ESET staff (typically developers) that replies in this forum besides moderators may not have experience with how to formulate replies precisely to avoid possible confusion so please bear with them. Moreover, they are not native English speakers.

Eset's KB article on pre-release updating: https://support.eset.com/en/kb3415-enable-pre-release-updates-in-eset-windows-home-products . Of note:

With all you do here for the company they should give you licenses. Pretty sad that they don’t.