EAV 4.2.71.2 causing perforce to crash on 64-bit Windows Server 2008 R2

Discussion in 'ESET NOD32 Antivirus' started by xmcspc, Mar 7, 2011.

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

    xmcspc Registered Member

    Joined:
    Mar 7, 2011
    Posts:
    5
    My company is running the latest release of the Perforce SCM server (64-bit executable, version 2010.2/284433) on 64-bit Windows Server 2008 R2.

    Our Perforce server has been crashing and with the help of Perforce technical support I have narrowed the cause down to EAV. Perforce is being blocked from reading/writing to it's database files by EAV. Whenever EAV real-time filesystem protection is enabled, Perforce logs errors like the following and eventually crashes:

    Code:
    Perforce server error:
        Date 2011/03/04 08:38:36:
        Operation: user-dirs
        Operation 'open' failed.
        Database open error on db.view!
        open: db.view: The process cannot access the file because it is being used by another process.
    
    Ok, fine... I get that. EAV needs to intercept file operations in order to provide protection. I'm ok with that. Here's what I'm not ok with. I have told ESET to leave Perforce alone and it's not. I have done the following:
    • Added the Perforce executable to the "exclude" list
    • Added the Perforce database folder (*.*) to the "exclude" list
    • Disabled epfwwpfr.sys according to SOLN2567 on the ESET website
    • Set scanner options to only scan specified extensions according to SOLN2144
    • Disabled anti-stealth and self-defense
    Using Procmon, I can confirm that when real-time protection is enabled (with all of the above in place), Perforce is getting sharing violations when attempting to open it's database files. Why? Not only have I told EAV to exclude the database files, the list of extensions to scan does not include the extentions Perforce uses (see above error where the file in question has a ".view" extension).

    As soon as real-time protection is disabled the errors stop and Perforce is stable. Re-enabling real-time protection causes errors and instability to re-occur.

    Are there other settings to tweak? Some other way to make EAV "obey" the exclusion list?
     
  2. ThomasC

    ThomasC Former ESET Support Rep

    Joined:
    Sep 8, 2008
    Posts:
    209
    I would suggest putting in a case with ESET Customer Care so that they can review your server setup and ESET Configuration in detail.
     
  3. xmcspc

    xmcspc Registered Member

    Joined:
    Mar 7, 2011
    Posts:
    5
    I have. Last week. To date I have had no contact from ESET customer care. Not even an ackowledgement of my submission or a case #.
     
  4. ThomasC

    ThomasC Former ESET Support Rep

    Joined:
    Sep 8, 2008
    Posts:
    209
    That is definitely not typical. -Sent PM-
     
  5. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    I'd be interested in checking the ProcMon log you created. Would it be possible for you to upload it somewhere and pm me the link besides replying to ThomasC?
     
  6. xmcspc

    xmcspc Registered Member

    Joined:
    Mar 7, 2011
    Posts:
    5
    You bet. PM on the way...
     
  7. xmcspc

    xmcspc Registered Member

    Joined:
    Mar 7, 2011
    Posts:
    5
    Posting an update for anyone who might be following this thread.

    ESET support has asked me to make changes to my exclusion settings. I am now excluding:
    Code:
      C:\Program Files\*
      C:\Program Files (x86)\*
      C:\Users\*
      E:\ProgramData\Perforce\Database\*
      E:\ProgramData\Perforce\Journal\*
    
    The result is the same. With real-time scanning disabled, we ran for 2 weeks without a single error in the perforce log file. As soon as EAV real-time scanning is re-enabled it's only a matter of hours before perforce logs errors stating it can't open it's database files and crashes.

    The database files are all in the E:\ProgramData\Perforce\Database folder.
     
  8. duijv023

    duijv023 Registered Member

    Joined:
    Feb 16, 2006
    Posts:
    230
    Location:
    Rijnsburg, Netherlands
    I am seeing the very same things with a visual foxpro database driven application.

    There it says that "blabla".fpt cannot be opened as it is in use by another user, there are also problems with .CDX (db index) files
    Perhaps we may be dealing with the same isssue here.

    In Holland we have opened a support ticket, I will mention tis post to them also

    Greetings from Holland
     
  9. xmcspc

    xmcspc Registered Member

    Joined:
    Mar 7, 2011
    Posts:
    5
    It's been over two months and ESET support has totally dropped the ball on this. I've provided ESET with logs, system config, etc, and they have gone completely quiet. I have made several inquiries to ESET customer support and got no response.

    The last test I performed was to excluded EVERYTHING by setting an exclude pattern of C:\* and E:\*. This should stop ESET from interfering with all files on my system, but it doesn't. ESET continues to lock and hold Perforce database files open whenever Perforce tries to open them.

    Very disappointing... very, very, bad behaviour from NOD32 and very, very bad customer service.
     
  10. dmaasland

    dmaasland Registered Member

    Joined:
    Nov 10, 2010
    Posts:
    468
    Do you have a case running here in holland? I've checked our ticket system and cannot find a reply with the mentioned logs, so perhaps something has gone wrong with recieving them. If you are indeed the one who has this ticket running in NL, please contact me directly via PM :).
     
Thread Status:
Not open for further replies.