if a product does not work, deactivating the feature must not be the solution. This sucks completely. We need a support level which is able to understand the problem and is able to figure out what is going on the provide a solution or a functioning product.
if a product does not work, deactivating the feature must not be the solution.
Yes, I agree.
But you made a leap here; nobody is saying that disabling a feature is a solution. Disabling a feature is a viable option that is available to you for the purpose of maintaining business continuity.
With any good Patch adoption plan there will be a business continuity plan. A plan that caters for "What if". And most often that may be uninstalling the product, then reinstalling the last known good build that was used. And depending on the issue that's impacting the business you might have enough data to refine the plan, or to engage an alternate contingency plan because other criteria was met. Disabling Access Protection for example, if it meant restoring business continuity immediately, is a viable option for anybody to consider or to have on hand in their "business continuity playbook". Maybe it isn't for you, and that's OK too, it just means you'd choose a different plan.
These aren't solutions. That comes later, perhaps much later.
I took a personal day on Friday, and an initial scan of my Inbox tells me our engineering team have confirmed a bug after following the leads from the behavior you reported.
When I get into the office tomorrow and have an opportunity to digest the details of their findings I can post them here to try and bring closure to this portion of the thread.
But just so you know, if Engineering had said it wasn't a bug, after seeing your "if you dare" language, I would have absolutely taken up your gauntlet. I'm interested in sharing facts for the benefit of the community. And while we all would like to believe that what we see is "the Truth" or that our "years of experience" provide us some measure of authority, it is not so. Even I, after 15 years supporting this product 13+ of which within this company, I still get surprised to learn of nuances our engineering team have coded or designed into the product. I feel that speaks to the complexity of the software and its evolving technology (for it must evolve in order to deal with evolving malware). And in that evolution, sometimes there are issues.
... and that points back to the need for customers to do testing, which I shall belabor for the benefit of readers.
Alright, the denouement is here - and there is a bug. Not too scary though once you take in all the details .
For the more formal looking view of the issue, see KB84900 (apologies if it's not published yet, but it will be soon if not already)
This issue will affect a small subset of our customer base, but our customer base is huge so it affects enough customers that we'll want to fix this promptly.
The issue is seen in Access Protection Processes to Exclude (but we knew that already from 's original post); what we did not know at the time is there are mitigating factors which reduces the prevalence and tells us ways to work around the problem until it can be fixed in code.
All criteria must be present in order to reproduce this issue with VSE 8.8 Patch 5:
The whole idea of having processes to exclude is so they don't get blocked but because of this bug, they do get blocked.
Hopefully, the info here spells out for readers whether this is an issue you need to be concerned with, and if so what it is you are needing to look for in testing to confirm if you're affected. If it does affect you, you have options...
Workarounds (as in, what can be done prior to installing a fix)
When the affected rule is one of our rules which has been enabled:
When the affected rule is one you have added:
The current plan is to release a hotfix for this issue, so we can expect to see a hotfix available for VSE 8.8 P5 in the near future. And, a cautionary plug, installing a hotfix still carries risk ().
The necessity for installing that hotfix will be High Priority, in my opinion, because I feel it important that anyone be able to craft AP rules to block e
FYI: Patch 6, which is already in development with the goal to provide support for Windows 10, will also solve this issue.
Do we know that this behaviour is the cause of the problems reported in this thread ?
I thought that we'd have seen some feedback from affected users by now...
For the specific issue of processes to exclude that are added to an AP rule and those exclusions are not working? We've confirmed it is only AP rules that block the Execute action that are affected, and Windows 5.x is unaffected.
If you saw a different issue described in this thread from anyone, then my prior write-up is not relevant to those.
Thanks - given how specific the conditions affecting the AP issue you've posted about are I'm not sure enough info. was posted about the original posters various problems to know if they were caused by this identified problem so I guess we'll need to wait and see what the post (hopefully) back.
That is not what McAfee Support said when I called them. Which is why I wanted clarification from William.
McAfee Support said any any process that I enter in Processes to exclude of (default or User Defined) would still be blocked.