NOD32 takes too long to examine some files

Discussion in 'ESET NOD32 Antivirus' started by sosl, May 19, 2010.

Thread Status:
Not open for further replies.
  1. sosl

    sosl Registered Member

    Joined:
    Mar 21, 2009
    Posts:
    4
    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.
     
    Last edited by a moderator: May 19, 2010
  2. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    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.
     
  3. vtol

    vtol Registered Member

    Joined:
    Apr 8, 2010
    Posts:
    774
    Location:
    just around the next corner
    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
     
  4. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    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.
     
  5. vtol

    vtol Registered Member

    Joined:
    Apr 8, 2010
    Posts:
    774
    Location:
    just around the next corner
    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...

    19-05-2010 19-33-00.png
     
  6. sosl

    sosl Registered Member

    Joined:
    Mar 21, 2009
    Posts:
    4
    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.
     
  7. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    Using an internal debug tool.

    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.

    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.
     
Thread Status:
Not open for further replies.