NOD32 takes too long to examine some files

[sosl]

Some files - large executables or archives containing multiple files - take 1-2 minutes to scan. Example: -http://download.gigabyte.eu/FileList/Driver/motherboard_driver_audio_realtek_azalia.exe-
(This one took 2 minutes, and contains 302 scanned objects, but the majority of time was spent on one file - Realtek/Vista64/AERTSr64.exe)

This is either immediately after downloading or an on-demand scan.

This is extremely slow - can I reduce the scan time somehow?

Thanks.

p.s. NOD32 version is 4.0.474.0, and is part of ESET Smart Security suite.

[Marcos]

I couldn't find a file that takes long to get scanned. Here are files with the scan time > 200 ms:

ChCfg.exe (0.250000 s)
engine32.cab (0.265000 s)
MSHDQFE\Win2K3\us\kb888111srvrtm.exe (0.235000 s)
MSHDQFE\Win2K_XP\us\kb888111w2ksp4.exe (0.234000 s)
MSHDQFE\Win2K_XP\us\kb888111xpsp1.exe (0.250000 s)
MSHDQFE\Win2K_XP\us\kb888111xpsp2.exe (0.250000 s)
Vista\AERTSrv.exe (0.219000 s)
Vista\HDALC.inf (0.203000 s)
Vista\mbfilt32.sys (0.219000 s)
Vista\RtHDVBg.exe (0.250000 s)
Vista\RtHDVCpl.exe (0.594000 s)
Vista\RtkAudioService.exe (0.234000 s)
Vista\RtkNGUI.exe (0.531000 s)
Vista\RTKVHDA.sys (0.422000 s)
Vista\RtlUpd.exe (0.453000 s)
Vista\RTSndMgr.cpl (0.218000 s)
Vista\SkyTel.exe (0.234000 s)
Vista\vncutil.exe (0.250000 s)
Vista64\SkyTel.exe (0.250000 s)
WDM\Alcmtr.exe (0.219000 s)
WDM\AlcWzrd.exe (0.297000 s)
WDM\ALSndMgr.cpl (0.204000 s)
WDM\HDALC.inf (0.203000 s)
WDM\MicCal.exe (0.343000 s)
WDM\OAO17Afx.sys (0.218000 s)
WDM\RTCOMDLL.dll (0.219000 s)
WDM\RTHDCPL.exe (1.515000 s)
WDM\RtkAudioService.exe (0.250000 s)
WDM\RTKHDAUD.sys (0.641000 s)
WDM\RTLCPL.exe (0.625000 s)
WDM\RtlUpd.exe (0.438000 s)
WDM\RTSndMgr.cpl (0.250000 s)
WDM\SkyTel.exe (0.250000 s)
WDM\SoundMan.exe (0.234000 s)
WDM\vncutil.exe (0.250000 s)

Setting a size limit for scanned objects to, let's say, 10-20 MB would mitigate the problem.

[vtol]

Originally Posted by Marcos

Setting a size limit for scanned objects to, let's say, 10-20 MB would mitigate the problem.

yeah, on one hand the users are supposed to better keep the default settings, such being advised in the forum so often, then however when there is problem with the default settings the user is being advised to tinker with the advanced settings to work around NOD problems. it is really hard to keep up where to keep the default settings and where to tinker, not that in some case that might contradict also the defence purpose of NOD

[Marcos]

So you suggest to set a size limit for scanned files by ESET for all users as default? You cannot expect a security program to extract and scan files from an archive faster than compression tools.

[vtol]

Originally Posted by Marcos

So you suggest to set a size limit for scanned files by ESET for all users as default? You cannot expect a security program to extract and scan files from an archive faster than compression tools.

then what is the default set by NOD, the entire archive? And no, I do not suggest as such. Just I find your reply inappropriate in a way by telling the person 'hey, don't care how long it takes your end, my end it does work ok'. Perhaps the customer got a different and even less powerful machine than yours, hence it would be better to tell that in such case it might take a little while to get large archives scanned entirely as NOD depends on the compression codecs or alternatively in order to shorten the scan time to cut down on the archive size for NOD to scan. Yet latter method eventually lowering the protection by NOD as obviously only a portion of the archive gets scanned. Not everybody out there has all the technical background you got...

[sosl]

Marcos, how did you get the exact timings of individual file scans?

Also - is there any problem with disabling archive scanning altogether?
Isn't it enough that only when a file is executed it is scanned? (I understand there may be non-executables which contain code, such as dlls, but they can be scanned only when touched from inside a running process, no need to scan them while offline, right?)

Another thing is that NOD32 scans every file when the system touches it (I think), even when just copying.
At least I noticed a difference in copy time when NOD32 is enabled and when it is disabled.
So the same question as with the archives - why scan them when they are not executed?

Thanks.

[Marcos]

Originally Posted by sosl

Marcos, how did you get the exact timings of individual file scans?

Using an internal debug tool.

Also - is there any problem with disabling archive scanning altogether?

When speaking about archives and real-time protection we mean self-extracting archives that are the only type of archives scanned by real-time protection upon creation. The reason why certain options / methods are used only for newly created or modified files is that performance-intensive operations like decompression or emulation by advanced heuristics may take time to complete, depending on the file structure and its size. By default, no limits are set but we allow users to define the limits themselves and thus achieve reasonable balance between protection and performance.
It's clear that unpacking takes some time; even if you use a compression tool like WinRAR, 7-Zip, etc. to decompress an archive it's not done within an eye blink and the process of decompression takes some time.

Isn't it enough that only when a file is executed it is scanned? (I understand there may be non-executables which contain code, such as dlls, but they can be scanned only when touched from inside a running process, no need to scan them while offline, right?)

Another thing is that NOD32 scans every file when the system touches it (I think), even when just copying.
At least I noticed a difference in copy time when NOD32 is enabled and when it is disabled.
So the same question as with the archives - why scan them when they are not executed?

The granularity of the program allows users, who often copy binaries and experience a slowdown, to disable performance-intensive methods, such as advanced heuristics or runtime packers, for newly created/modified files and use them only on file execution. In this case, the only drawback would be the delay upon executing files which may or may not be noticeable, depending on the files you run. At least it's worth a try so that you see how it works for you.