Here then, are some issues our team is hearing about in the field and further below are references to field guides to help you avoid stepping on others we've already disarmed or at least identified.
P.S. If you've already stepped on a mine, call a doctor (i.e. call Support)
OAS will not enable after Patch update
McShield service fails to start due to dependency on MFEVTPS
Mfevtps service fails to start due to dependency on MFEHIDK
Mfehidk driver fails to load because it has no "Start" value.
Here's an annoying issue - you install a patch update, Patch 4 is what has been commonly reported as the catalyst, and post installation the scanner will not start. Upon inspection you can trace the cause back to a missing "Start" value for our "link" driver "mfehidk.sys". This value is supposed to exist in the registry here: HKLM\SYSTEM\CurrentControlSet\Services\mfehidk
Add the missing "Start" REG_DWORD and set it to "0". Then reboot.
To find root cause for this issue we have to "see" the issue occur. In most cases this is reported to us "after-the-fact", meaning, the system is already in a broken state. And while that is the right thing to do, it doesn't offer sufficient data to help us know how it got into that state. Ideally, there will be a VM snapshot available that allows us to reproduce the failing sequence of events that led to the "Start" value disappearing.
If we cannot obtain that data we might be forced into devising a less elegant resolution for the field.
I've now seen 2 sets of MER data from different environments that encountered this issue. Their install logs each showed that the first attempt to install VSE was to use the 8.8 Patch 4 full-install package, and, that installation failed because the system was SHUTTING DOWN! LOL.
The next attempt to install the product, obviously post reboot, was SUCCESSFUL (if log files are to be believed) - however, that's also when the issue manifested. So it leaves me wondering, "Was that original install attempt and failure due to shutdown the catalyst to make this issue possible?". I have added reproduction attempts it to my "to-do" list but who knows when I'll get to complete that testing.
If this really is the cause then... there's nothing we can do for this... we'll always be hearing about odd sporadic reports of this issue occurring, because we can't exactly stop the system from shutting down just because our software is installing. Can we? Hmm, maybe there's a PER to explore here.
Server 2003 memory leak
Requires: VSE root-kit scanning, and a 3rd party driver
Non page pool memory has been observed to leak, only on this operating system, and only when doing root-kit scans as part of an ODS task.
The leak is small but quite a few people run ODS regularly, scanning memory and for root-kits. This will exacerbate the leak to the point where it becomes noticeable - system sluggishness, System Event 2019's, failure to RDP to the node, etc.
The issue doesn't occur within our code only; it needs a catalyst, and a couple 3rd party drivers have been found to be just that.
Investigation has proved impossible because it's Server 2003 and doesn't support debugging tools for tracking object referencing. And there have been no reports against newer operating systems where such debugging is possible.
Next step: McAfee could invest time/effort into inventing an object-tracing methodology for this old operating system which will have unknown value/results, or...
Suggestion: Either a) Plan to reboot periodically, the frequency being proportional to the leak rate which will be proportional to the ODS root-kit scan frequency, or b) avoid root-kit scans or reduce their frequency such that planned reboot cycles can be leveraged to recover the memory.
Patch 5, related to MFEDISK.sys
1. Unable to install drivers for storage device (e.g. USB)
2. Hyper-V no longer recognizes pass-through drives
Uncertain at this time if these 2 issues stem from the same cause, but what they have in common is the symptom no longer occurs when our MFEDISK.sys is not loaded.
Workaround: (disable MFEDISK.sys from loading)
Engineering to investigate.
|Know this||Why you should know this|
|KB65944 Hot Topics||A quick reference article to help solve the most common reported issues as assessed by the VirusScan SEO Team (that's Tier 3 or "backline" for some folks). Topics covered include:|
KB51111 What is Supported?
And, Known Issues for each release
And, What Patches or Hotfixes are available
The footnotes and Important statements store gems of information too.
Always review the Known Issues for your Patch level. Need more information about any? Ask Support.
Heed any Hotfixes that are listed if they apply to your Patch level. We posted it for a reason. If the hotfix package includes MFEHIDK.SYS, we strongly recommend adopting it because the "reason" just got real.
MFEHIDK.SYS is one of our core components that integrates with the operating system; when we fix an issue in this area of code, we help stabilize the product, your system, your business continuity.
Blog, covering fundamentals for improving your chances for success and overall experience when applying product patches to VSE.
Notice the size disparagement of the Patch (MSP) vs. the full install (MSI)? It's because the MSP has to support multiple upgrade paths and the deltas of each, cramming all that data into one MSP package. Thus the delta is larger with each patch release.
|Using Scanner Profiles||Blog, showing how to improve performance without punching massive holes in your AV coverage.|
|OAS: Scanner Timeouts||Blog, telling you to stop ignoring timeouts (unless you understand/accept why they're occurring)|
|OAS: Disabled||Blog, explains how to investigate OAS reporting a disabled status|
|Access Protection: How to||Blog, explains how it works and how it should be used|