I have an open case with support but wanted to get insights here. We're running ePO 4.6.3 with Global Updating enabled. We recently upgraded from VSE 8.7 P5 to 8.8 P2 and on some of our systems we've experienced hangs/freezes during the DAT file update process. When this happens, the system goes out to lunch and is completely unresponsive for 1-2 minutes. When the system comes back to life, we can see that the OAS timed out and killed the process. We assume that it's during the restart of the mcshield process that hangs the system. In the event long we can see a 5051 event. The thread address is always the same but the object being scanned usually changes. It's odd that it only happens on some systems even once that have fresh XP builds on them. We never saw the issue with VSE 8.7 P5. The issue seems very similar to this post https://community.mcafee.com/message/100166#100166 related to 8.7 and it seemed like the consensus there was ePO Global Updating was to blame. Any ideas on what this could be? Below is an example of the event log error
Event Type: Error
Event Source: McLogEvent
Event Category: None
Event ID: 5051
Time: 1:25:31 PM
User: NT AUTHORITY\SYSTEM
A thread in process C:\Program Files\Common Files\McAfee\SystemCore\mcshield.exe took longer than 90000 ms to complete a request.
The process will be terminated. Thread id : 4036 (0xfc4)
Thread address : 0x7C90E514
Thread message :
Build VSCORE.188.8.131.526 / 5400.1158
Object being scanned = \Device\HarddiskVolume1\WINDOWS\WinSxS\Policies\x86_policy.8.0.Microsoft.VC80.C RT_1fc8b3b9a1e18e3b_x-ww_77c24773\8.0.50727.6195.policy
We are experiencing similar problems, except we upgraded from VSE 8.8 P1 to P2.
McAfee hangs shortly *after* the daily update process has completed, and all windows end up 'Not Responding' for about a minute and a half, after which we receive the same event log message as you and the system is fine.
This happens on a clean install as well, with VSE 8.8 P2 repost installed directly (no upgrade).
Will let you know if we get anywhere on our McAfee case, I think we are up to Level 4 on the escalation ladder now...!
P.S. Some of the things already attempted to resolve:
I have also independently tried changing the DAT update time - ours is not using Global Updating but instead a task which is set to 'Run if missed' 10 minutes after the system boots. I tried changing this to 5 minutes in case it was conflicting with another system process but this didn't help.
We can see *very* clearly in the logs that the issue only occurred after Patch 2 was installed (the dates match up perfectly) but McAfee are insistent this is not the cause...
Have you followed the best practice guides for VSE? I had terrible performance with VSE until I followed that and excluded a few more VSE exe's from being scanned. Might be worth a look to check your getting the best performance out of your systems.
Yep, that's PD22940 described above. We've got pretty much all of this implemented already, certainly the performance related stuff. Didn't seem to do any good.
What's odd for us is that it does not occur on every machine. Only a few machines have the problem but we definitely did not see this until we upgraded our VSE 8.7 P5 to 8.8 P2. It just seems like there is some sort of contention that occurs when McAfee tries to scan the file system while there are other system processes locking the files. I don't believe excluding would help because it just seems like random files are causing the problem.
As far as the best practice guide, process on enable is turned off and we do not scan archives. Again it's the exact same configuration we had with 8.7 as we used the mgiration tool to move the policies over. I sent McAfee support a process monitor scan last week that they are currently analyzing.
It may be related to what the user is doing on the system at the time - hence why only some machines are displaying the problem.
We also sent a Process Monitor scan across a couple of days ago and are waiting for a response.
Glad to hear it's not just us experiencing the problem!
Minkus - did you ever hear back from support? They sent me the following KB article https://kc.mcafee.com/corporate/index?page=content&id=KB67648 to identify if the OAS was the cause of the problem which I already knew. Excluding the files from OAS scanning of course fixes the problem but I don't know that it really proves because it seems that most of the time a different process is responsible for the OAS conflict. I have a feeling that entering exclusions will just result in other processes contending with the OAS. They still have not commented on the procmon I sent.
I got the same article, and also found that excluding all files works (at least the one time I tried) - but of course this doesn't prove anything and the problem is intermittent anyway.
Our event logs are very clear that the issue started occurring when we installed Patch 2, and once I pointed this out again and had a bit of a moan I got up to Tier III who are now investigating for me.
I would suggest you push this angle as well - if you can install 8.8 Patch 1 onto a machine, demonstrate that the problem does not occur, and then upgrade to 8.8 Patch 2 and demonstrate that it does, you may have better luck in convincing them to escalate.
Further status update: The chap at Tier III has asked me to enable LogLevel 8 for McAfee Agent (KB56207), set up debug logging for VSE, set up etltrace, Process Monitor, and replicate the error. Once this is done I am hopeful it'll get up to the engineering level.
Will let you know how I get on.