itman

@Marcos already answered this. The answer is yes!

For those likewise "experimenting" with WD real-time, here is an article to how to configure block-at-first sight for the maximum time period of 60 secs. cloud scanning; i.e. 10 secs. default plus additional 50 secs.: https://www.ghacks.net/2017/05/26/set-windows-defender-antivirus-blocking-to-high-on-windows-10/ . Without a doubt, GPO is the way to do stuff like this but you need Win 10 Pro+ to do so. Note: this article is two years old, so perform web due diligence and verify the registry mods. given are still applicable if going that route on Win 10 Home. Also assume those reg. mods will definitely be wiped out by applying the next Feature Upgrade and possibly so by a cumulative update. There is also a possibility these high block-at-first sight will increase the likelihood of false positives so be prepared for that.

Personally, I believe Smart mode is nothing more than a HIPS "placebo" setting. I and many others have never seen a HIPS alert in either Auto or Safe mode assuming no user rules have been created.

The fact that you're on Win 10 1803 should have no bearing on why NOD32 can't install. When you ran the Eset Uninstaller Tool did you do so in Win Safe mode? It needs to be run in Safe mode.

Not that I noticed. Note that WD will whitelist a process after the initial block-at-first-sight scan so it is not repeated.

Good to know AMS is not dependent upon RTP. As far as ransomware additional HIPS rules, I use Eset's recommended ones plus many more of my own. My understanding of WD's advanced ransomware ASR mitigation is it is doing similar to what you noted in regards to Eset file level operations monitoring. If it detects during heuristic analysis at process startup like activities, those operations and/or processes are blocked. Assumed there could be conflicts with legit encryption software due to this. So exceptions to the ASR mitigation would have to be added. N/A for me since I don't use any like software. Again, I am still in the experimentation phase as to using WD as real-time protection but as noted, it does look promising.

You are the second person who recently posted they found NOD32 not running. What ver. of Windows are you using; e.g. Win 10 1903. Also have you applied recent Win Updates?

That's impossible to do unless we know what virus you are referring to. I have asked multiple times for you to display the virus information that Malwarebytes found.

As far as AMS goes, per the below Eset online help description that it works in conjunction with exploit protection leads me to believe it only applies to Web Access protection; the real-time function I have validated still is in effect if WD real-time protection is enabled: As far as ransomware shield protection, it also is a HIPS setting. If there is an Eset's real-time component to it, recent AV lab tests have shown WD's out-of-the-box ransomware detection is equal that of Eset's. An additional advanced anti-ransomware ASR mitigation can also be deployed. I assume that mitigation will block all non-Windows process based use of the crypto API's.

It is best you open a support ticket with Eset Middle East to assist you in removal of this.

Forgot to mention how I am disabling Eset's real-time protection is via Advanced Settings option. I am not disabling it via "Protections" opinions that show various pause duration settings.

Drag it to the desktop taskbar and it should remain unhidden.

Exactly. I long suspected that Eset's "real-time" protection is modularized. This is evidenced by the ability for different Threat Sense settings for real-time, Web Access, e-mail, and on-demand scanning. So in essence you are really only using WD for scanning of program and script execution only. However, this might change when advanced machine learning is implemented in Eset ver. 13. That feature appears to be part of Eset's real-time scanning feature. Presently, all of Eset's advanced protection methods are part of the HIPS.

That's the "gotcha" with Microsoft. WD has be the real-time scan engine. Also, ditto for ASR mitigations and network protection. What I have been experimenting with yielding very good results so far is using WD real-time instead of Eset's, but keeping Eset installed and operational. As best as I can determine, all Eset functionality still exists; especially Web Access and e-mail protection. Startup scanning and the like still runs fine. For example, all the AMTSO desktop tests are still detected by Eset. Perhaps Eset will soon offer this same option?

Was NOD32 running after you booted the PC for the first time today? Was the Eset status icon present on the desktop taskbar? Did its visual status indicate anything wrong with Eset?

Windows Defender Controlled Folders option has an additional anti-ransomware feature that will automatically backup your Controlled Folders to your cloud OneDrive account. The feature is called Ransomware Data Recovery. It is not enabled by default. Here's how to enable it: https://www.bleepingcomputer.com/news/microsoft/how-to-enable-ransomware-protection-in-windows-10/

I was using RS6; i.e. Win 10 1903, with ver. 12.2.23 installed without these new issues. As such, the problem is the new certificate Eset is using.

I believe its time Eset returns to how it was registering with Win 10 Security Center prior to ver. 12.2.29. I for one had no issues in this regard other that a registration issue appearing in the Eset event log similar to the one I previously posted. This event only occurred after an install or ver. upgrade and disappeared after a subsequent reboot. As such, I always ignored the event log entry.

I assume you have advanced HIPS log all blocked entries option enabled? If you scroll through the log, you will also see alot of other processes being being blocked from modifying Eset processes.

Synaptics is a company that markets human interface hardware and software (HMI). Did you manually install such software? Was it installed when you bought the PC? As far as the MalwareBytes screen shot, you didn't show what is the malware; i.e. type, that it detected. The files are not relevant at this point. Again, we need to know what malware MalwareBytes detected. Boot into safe mode and see if you can delete the files from there. While in safe mode, also run another scan with MalwareBytes. Note that the malware could have changed permissions on the %Temp%\ directory in question to prevent your access to the directory. You will have to modify those to include your local admin account access to the directory. Make sure you allow full read/write/modify access to the directory. These should have been set automatically when you added you local admin account. If you have an Eset SysRescue disk, boot to that an run a scan. If not and you have access to another PC, read the instructions on how to create SysRescue bootable media here: https://support.eset.com/kb3509/ . It is advisable not to create SysRescue media on an infected device.

I will also add that the Eset Win Security Center registration issue is not 100% fixed on ver. 12.2.29 as evidenced by the below log screen shot. However, I was having hardware issues at this time; non-boot hard drive crashed.

Below is what the same display looks like on my Win 10 x(64) 1903 build. Note that my screen resolution is 1920 x 1080 scaled to 125%. Also the screen shot is a .png file so its not 100% true to what is actually being displayed on the desktop. Appears to me something is wrong with the fonts your Win 10 installation is using.

My "old memory" just did a reset and I now recollect your question was about Eset product update settings? Eset a few versions back eliminated the option to be "asked" in regards to a release update. As I recollect, their reasoning was you should always perform an update when offered. Some didn't agree with that then, and some still don't agree with it now.

I saw your question yesterday. Was getting around to responding and you deleted all the detail within the posting. As such, I assumed you resolved the question/issue on your own. Note that from Friday evening through Sunday evening, a lot of forum members are not active on the forum. The same applies to the moderators. They jump in and out during the weekend and might have missed your posting. Remember this is the weekend and they deserve time off also. So I advise you to re-post and wait for a response.

Did you edit the screen shot you posted? The path shown doesn't make any sense. AppData is associated with a logged on user. For example, C:\Users\xxxxxxxx\AppData. Post a screen shot of log entries, etc. these other "anti-malwares" found. And also which anti-malwares you used for scanning.