This issue is still happening in my shop as well. We are running EPO 4.5, MA 4.5.1270 and VSE 8.71 P2 + hotfix 517265. Not all machines have the hang, but the same machines have the hang almost daily. I have removed/reinstall agents, VSE, still no change in behavior. DAT update dates 2-3 minutes (that's fine) but then engineserver.exe buries the machine for another 8-10 minutes. I saw a machine yesterday with over 1gb of pagefile used and the machine had 1gb of total system memory so you know how well it was acting. Seriously, do I need to just NOT update dats except for once a week or something? It also doesn't matter what OS I am running its not picky. I have Windows 7 64-bit and Windows XP, same behavior happens at the same time on both OS'es. Is this something a patch 3 might finally resolve for 8.7? I sure hope so!
I haven't seen any posts on this in a while. I'm seeing the exact same issue occur in our environment. As of yet I have not made the recommended change of turning off scanning the processes on enable. I was hoping that someone might have some more information on this and if there is anything else to address the issue.
Still happening. Thought I'd fixed it by removing 'send-to' entries from my profile but the joy was short lived. Seeing it on a few PCS around the world in our company and have changed update times to be during a break for them rather than talk to McAfee again. Spent about 6 weeks getting nowhere really last year and don't want to go though it all again. Patch 3 for 8.7 should be out March so I am going to wait for that and if it does not help, I will address it again.
engineserver.exe issue should be fixed in patch4 per KB59962(June 2010)
disabling process on enable should fix the hung system on updates issue, will be perm fixed and ok to keep that enabled by the NEXT VSE release VSE 8.7.1
hope this helps
Here's what I know -
Patch 4 will include resolutions to 2 issues that are relevant to this thread:-
1. EngineServer memory usage climbing to excessive levels.
A proof-of-concept build has been proven to solve one aspect of the issue, specific to use of EmailScan. We still haven't tracked down lingering reports of high memory usage in EngineServer once our POC code is in place; whatever the condition, it is rare, and it does not appear related to EmailScan.
2. A fix for an issue with creating the mferuntime.dat file.
This symptom is the key contributor of why some systems are seen to take 10+ minutes to complete an update.
Post update, the Engine tries to create a memory mapped file to help reduce memory footprint and improve performance, this file is mferuntime.dat (See article KB65459).
What we have found to occur is the creation of the file sometimes encounters sharing violations (one or more of the scanners hasn't released it) and the product enters a loop of retrying to create this file. This file is created based on information from our DAT signatures, and so this data is reread each time the loop repeats. It can be very noticeable to users by way of sluggishness of the system.
Here's what I know will help alleviate the stress of updates, until these issues are resolved:-
1. Tweak the Agent thread priority as described in KB53690.
2. Disable scanning of Processes on Enable - this is only intended for environments who abide by the "Maximum Security" setting of the product
3. Utilize the Low Risk On-Access Scanner profile, placing McAfee processes into it (mcscript_inuse.exe, naprdmgr.exe, frameworkservice.exe), with scanning disabled (understand this is a temporary measure)
4. Perhaps the most significant change for relief, lower the priority of our On-Access Scanner from its default "High" to "Normal"
This is done by creating/setting a DWORD registry flag named "RunAtNormalPriority" to 1, under HKLM\Software\McAfee\VSCore\On Access Scanner\McShield\Configuration, and restart the service.
This change is normally done only under direction by McAfee Support. It does not reduce your security in any way, but it's plausible you could see an increase in scanner timeouts because McShield will be getting equal CPU time as your other Normal thread priority processes instead of a lion's share. And this means if experiencing the mferuntime.dat loop, your system will still be pretty responsive during that time.
Patch 4 is expected mid-June if able to stay on schedule. Living in the dynamic world of McAfee Sustaining, all things are subject to change.