NOD32 v4: are any files excluded automatically?

Hi All,

I'm new to NOD32 and was wondering what files, if any, are automatically excluded from scans and real-time monitoring? e.g. pagefile.sys, hiberfil.sys etc?

I saw mention of automatic exclusions in a forum thread, but it lacked details and I found nothing in the NOD32 docs about what might be automatically excluded...

TIA,
-Mike

 

Automatic file exclusions are first supported in the server product line 4.3. Version 5 scans files in a smart way and may skip those that are 100% clean (ensured by various mechanisms).

 

My NOD32 client reports v 4.2.71.2, so I presume there are no automatic exclusions.

Is there a recommended list of typical exclusions that should be made for the various Windows operating systems?

Maybe there's a sample config (.xml) that contains typical exclusions?

 

Unless you're running a server there's no need to exclude anything.

 

Hmmm, all past AV products we've ever used recommended certain os files be excluded. Many products even auto-exclude such files, or provide a list in a sample policy/config.

So you're saying NOD32 will scan files like pagefile.sys, unless we specifically exclude them in our policy?

Even Microsoft has a list of files they recommend be excluded by AV products.

Maybe I misunderstood you Marcos - is it possible there are some files that NOD32 excludes by default (even though they may be hidden)?

 

I'm not aware of any such list recommended by Microsoft for home versions of Windows. Files exclusively used by the oper. system are not scanned as the OS does not allow other apps to access them.

 

Hmmm, am I posting in the wrong forum? I am using NOD32 4.2 *business* - to provide AVAS to all my customers' business PCs.

FYI, here is the link to a Microsoft KB article that I have seen many AV vendors reference:

http://support.microsoft.com/kb/822158

 

Those exclusions apply for server systems. It is not a common practice for home and corporate users running Windows XP, Vista or Windows 7 to exclude files. It is only necessary on server operating system where scanning certain files may lead to problems. On home OS it's never been a problem to scan everything that is not locked by the OS.

 

Hmmm, that's not what I got out of this KB . You might want to look at the KB article again, as the first section states:

"For computers that are running Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, Windows 2000, Windows XP, Windows Vista, or Windows 7"


Maybe your developers should review this too?

 

Marcos - I also wanted to ask you why you frequently refer to NOD32 *home* versions? Is there a better forum section for me to post NOD32 v4.x business questions?

 

Another thought to consider: earlier you said "Files exclusively used by the oper. system are not scanned as the OS does not allow other apps to access them"

I'd suggest that excluding files known to be locked by the os would yield more efficient scans and realtime protection. e.g. Why ask the operating system to grant access to the page file (pagefile.sys) if it's known to be a restricted file? Each such attempt wastes precious resources. And I believe there are other files that although the os will let you open/scan it, you may end up interfering (or degrading) os operations. e.g. Windows Update database and its log files.

 

Marcos - while searching to find out if the Exclusions section supports environment variables, I found a thread that discussed this very same MS KB 822158. So apparently this same issue has been raised before. You even participated in this thread: https://www.wilderssecurity.com/showthread.php?t=267344&highlight=windir

That thread is almost 2 years old - and it seemed that ESET was going to add support for envir vars. Did that ever happen? If not, any ETA? This is a very important feature for those of us who choose to follow this MS KB...

Sorry for all the posts - but I am a NOD32 newbie with more questions than answers

 

bump, bump

 

They've said that variable support has been in the works for a while, but I'm not holding my breath. Honestly, working around it hasn't been that difficult. Your paths for exclusions are going to be primarily C:\Windows with the only wrench being if you need to support NT/2000 systems and then you'll need a second copy of those exclusions with the altered C:\WinNT path to handle that. Just get them in there ahead of time with your cfg.xml file or push them down with a policy and you can forget about it for years after.

The one situation I could see where it would really bite you in the butt is if you have a program that needs a file exception, and it is keeping the file someplace under the %userprofile% directory somewhere. Thankfully I've never run in to that and I haven't see anyone here who has either.

As for the AV engine trying to access locked files and being denied, this is going incur a delay in the nanoseconds. Coding around that would produce such an insignificant benefit that I doubt it would be worth doing, and it would probably come out as a wash anyway since now all IO operations need to be compared against an ever-increasing list of exclusions.

 

But what if, as MS states in that KB, system performance is affected when NOD32 attempts to access some of these locked os files? I'd rather avoid them in the first place and keep the os running as smoothly as possible. Granted, it takes a few milliseconds to process the exclusion list, but it is probably time well spent to insure whatever sensitive os files are left alone.

As a new NOD32 user, I am trying to leverage all that I have learned from past AV products (most recently I dumped GFI's VIPRE Enterprise). I've learned the hard way that it's best to do some up-front homework and exclude some items, otherwise performance issues come up and customers complain.

 

I understand those concerns, but in practice it just does not end up being an issue. The scenario you do need to concern yourself with is files that rapidly lock, write, and unlock. The anti-virus software will jump in and re-scan that file after each unlock which will thrash disk IO, suck up CPU, and generally degrade performance. The vast majority of the time, this will be from DB and log files which you should always be excluding from scanning. Then there may be a few other oddball programs using flat files in the way I described which would also need an exclusion, but you won't know about those until you stumble in to them.

 

Hello,

ESET has invested a bit of time in optimizing its software, not just from the perspective of malware detection, but also the overhead it introduces into a system from things like on-access scanning and file I/O.

Files which are held open exclusively by various versions of Windows like the swap and hibernation files, as well as some of the database container files are not going to be scanned while the operating system is live—you will probably see some sort of "error opening (File locked) [4]" notification in the log file from a scanned system and that's about it.

If you want, you can exclude the files mentioned in the Microsoft Knowledgebase articles, but I think you are going to find that doing so has much of an effect on overall system performance.

Here's what I would suggest doing: Since you are still in the process of planning out your test deployment, create a couple of test configurations, one with the exclusions, and one without. Push the configurations out to two identically-provisioned computers and monitor their behavior. In all likelihood, you are not going to notice much difference between the two.

Of course, if you do, we can do some troubleshooting, but usually the sorts of objects which I see need to be excluded are third-party applications which perform a lot of rapid-fire file I/O requests.

Regards,

Aryeh Goretsky

 

Hello agoretsky - I can try the comparison tests you suggest. Just curious - have you ever tried doing the comparisons? As far as simple os files like pagefile.sys and hiberfil.sys, how often will ESET try to access them if they are not excluded? Pagefile.sys likely changes quite frequently - so does that mean NOD32 realtime protection will attempt to check it every time it changes? Or does NOD32 have some special table of special os files and knows to not keep checking it?

Interesting that you said "ESET has invested a bit of time in optimizing its software, not just from the perspective of malware detection, but also the overhead it introduces into a system from things like on-access scanning and file I/O." I modified my default client policy to do a "smart" scan at 1pm every day and am amazed at how slow my computer performs during the scan. I even set it to Low Priority (can only imagine if it wasn't . I was trying to mimic my prior AV software (VIPRE) that had a "quick scan" profile that only scanned memory and key Windows folders (e.g. %WINDIR%, %ProgramFiles% etc.). This quick scan would take only a few mins to complete, so could run every day without impact users. Can the same be done with NOD32? Does NOD32 support envir vars in the *paths* entered into the Exclusions section?

 

A smart scan is automatically performed during user logon (up to once per day) as well as after every definition update (workstations will see that 2-3 times per day). Scheduling another one is superfluous and will not detect anything.

I would strongly suggest starting with the defaults (maybe enable unwanted program detection and set strict cleaning for the full system scan profile) and work from there only if you encounter a problem. The defaults are quite intelligently configured and there really isn't much you need to do besides pointing clients as your update mirror and management server.

System environment variables like %WinDir% are not supported in the exclusion list. You will need to include the full path, but hopefully everything you run these days is C:\Windows.

 

Hello,

When I have performed an investigation into locked files (or file I/O issues) it was usually when investigating compatibility issues with third-party software, such as with file backup programs, a laptop manufacturer's diagnostic that generated verbose logs in HTML format, an odd device driver that communicated with its hardware over the loopback interface and so forth. Issues often started out as an investigation on the operating system side of things, like the Windows Filtering Platform bug ESET came across in Microsoft Windows Vista, but for the most part, it was mostly setting up exclusions for the application(s) or network connection(s) in question. I cannot recall the last time I performed an investigation suspect an operating system level compatibility issue, though (er, unless playing around with the Windows 8 Developer Preview counts).

Is the computer performing the scan with smart optimization at 1:00PM rebooted between scans? The reason that I ask is some of the caching techniques (for lack of a better term) used by the smart optimization algorithm are not persistent. Running smart optimized scans without a reboot between them should show some improvement in scans over time. Anecdotally, I have noted here in the forum that those who seem to benefit the most are avid gamers with many games installed.

You could probably create a custom scan similar to what GFI VIPRE does, listing the specific paths to scan, disabling the scanning of all files and choosing which ones to scan based on their extension and so forth. However, I am not familiar enough with VIPRE to know their exact scanning configurations. Environment variables are not supported in the path specification for current versions of ESET's software, but it is under consideration for a future release.

Regards,

Aryeh Goretsky

 

I just updated EMU to 5162 and see that pseudo environment variables are in the exclusions section of the config.107.xml file. e.g. "%WINDOWS DIR%". I guess ESET is creating their own nomenclature instead of using Microsoft's? Can we get a list of the supported envir var names to use in our own config files?