You've described 2 separate issues here, both of which I suggest working on with our Support team in 2 separate service requests. Each will have their own investigative methodologies to work through.
Of the two, the install issue is the simpler to discuss because you'll have install logs left behind by the installation attempt to review (which Support can do of course).
Downgrading the software is not advised but if you feel you must, it will require removing VSE + the Agent (since you say it's 5.x version) + any other ISecG products that are installed which use our shared technology (SYSCore) - then rebooting - then reinstalling the products to their desired version. So, as you can see, we wouldn't wish that upon anybody. Better to identify the problem and determine if there's a simple workaround, while a longer-term solution is followed up on.
We are having the exact same problem, Agent Version 184.108.40.206 VSE Patch 7. Black screen after logon, windows processes being blocked, printing issues, unable to access the VirusScan Console, Agents not talking to EPO etc.
In some instances removing Deep Defender has worked for us, in others it hasn't. I don't have the logs to hand, but Deep Defender was blocking the Agent, as soon as Deep Defender was removed the Agents started talking to EPO again.
Disabling the Access Protection has been another 'solution' as just disabling the policy blocking explorer.exe hasn't always worked.
We spend numerous hours on the phone with McAfee support with no resolution, and have had to re-image a large percentage of clients to get them running again.
A very painful experience.
Just from your comment I can see that you experienced 2 separate and severe issues.
1. You encountered the issue with Patch 7 + the Windows process spoofing rule.
2. You installed Patch 7 on top of Deep Defender.
For #1, we know the issue and workaround: https://kc.mcafee.com/corporate/index?page=content&id=KB86694
For #2, don't do that. Deep Defender is old product that cannot coexist with the underlying technology carried by Patch 7. Reimaging may well be your only path to recovery as it's an unsupported configuration, never tested.
Outstanding. I feel vindicated, and I can share with my team that "I didn't do it" - directly anyway. When I ran the update that caused this, it started a steady stream of Help Desk calls. I had to punt really, really fast. Disabling the policy and pushing it out was a knee jerk immediate resolution (now seen as a workaround) but some machines got stuck on stupid.
I figured out that on a machine with the black screen, if you CTL-ALT-DEL and run Task Manager, you can launch a new task - mcconsole, and disable AP. While you got that up, go into the AP properties and add an exemption for explorer.exe in the Windows Process Spoofing policy. You can then launch explorer.exe via task manager and you got your desktop back.
Thank you for the reply, it is appreciated.
The workaround does not solve the problem. With all the exclusions in place, I am still unable to get to Windows Services or McAfee VirusScan Console the Windows Desktop Taskbar isn't formatted correctly and the Windows Update Service does not run. There are probably other issues, but these are the obvious ones. We have been told that the issue is with a Tier 3 engineer, but this has been two weeks now and we have had to disable Access Protection again and are no closer to a resolution.
Thank you for the information regarding Deep Defender, this has now been removed from our client base.
Ok. Tell me your SR# if you don't mind; it may be on my "to do" list. That list keeps growing faster than I'd like at the moment.
But if you're facing AP violation issues, the remediation is straight forward: Review the AP log file, identify what processes are being blocked, update the policy to exclude what is being blocked.
Sometimes corrective action is complicated by other symptoms, like "the exclusion is not working" or "the policy is not being enforced" etc. All of which can be explored with Support.
Has anyone read this:
If not - you may should do so.
Multiple McAfee endpoint products include a private mechanism to access settings and files protected by self-protection rules. This mechanism is not sufficiently secure and may be misused to access registry keys and files that should be protected from tampering.
When VirusScan Enterprise (VSE) is present on the device, processes that attempt to use this private mechanism are scanned upon access. If the processes are not detected as malware, they could gain access to resources protected by McAfee products
This trusted access bypass vulnerability allows access to resources normally protected by the products. Someone with knowledge of this mechanism can use and exploit it
Please, that can’t be true! Really? “A private mechanism” to bypass security…in a security product? Really? Who had such an idea? Security by obscurity (“s.o. with knowledge of …”)? I really can’t believe this!
The security bulletin is correct. It also explains how to solve the issue; Patch 7.
The reporter was kind enough to allow us to have a fix available prior to going public with their findings. And I have already seen evidence of proof-of-concept code in the field that leverages this back door.
Patching is advisable. But not in haste.