VirusScan Enterprise 8.8 32bit (with scan engine 5400.1158) currently uses ~1GB memory from the nonpaged pool. That’s half of the physical memory of the system.
(RAMMap and Poolmon)
After 12 hours, during which there were little activity, the memory picture remained almost unchanged.
OS: Windows Server 2008 SP2 32bit
System uptime: 9 days
for %i in (mfe*) do @echo %i & sigcheck -q -n %i
Note that such memory leakage cannot occur on 32bit WindowsXP/2003 because the nonpaged pool of these OSes is restricted to 256 MB or less.
Is this a know VirusScan issue?
The system is still alive. Is there a way to see the memory content of MFE0?
Hmm, an update should be the first thing to consider, you are running on an old set of drivers (8.8 RTW), P1 for VSE 8.8 will update you to 220.127.116.117. Note issue 15 in the P1 readme. From the data presented, difficult to say what is going on and what is at the root, that would require perfmon, poolmon, dump analysis. I'm quite confident though that P1 will alleviate the symptoms you describe. Make sure the OS is up to date (Windows update).
The numbers are odd though.
More reading if you are interested, I found useful: http://blogs.msdn.com/b/ntdebugging/archive/2006/12/18/understanding-pool-consumption-and-event-id_3...
You would be able to analyse MFE0 memory consumption with a memory snapshot (kernel dump) while the machine is in the state of exhibiting the symptoms.
I found a way to dump all pool allocations tagged with MFE0 without restarting the system.
Step 5 and 6 require perl with necessary packages installed (I used ActivePerl). These two steps may take several hours.
These instructions probably are far from optimal, but they give freedom to everyone technically literate to follow them, to obtain an approximate idea of what is going on without relying on the interpretations of someone else.
In MFE0.txt, which I generated by following essentially the same instructions, I found a lot of "cygwin" strings. Recently I compiled OpenSSL in Cygwin environment in order to create self-signed certificates.
On the basis of that information I created a test case which clearly illustrates the memory issue:
Although the test case involves compilation of source code the underlying memory problem may manifests itself in other situations.
> I'm quite confident though that P1 will alleviate the symptoms you describe.
I don't see a clear reason to think so. Issue 15 in the release notes of Patch 1 refers to the process validation service, which aparently is part of Access Protection. Access Protection is not installed on the system.
You should check to see if you have a process that's leaking Handles.
We have seen and addressed NPP leak issues in our drivers in previous releases, but we haven't seen anything for a long time that has been confirmed as a McAfee issue - instead what we've found is we are a victim of a poorly behaving process, who is opening file handles endlessly (which we are having to track in our driver code, thus using up memory).
Otherwise, you should force the system to dump (or you can try live dumps if your system must remain up, but live dumps aren't 100% reliable to have the data we'll need - or at least the data may not be coherent). With a dump we'll be able to track the pool usage and probe for other potential causes.
ESET NOD32 Business Edition 18.104.22.168 passed the test case without leaking memory.
After uninstall of McAfee VirusScan Enterprise 8.8 (and McAfee Agent) and subsequent system restart, part of McAfee remains active and occupies RAM memory:
One way to remove that part is the following:
Download the new ePolicy Orchestrator (ePO) Support Center Extension which simplifies ePO management and provides support resources directly in the console. Learn more about ePO Support Center