Marcos

The topic was renamed to a meaningful one. Let's try the following: 1, Disable SSL filtering in the advanced setup. Does Outlook connect to the mail server and receive email alright? 2, Reboot the machine. Without launching any application, re-enable SSL filtering and click OK. 3, Launch Outlook. Does the certificate warning still show up?

What we'll do it consider automatic resolution of blocked attempts to access a blacklisted website. It's unrelated to Web Control which is disabled by default and it's Web access protection which blocks access to sites known to host malware or PUAs.

This is not ESET's fault that the certificate used by the website was revoked. An administrator should replace the certificate with a valid one. As for the other machines, maybe you don't have SSL filtering enabled in ESET that you don't get any warning. https://www.ssllabs.com/ssltest/analyze.html?d=stormfront.org&s=104.20.32.134

You can try uninstalling ESET, running the Uninstall tool in safe mode and then installing v13 from scratch. Not sure if it will make any difference in reporting by the said sw though.

Of course. If there is no Internet access, from where the modules could be downloaded and updated?

In the Application statuses setup you can disable particular update statuses:

They can get information about the product name from HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info\ProductName and ProductVersion. I recall it's also possible to query WMI.

Please run the ESET Uninstall tool in safe mode. After booting to normal mode, install v13 from scratch.

What about pausing real-time protection?

What registry value does the sw monitor?

Is it the only exclusion in the list? Have you tested it by putting the eicar test file there and subsequently accessing it?

User variables do not resolve under the local system account under which ekrn.exe is run. That's why such exclusions cannot work. You can use C:\Users\*\AppData\Local\JetBrains\Transient\*.*, however, this is not officially supported and may not work if you add other exclusions.

This was fixed 3 hours ago. Please try now.

This is a known issue of v13. It's been tracked as a bug and already resolved internally so a fix will be included in the next release of v13.

A workaround should be already included in Endpoint 7.2. As for an actual fix in the VMWare driver, I have no clue if they have already included it in their products. However, a workaround on our part should suffice in order for the issue to not manifest.