Problems excluding files from backups...

Discussion in 'ESET NOD32 Antivirus' started by Adam H, Jun 29, 2009.

Thread Status:
Not open for further replies.
  1. Adam H

    Adam H Registered Member


    I'm having a problem at the moment with Eset Antivirus 4 trying to exclude files from real time scans.

    I have attempted the following:

    a) Gone into Advance Setup-Real Time System Protection and pressed the SETUP button. Ticked the SCAN ALL FILES button, and then added the extentions I wanted excluded (both with decimal and without such as ".LOG" and "LOG" without quotes).

    b) Gone into the same location and tried by pressing the default button. (Turns off SCAN ALL FILES and only scans those listed. I made sure the files I wanted excluded were not in the list).

    However, when I view Protection Status-Statistics, I still see the files I want excluded show up in the 'Scanned Object' section, regardless of which of the above I try.

    Can anyone tell me why this section is not working or what I am doing wrong?

    Thanks & Regards

  2. Marcos

    Marcos Eset Staff Account

    It means the file is being accessed and processed, but it shouldn't be actually scanned.
  3. Adam H

    Adam H Registered Member

    Hi Marcos,

    Thanks for that. It just had me confused when I was seeing the file listed as being scanned. Could I suggest that future versions of NOD have the label 'Object Scanned:' changed to 'Access and Not Scanned:' for files that aren't being scanned.

    Stating that the file has been scanned when it's not is a little confusing. ;)


  4. jimwillsher

    jimwillsher Registered Member

    This confused me too.

    I'll reiterate my request for a logging facility to be added to ESET:

    C:\Logs\ESET_RTScanner.log :

    29/06/09 14:36:01.29 C:\program Files\ABC1.exe > Scanned, Clean
    29/06/09 14:36:01.31 C:\program Files\ABC2.exe > Scanned, Clean
    29/06/09 14:36:01.34 C:\program Files\ABC3.exe > Scanned, Clean
    29/06/09 14:36:01.36 C:\program Files\ABC4.exe > Scanned, Clean
    29/06/09 14:36:02.51 C:\program Files\ABC5.exe > Scanned, Clean
    29/06/09 14:36:02.53 C:\program Files\ABC6.exe > Scanned, Clean
    29/06/09 14:36:02.54 C:\program Files\ABC7.exe > Scanned, Clean
    29/06/09 14:36:02.56 C:\program Files\ABC7.dat > Ignored by exclusion
    29/06/09 14:36:02.57 C:\program Files\ABC8.exe > Scanned, Clean

    VERY useful when diagnosing slow systems, slow data access, defining exclusions etc. In fact very VERY useful

  5. Marcos

    Marcos Eset Staff Account

    This kind of logging would cause >95% slow downs of system performance.
  6. jimwillsher

    jimwillsher Registered Member

    Correct....but if it's disabled by default, and only enabled by somebody diagnosing problems, it could save > 95% wasted time trying to work out why certain applications are really slow when ESET is running.

    Think of it as the Message Tracking facility in Exchange, or Verbose Logging in postfix. At present you either have to be a mindreader or an expert in black magic, since ESET's logging is currently woeful. Embarrassingly so, for a professional product.

  7. Marcos

    Marcos Eset Staff Account

    Enabling a kind of logging that might lead to a total system lock up wouldn't do any good to anyone. You can use Filemon or Process Monitor from Microsoft to find out what files are being accessed by ekrn.
  8. jimwillsher

    jimwillsher Registered Member

    It would only lead to system lockup if it was very badly written code. Hmmm..............

    Take a look at Microsoft ISA, which shows full logging for all permitted and denied firewall packets. Are you telling me that a system that processes 1000's of packets per second can happily log everything to an MSDE database, and yet something that writes simple one-line entries to a log file perhaps dozens of times per second (not thousands) will cause lock up?

    Same with Firewall1. Same with IIS.

    Clearly I'm banging my head against a brick wall here, and you're not going to take this suggestion forward. But you're also clearly missing the point. A very sad stance Marcos, and clearly one with no technical backing.

Thread Status:
Not open for further replies.