ENS Exploit Prevention blocking processes but not logging (IE not launching and black desktop)

[stevenheritage]

The issue is first noticed as Internet Explorer or another browser not launching on a computer.  When the user restarts, they typically do not have the GUI desktop upon Windows logon (the shell, explorer.exe, will not run).  We can launch Task Manager and run a new task (either explorer.exe or iexplore.exe) and watch the process spawn, but die very quickly.  Exploit Prevention (and ENS as a whole) is not logging any threats or blocks, but when we disable Exploit Prevention (via policy update in ePO), the issue is no longer present.  Because a threat or block is not logged, I can not pin this on any specific ID.  I have an open SR, but Support has not been helpful and appears to not have even reviewed the MER or logs that I have sent in.

Reviewing the Debug log for Exploit Prevention, I can see several Warnings when I try to spawn the iexplore or explorer process:
12/19/2018 10:08:00.443 AM mfetp(7628.1928) <SYSTEM> TmpLogger.Gbop.Debug: [s] Warn : 0x1dcc,788 AddJobEx: pid 0x3058, Already in the job map with job state 0x1

Additionally, there are occasional errors in the debug log as well: 

12/19/2018 10:08:00.486 AM mfetp(7628.2672) <SYSTEM> TmpLogger.Gbop.Debug: [s] Error: 0x1dcc,a70 Error: HamQ error code: 0xd

I saw another post about this, however that was referencing VMs.  For me, this issue is manifesting across a few different physical machines.  Updates to ENS and McAfee Agent do not correct the issue.

MA: 5.5.1.388

ENS: 10.6.1

OS: Windows 10 v 1803 & 1809

Anyone else experiencing similar issues or have any suggestions?  I'm preparing to go through each rule in the ExP policy to see if I can narrow it down.  Would be helpful is McAfee Support would actually work on the SR.

[jess_arman]

@stevenheritage We are actively investigating this issue and are in progress of narrowing down what aspect of Exploit Prevention may be involved. You mention you have a case with Support, could you please let me know what your SR # is? 

Your idea of progressive disabling of Exploit Prevention rules would be a good, manual way to get started in narrowing down the potential source.

Was my reply helpful?

If this information was helpful in any way, or answered your question, will you please select "Accept as Solution" in my reply, or give kudos as appropriate, so together we can help other members?

[stevenheritage]

@jess_arman

SR # <4-19411257351> 

Setting all the GBOP Exploit Prevention rules to report only did not resolve, so that's curious.  I'm wondering if something is happening with the integration with Windows AMSI.  Might this behavior be occurring if the AMSI stream is being read by another process when McAfee tries to access?

[jess_arman]

@stevenheritage Thank you.

Definitely an interesting hypothesis. Since setting them to report only didn't change the behavior, there's likely to be data that could be gained by review of the trace data. I'll review the SR and will work with the technician to get some next steps together for investiation.

Was my reply helpful?

If this information was helpful in any way, or answered your question, will you please select "Accept as Solution" in my reply, or give kudos as appropriate, so together we can help other members?