If you have really slow performance with certain HTML files, you should open a support call with McAfee, and provide samples of the files to them per their instructions.
Sometimes the optimisation of dat drivers can be improved when McAfee Labs are able to see files that take a long time to be scanned and analyse which driver is causing the issue.
1 of 1 people found this helpful
There are a couple of possiblities that have worked for others.
1. If you haven't already, make sure you have the current 5400 scan engine installed.. It fixes some of the HTML and Cookies scanning issues.
2. Most importantly, very few users need to have "Network scanning" enabled in the "On Access Scan" settings.. Since the file in question appear to be on a network share, UNCHECK the "Network" box and it should help your particular problem.
Hope this helps.
Thanks for the replies but no solution as yet I am afraid.
Unfortunately due to the nature of the files and the network they are located on I cannot and will never be able to provide Mcafee, or anyone else either for that matter, copies of them to try and find the reason for the poor performance.
Also I already have the 5400 engine installed and have 'network scanning' turned off.
The files open very very slow even when opened directly from the server on which they reside. The fact that they still open very slowly even when I exlude the entire share on which they sit from 'on access scanning' leads me to think that it is not necesarily the files themselves but some other file or service which they call on opening.
1 of 1 people found this helpful
The changes in behavior you described in this paragraph are intriguing:
Suprisingly if they turn it off before they open the main menu page, even when EPO turns 'on access scanning' back on again after 5 minutes or so everything continues to work perfectly for all pages opened after that from hyperlinks within the first page. However if they turn off 'on access scanning' after the first menu page is opened then pages are unusably slow even if the scanning stays off permanently.
It suggests to me a potential interoperability issue with a 3rd party driver.
And this comment from your last post suggests the way forward:
The files open very very slow even when opened directly from the server on which they reside
I recommend collecting ProcMon data on the latter, and evaluating from the capture whether there is an undue level of file or registry activity.
- If file activity is high, inspect one of the File I/O records. Look at the stack - see what kernel level drivers are listed. Anything other than MSFT or MFE drivers?
- If registry activity is high, is VSE's buffer overflow feature enabled? And if so, be sure to have VSE 8.7i Patch 2 so you can test with only BOP disabled, instead of the entire OAS.
When you disable OAS, you disable Access Protection and Buffer Overflow Protection also. This can be narrowed down further, but you'll need Patch 2 (or Patch 1 with HF 464768) to make it easier to narrow down.
You don't always need the *exact file* that causes the issue to submit. As long as you can provide a file which causes the issue it should be able to be escalated.
So confidential data in the HTML can be changed - as long as the error still occurs.
I also agree that there seems to be something else going on that may not be related to McAfee.
I am running Patch 2 at the moment so should be no problem to try turn off AP and BOP individually and see what happens.
I will also have a play around with procmon and see if anything looks particularly busy.
I take your point regarding possible files for submission to mcafee. Unfortunately there is a lot of confidential info embedded into every page and which would cause an awful lot of work to try and remove whilst keeping the symptoms.
As an extra bit of information. I just received a reply back from the developers of the webpages in question. They fully acknowledge the problems when used in conjunction with Mcafee but refuse to do anything about it. This is because the primary(and only other) customer who uses it has a different AV solution on their networks(I dont know what) which has no issues opening the files.
Also when I said earlier that the files opened slow on the server on which they were hosted. I shuold have mentioned that if I turn of OAS then they open just fine as well.
1 of 1 people found this helpful
"Also when I said earlier that the files opened slow on the server on which they were hosted. I shuold have mentioned that if I turn of OAS then they open just fine as well."
I might suggest that some basic performance tuning is in order. Consider turning Off 'When reading from Disk' and consider whether .jar files should be excluded in the list of extensions as this 'may' cause significant slow down while each is extracted.
Let us know if this is helpful.
Did some additional testing by turning off BOP on its own but was no change in symptoms.
I already had exclusions for .jar files and a few others so there was no problem there.
I then ran some Procmon traces as suggested by William Warren. They showed a huge amount of both File activity as well as registry activity with OAS on compared to turned off. Apart from the fact that the Mcshield service was the cause of most of the activity it was hard to pin down exactly why it should be so.
I then re-tested again but this time with script scanning turned off. I had done this before, or thought i had, but obviously messed something up previously as with script scanning turned off the problem disapears. I then turned script scanning on again but put a specific script scan exclusion of iexplore.exe which was also fine.
Out of interest the difference between mcshield activity with script scanning turned off compared to on is quite amazing. For example to open one link with scanning on took mcshield.exe 60k+ file events (about 4MB/s IO throughput and 1000 file I/O events per second for 50 secs) and 9k registry events with roughly 90% CPU being used for 50 seconds before the link opened. With it turned off (or on with the exclusion) mcshield took 755 file events and only 3 registry events over less than 2 seconds to open the exact same link.
Having iexplorer.exe exluded from script scanning is not the best solution but its better than turning off OAS or script scanning completely. Unless anyone else has any ideas to narrow the problem down further I think I am going to have to leave it as it is now.