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?