Marcos

Indeed, there's no mention of a threat detected in memory. Detection of potentially unwanted applications is optional as they don't pose a threat.

Please post a complete scan log, not only brief information / statistics about scans. If there are too many records, post only the malware-related ones.

You can find instructions how to password protect a rar archive here for instance.

It doesn't sound like a general problem as nobody else has reported it yet and Adobe Flash as well as Firefox are famous programs used worldwide. Please try to narrow it down to the particular module by disabling HIPS, protocol filtering and real-time protection, one at a time and let us know about your findings.

Please submit the file to ESET as per the instructions here. Without analyzing the file, it's impossible to tell whether it's actual malware, clean file or non-functional (corrupt) file.

Please reinstall VC++ Redist. from hxxp://www.microsoft.com/en-us/download/details.aspx?id=3387. If you have Windows x64, also install hxxp://www.microsoft.com/en-us/download/details.aspx?id=26347.

When you encounter the issue, we'll need to get the following: 1, a complete memory dump created manually as per the instructions at hxxp://msdn.microsoft.com/en-us/library/windows/hardware/ff545499(v=vs.85).aspx 2, SysInspector log 3, information about installed module 4, export of product settings 5, information about the OS and platform (should be included in the SysInspector log)

If you look at the performance test closer, they state: Use cases: visiting websites, downloading software, installing and running programs and copying data. That said, it all boils down to what files are used. If large archives or heavily packed files are used, it will take longer to scan them. However, without knowing more details about this particular test, it's impossible to comment on it but generally said, in a real-world scenario ESET is one of the lightest AVs in terms of the system footprint. Also we've been continually working on improving performance of code emulation so that files are emulated by advanced heuristics much faster than ever before.

If you have an email address in the exception list, it will always be checked for spam regardless of whether it's in the whitelist or not. If you do not receive spam with your email address listed as the sender, removing it from the exception list should do the trick.

Check this out for a comparison.

50-80 MB is normal nowadays, also given that only the engine with signature database is about 31 MB in size which needs to be loaded in memory. Also memory is used for operations that would otherwise require writing to the disk which speeds us scanning a lot.

Reading several files at once from different physical places on the disk would make hard drive heads move forth and back which would actually slow down the scan speed. You can observe the same when copying files simultaneously within the same disk - it takes longer compared to the scenario when only file is copied at a time.

Your test was not performed with the public beta. Please try to reproduce it with v. 7.0.104 currently available for public testing and regardless of your findings, report the issue to customer care via the built-in form,

This would happen if the ERAS service was not running with efficient permissions. Under what account is your ERAS service running? Since your license was purchased in the USA, to contact the US Customer care, fill in the form hxxp://www.eset.com/int/support/contact.

Just to make sure, do you have the proxy server configured properly in the advanced ERAS setup?

Do you mean firewall on the server or on clients? If you create a mirror on the server using ESET Remote Administrator, is it created alright without an error and the problem is just with updating clients from the mirror?

I've seen variants detected only by ESET so the likelihood that the samples you're referring to are detected is quite high.

Most likely it's detected as Win32/Filecoder.XX. However, without an exact sample it's impossible to tell for sure and my assumption is based only on searching for the name provided.

Please post here a complete record from your ESET Threat log containing the full path to the file, the detection name as well as some other information.

You'd need to disable real-time protection but this would leave your computer unprotected. It's the role of real-time protection to scan all files that are created or accessed by the operating system or 3rd party applications. Are you experiencing any issue with real-time scanning?

Does the slowdown occur at the time the clients receive an update? By default, a startup scan is run after an update to make sure no threat is active in memory. Are they systems with multi-core processors or what's the hw configuration?

In order to troubleshoot the issue, we'd need a Process Monitor log from an issue replication for analysis. When you create one, compress it, upload it to a safe location and pm me the download link.

You can try v7 but since Windows XP uses legacy drivers and does not support minifilters, it won't make any difference and the issue will occur also with v7. There are basically 2 options: 1, upgrade the operating system to a newer one with support for minifilters 2, make the application open files for writing only in one thread. Making a change preventing the issue from occurring on Windows XP would cause the real-time scanner not to detect malicious files.

It's been confirmed by engineers that this issue cannot be fixed in the legacy driver used in Windows XP and older due to technical limitations of the operating system. Issues like this may occur if an application opens files in 2 or more threads for writing and ShareMode read,write. That said, the only solution is to use a newer operating system as keeping real-time protection disabled is not an option. Another solution would be to make the application open files for writing only in one thread in which case the sharing violation wouldn't occur.

Probably it's because I didn't restart after installing v7 beta. Anyway it's not a big deal as long as the Exploit Blocker is functional, which I hope it is, am I right? So this explains the problem. A computer restart is required for the text to be displayed as it was added via a module update so that beta users can test the new feature without making a new beta version.