Marcos

If you are using a 32-bit Windows 10, then it's a known issue which is being investigated by Microsoft. Rebooting the machine should fix it for a while. You can try disabling protected service and rebooting the machine which usually mitigates the issue. I'd recommend upgrading to 64-bit Windows 10, if possible.

Do you have the latest version 11.1.54 installed? Does the problem persist after uninstalling EAV and installing the latest version from scratch using default settings? Does pausing real-time protection make a difference?

I'm not sure if multi-monitor systems are supported by gamer mode if the screen is not stretched to all monitors. I'd suggest contacting customer care and creating a regular support ticket.

Unfortunately, the relevant log contained too little information for some reason. Try creating advanced logs again but wait at least 2-3 minutes after Windows starts before you disable advanced logging. It will be enough to provide just EPFW.etl from the C:\ProgramData\ESET\ESET Security\Diagnostics folder.

Yes, we have reached out to Microsoft and provided them with all stuff they requested for investigation. Some other AV vendors been reporting more severe issues after upgrade to v1803 and Microsoft allegedly temporarily stopped providing the update to their users while the issue is being investigated.

If you update through an http proxy, have you tried clearing the proxy cache? Could be related to this: https://forum.eset.com/topic/15573-verifyfilecontentsignature-failed-to-validate-pgp-signature-error-while-parsing/.

Does temporarily disconnecting the server from the network stop the malware from being created / detected ? Please gather logs with ESET Log Collector and provide me with the generated archive.

If they are getting an error "Scanner initialization failed", it's related to upgrade to Windows 10 April 2018 Update (v1803). We have published an alert for this: https://support.eset.com/alert6798/. Disabling Protected service in the HIPS setup and rebooting the machine might mitigate the error. Microsoft is looking into it, however, the result is uncertain at the moment. Wherever possible, I'd recommend upgrading Windows 10 x86 to x64 version.

We have confirmed this to be a bug in the latest ESET Endpoint Antivirus 6.6.2078.5. It will be fixed in the next version of EEA. ESET Endpoint Security is not affected which is why I was initially unable to reproduce it.

It's the PH driver which needs to be excluded. That doesn't matter if you create an exclusion by detection name which we prefer to excluding a particular file completely.

While running an in-depth scan, please create a dump of ekrn.exe via the advanced setup -> tools -> create (dump). When done, gather logs with ESET Log Collector, upload the generated archive to a safe location and drop me a message with a download link.

The detection is correct. Process Hacker is not detected as malware but as a potentially unsafe application. This detection covers legitimate tools that can be misused in the wrong hands for malicious purposes. It is disabled by default and users enable it at their discretion. Tools like this have been seen to be misused by hackers for killing security solutions after breaching into networks which enabled them to run ransomware and subsequently extort money from the victim. If you want to use the tool while keeping detection of pot. unsafe application enabled, exclude it from detection.

Please carry on as follows: - temporarily uninstall EAV and installing ESET Internet Security - enable advanced logging in the main gui -> Help and support -> Details for customer care - reboot the machine - disable logging - gather logs with ESET Log Collector and providing us with the generated archive - in the main gui -> help and support click Change product and select ESET NOD32 Antivirus after we find out the root cause of the issue.

How long does it take to scan the disk using the in-depth scan profile?

In automatic (default) mode, the firewall allows all outgoing communication and blocks all non-initiated communication unless blocked by custom rules. Please carry on as follows: - with EIS v11.1.54 installed, in the main gui navigate to Help and support -> Details for Customer care and select "Create advanced logs" - reproduce the issue - disable logging - gather logs with ESET Log Collector, upload the generated archive to a safe location and drop me a message with a download link.

Please carry on as follows: 1, Install Wireshark. 2, Enable advanced protocol filtering logging in the advanced setup -> Tools -> Diagnostics. 3. Start logging with Wireshark. 4, Reproduce the issue. 5. Disable logging, save the Wireshark log (pcap/pcapng) and compress it. 6. Gather logs with ESET Log Collector. Upload the generated archives to a safe location (e.g. Dropbox, OneDrive, etc.) and drop me a message with download links.

Try this syntax: eav_nt64_ENU.exe --silent --accepteula --msi-property-ehs PRODUCTTYPE=eav --msi-property PRODUCT_LANG=1033 PRODUCT_LANG_CODE=us-US ADMINCFG=“C:\Install\cfg.xml“

Since the firewall does not currently support wildcards, you can only create a new rule each time the folder changes. It should be improved in the future, however.

We don't have SysInspector for Mac and to my best knowledge there are currently no plans to have it in the future either.

We're not aware of any repository problem. There was a problem when the agent was accessing IP addresses instead of the host name repository.eset.com for some reason but this was solved more than 12 hours ago.

Disabling HIPS and protected service are two different things. While disabling HIPS would substantially deteriorate protection capabilities, disabling protected service has much negligible impact on security. Please disable only Protected service in the HIPS setup, not the whole HIPS feature and reboot the machine. We are still waiting for Microsoft to come up with a solution to the issue since it's a standard Windows API function call that started to fail after upgrade to v1803.

We have classified the executable as Win32/RiskWare.ProcessCritical.A application.

We have tested it on 2 machines and it indeed works. Please try the following: 1, Add 213.211.198.62 to the list of IP addresses excluded from protocol filtering 2, Download Eicar from http://www.eicar.org/download/eicar.com Is Eicar really detected by Web and email protection?

Please submit the sample as per the instructions https://support.eset.com/kb141/ for analysis.

By just a quick look it's a non-onfuscated Autoit script with "Joakim Schicht" listed as the author, so probably related to https://github.com/jschicht. I've passed the script for further analysis to confirm or deny that it should be detected.