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

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?

 

I would suggest putting in a case with ESET Customer Care so that they can review your server setup and ESET Configuration in detail.

 

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 #.

 

That is definitely not typical. -Sent PM-

 

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?

 

You bet. PM on the way...

 

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.

 

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

 

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.

 

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 .