If you only disabled the McAfee services in the list of Windows services, then McAfee isn't really disabled. There are still filter drivers/etc that are active. You can disable/re-enable them using the mfehidin command. For reference see McAfee KB56059.
Here is another thread that may be related:
Try to run process monitor tool to see what is happening on server to make high CPU usages. Based on results you can do exclusion to make CPU utilization at normal level.
McAfee On Access scanner policy, remove scan inside ZIP files + Remove scan on files opened for backup + Remove scan on Network Drives. Using these options will make CPU normal.
@ansarias Thanks but you did not read my post really well I guess. I did exclude everything. I even disabled all services. So except for some low-level drivers, nothing is running anymore. That means excluding from mcshield will not do the trick.
I'll still see what procmon will tell me but probably it's just 'system' that's using all cpu.
@bleeder Thank you as well, I'll check that out.
I wonder if noone else is having these issues. We are only having a 1Gbit backbone here, but imaging how bad this is when running on 10Gbps.Even when excluding everything,
Try disabling the McAfee Mini-firewall device driver (MFEWFPK.SYS), as long as you are not currently making use of port filtering via VirusScan Access Protection. To disable that driver simply rename it (e.g. MFEWFPK-disabled.SYS) and reboot.
I have a case open for what appears to be the same issue. It does not happen on physical servers but only on Hyper-V and VMware VMs. I ran a before and after test to be sure, where I would copy a large file to the server and time how long it takes, as well as watching the CPU usage.
With the evidence I sent to McAfee in my case, they have agreed that there is a problem and they are now moving it to McAfee Engineering.
The way I look at it, the mini-firewall driver is shimmed into the network stack (as a mini-filter driver) -- in order to do its work -- and should not consume any cycles at all if nothing has been configured for it to filter/scan.
I am hopeful of a hotfix but in the meantime am considering disabling the driver. Imagine the performance boost!
Would be curious to see your test scenario. My case # is 4-6523877545. I have not done much testing on P4. My tests were comparing P2 and P3. I am guessing that there was a change introduced in P3 that continued into P4, which is causing this.
There is an interesting change in mini-filter driver architecture by Microsoft in Server 2012 (Win8). Check out these articles:
The last one adds an interesting wrinkle for Hyper-V (Offloaded Data Transfers).
My scenario is pretty simple - I've setup 2 2012R2 VM's, both updated by WSUS to current patchlevel, one with VSE8.8 p4, one without it. The difference especially with large files is astounding. Disabling mfewfpk.sys indeed stops the issue, so for us it's reproducable and narrowed down to that filterdriver, while we don't actually use it. I registered a case, still waiting for initial response. Same happens in 2008R2 VM's by the way, which don't support ODT as far as I'm concerned. I don't run VSE on my Hyper-V hosts, as excluding all Hyper-V storage as a best practice (and boy did I have issues with VSE running on these hosts even with those exclusions) means it's not doing anything really functional anyway. With regards to network drivers; there is not really such a thing as they are updated by installing the guest-additions and they are all up to date.