Little bit of a wierd situation here - not sure if I am missing anything, but brain is baffled.
Enviroment: VSE8.8 (patch 1) with latest DATs and 5400.1158 engine running on Win2k8 R2 SP1. VSE exclusion policy is default process only (1 policy for all processes).
Issue: mcshield.exe spiking to 90% when certain actions carried out on server
Troubleshooting so far: Use of profiler (see https://community.mcafee.com/message/283845), perfmon monitoring during certain server actions, EICAR tests, VSE configuration checks.
Specific exclusion background: So, we have an excluded folder configured, H:\program_files\my_temp_folder\ (+subdirs). Most of the 'action' happens in that folder.
What I have just seen:
- Looking at profiler 10 top files, 8 out of the top 10 files had the extension XYZ. All XYZ files are contained in the excluded folder above
- When looking at the VSE on-access statistics last scanned field, I noticed that on occasion the following is shown: H:\PROGRA~1\MY_TEM~1\XXXXXX~1.XYZ where XXXXXX is 6 hex characters (just what the app does)
- Using notepad, when writing the EICAR test string to a file C:\EICARTEST1.txt, the test string is detected.
- Using notepad, when writing the EICAR test string to a file H:\program_files\my_temp_folder\EICARTEST2.txt, the test string is not detected.
- If I open up H:\program_files\my_temp_folder\ in Windows Explorer, and look at perfmon at the same time (process -> %processor time -> mcshield), when there is a lot of 'action' in this folder, it corresponds with the excessive CPU utilisation of this process.
Now one of the guys I am working with has suggested it is something to do with the 8.3 naming convention being enabled on the server. I have advised that I dont believe this is the case, as 8.3 naming convention needs to be enabled for an ePO install on server 2008 R2, and this would be a little wierd if it were the case. HOWEVER, on seeing what I have seen above, I have to say I am agreeing with him - although I cannot find anything relevant. I also thought that potentially the server may have been reporting physical and not logical mappings for filepaths, however if this were the case, my second EICAR test above would have resulted in a detection surely?
PS - I have also raised a support case for this.