EAV v 4.2.58.3 problem on Fileserver

Discussion in 'ESET NOD32 Antivirus' started by ICA, Jul 7, 2010.

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

    ICA Registered Member

    Joined:
    Nov 28, 2007
    Posts:
    34
    Hi,

    I have upgraded my Eset Antivirus v 4.2.40 to version 4.2.58.3 on my Windows 2008 R2 x64 fileserver.
    With version 4.2.40 all was working fine.
    After installing version 4.2.58.3 all my users are complaining that opening Office document files (xls, doc, etc) from a share on this server is taking very long. Normally opening a document took less than a second and now it can take up to 15 or 20 seconds.
    I have tested this while disabling the local EAV client (also v 4.2.58.3) on the workstation but that makes no difference. Only when I disable the real-time file protection or add an exclusion for all the shared files or exclude the file extension in the real-time ThreatSense engine then the response on the network is normal again.
    I have also completely removed EAV and installed it again with the default settings, but that also makes no difference.
    When I check the statistics within EAV on the server I see that when a client tries to open (for example) a Word document from a share on this fileserver the server is also doing some things with this file. When I tell the server to keep off all is working fine again, but that cannot be the solution of course.
    Reverting back on the fileserver to version 4.2.40 also solved this delay problem.

    Does anyone have a clue?

    Kind regards,

    Rene.
     
  2. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    Could you please create a Process Monitor log from the moment of attempting to open an Office file on the server and PM me or post the link to it here? Make sure to enable advanced output in the Filter settings in Process Monitor before you start capturing the operations.
     
  3. ICA

    ICA Registered Member

    Joined:
    Nov 28, 2007
    Posts:
    34
    Hi Marcos,

    I have PM'ed you.

    Kind regards,

    Rene.
     
  4. rpremuz

    rpremuz Registered Member

    Joined:
    Jan 18, 2005
    Posts:
    100
    Location:
    Croatia
    ICA, about a year ago I had a similar issue on a MS Windows Server 2003 SP2 (x86) after upgrade to ESET NOD32 Antivirus 4.0.314 Business Edition on both the server and WinXP clients. I waited quite long that ESET fixes the issue.

    A couple of new versions (4.0.417, 4.0.424 and 4.0.437) were released that didn't fix the problem. Eventually, the problem disappeared in ver. 4.0.474, which I still use on my Windows Servers 2003.

    I'd say that on MS Windows Servers the NOD32 ver. 4.* have serious issues if the virus scanning is done by both file server and clients. A "smart" workaround is to configure the NOD32 on the server to exclude shared directories from real-time scanning.

    -- rpr.
     
  5. ICA

    ICA Registered Member

    Joined:
    Nov 28, 2007
    Posts:
    34
    For several days now I have disabled the real-time scan on "file open" action, that solved all the delaying. This is only a temporary workaround and not a fix of course.

    Rene.
     
  6. Balthazor

    Balthazor Registered Member

    Joined:
    Mar 3, 2007
    Posts:
    41
    I'm seeing this same behavior with regard to files on Homegroup computers, running Windows 7 x64 Professional and Office 2010. The 'delay' appears to affect non-Office documents also, like pictures.

    Rolling back to 4.24.40 fixes this error.
     
    Last edited: Jul 16, 2010
  7. The PIT

    The PIT Registered Member

    Joined:
    Sep 4, 2008
    Posts:
    185
    Ah I was going to upgrade perhaps it's not worth doing this. Then thinking about it I disabled scanning on network drives anyway pointless being scanned twice.

    I wonder if it's anything to do with scanning the cache for offline files so effectively they get scanned three times. Once by the host machine the client and then the offline cache is also scanned.
     
Thread Status:
Not open for further replies.