Eset AV and Lavalys Everest

Discussion in 'ESET NOD32 Antivirus' started by Stalks, Apr 5, 2009.

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

    Stalks Registered Member

    Joined:
    Jan 13, 2008
    Posts:
    28
    Eset AV and Lavalys Everest [SOLVED]

    Intel E8400 (Core 2 Duo @ 3Ghz)
    Lavalys Everest 5.00.1650
    ESET NOD32 4.0.417.0

    If I enable logging in Everest so that it regularly writes to an HTML file, ESET NOD32 will use 100% of 1 CPU and Everest will become very unresponsive.

    If I disable "real-time file system protection" the symptoms cease.

    I have tried adding exclusions to both Everest's program directory and the directory it is writing the HTML file to.

    FIXED: Lesson learnt. Network shares are excluded via their UNC paths. eg, \\server\share\path\file
     
    Last edited: Apr 5, 2009
  2. jimwillsher

    jimwillsher Registered Member

    Joined:
    Mar 4, 2009
    Posts:
    667
    I'm not experiencing this with Everest 5.01 and ESET 4.0.417. Any particular logging settings I need to tick?
     
  3. Stalks

    Stalks Registered Member

    Joined:
    Jan 13, 2008
    Posts:
    28
    I enclose a copy of my "everest.ini". It is renamed to "everest.ini.txt" to bypass the extension filter of the forum. This has all my settings. I have masked domain names with "dev.null".

    I write logs to a network share mapped to S:\. Logs are saved to "S:\Everest Logs\".

    I'm thinking that perhaps Everest treats the HTML file that is being written to as a web page and attempts to scan it regardless of file based exclusions.

    My log file is 76MByte so I can imagine it would take some time to scan. Also, whilst it is scanning the file it would block Everest from finishing its 'write' action which would then explain the Everest interface locking up as its process has been blocked awaiting I/O.

    I'm going to try disabling just web page scanning and see if this is the cause. I'll also rename the current log so a new one is created and see if the cause is the time spent on scanning such a large file.
     
    Last edited: Apr 5, 2009
  4. Stalks

    Stalks Registered Member

    Joined:
    Jan 13, 2008
    Posts:
    28
    If I disable Web Access Protection the problem still occurs.

    If I rename the current 76MByte log file so that Everest creates a new one, I no longer suffer from high CPU usage. I guess I can setup a system to rename the file regularly so it doesn't get so large.

    I suppose as the file is being accessed over the network, the time taken to scan the file is longer than the interval between writes, causing a backlog of events.

    If you have a network share to place the log file, you can reproduce this by manually creating a 50MB file, doesn't matter what the text is. Everest just appends to the end of the file at each log interval.

    I think the problem here is that the exclusion list isn't working. For the time being I shall monitor the file size of the log, or just disable logging.
     
  5. jimwillsher

    jimwillsher Registered Member

    Joined:
    Mar 4, 2009
    Posts:
    667
    For your exclusion list, instead of excluding S:\ try excluding \\yourservername\yourpath

    I found (to my cost!) that I was excluding some network paths by the drive letter, but the statistics screen was showing the UNC path names.
    Just a thought...
     
  6. Stalks

    Stalks Registered Member

    Joined:
    Jan 13, 2008
    Posts:
    28
    Bingo!

    Thanks to your "just a thought" the situation is resolved!

    Running "net use" at the command-line reveals the exact pathname of the share. This plus the everest log directory with a suffix '*' has fixed the problem for good.

    Thank you, jimwillsher. :thumb:
     
  7. jimwillsher

    jimwillsher Registered Member

    Joined:
    Mar 4, 2009
    Posts:
    667
    Nice one :)

    It's a shame the exclusions screen doesn't handle this automatically. After all, what's the point in mapping drive letters to UNC paths if you need to deal with UNC paths in the exclusions screen...


    Jim
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.