This article explains why some software processes must be added to the ENS/VSE Low-Risk list with a Read or Write exclusion. It also offers general guidance on potential conflicts between ENS/VSE and third-party application software. The article isn’t specific to any particular non-McAfee application.

Some application processes are known to generate high Input/Output (I/O) when running. These processes also compete with ENS/VSE scanning activities. Generic examples of such programs are backup applications and encryption software. The same can apply for custom applications that have been designed internally or by third-party software vendors. 

Issues might occur if an application is running high I/O, which usually involves many file read/write events or registry queries per millisecond. Since ENS/VSE processes the I/O, the third-party software or custom application can experience performance issues or errors. The issue occurs in many scenarios such as the following examples:

• Third-party software is interested in the same I/O that ENS/VSE is trying to scan or the opposite way. 
  
  Example: A backup application reads from location A and writes to location B. In this case, ENS/VSE scans the file being read (Scan on Read). ENS/VSE also scans the file that the backup application writes or modifies (Scan on Write). Some applications might even cause sharing violations to occur, when one application prevents the other from getting access, leading to other symptoms.
   
• Third-party software generates thousands of registry or file events per second to perform an operation. In this case, ENS/VSE processes each of the events, adding about a millisecond of overhead per event. It’s fast, but multiplied by thousands, and equates to visible user impact. The reason isn’t because ENS/VSE is taking too long, but because the application makes so many requests per second. 
   
• Third-party software has low tolerance for timeouts or delays. In other words, the third-party software has critical time-based dependencies where actions are assumed to be completed within a time frame. If not completed, the application exhibits unexpected behavior. You see this scenario if the software hasn’t been well stress-tested with antivirus software or other filtering software. Or, you see it if the software relies heavily on asynchronous operations which are assumed to have been completed.
   
• There are system hardware specifications, operating systems, and installed programs that can also affect if the I/O overhead becomes noticeable. Microsoft Process Monitor is useful for investigating and analyzing the amount of I/O generated by a third party and ENS/VSE. For more information, see: KB72766 - Utilities used for troubleshooting. Usually, issues that arise from these types of issues can be resolved by adding the necessary file, folder, or Low-Risk processes exclusions.