McShield is the real-time scanner; it's job being to scan new or modified files.
MFERunTime*.dat is a DAT file built from the full DAT files; a memory mapped file.
It's combing the file in response to scan requests, those scan requests being in response to file activity that has been deemed to require scanning.
Being a "development machine" it's expected there's going to be tons of new files coming and going.
It would be best to chat with your admin folk about ensuring they've configured an optimal scan configuration for you. For example, they could utilize the hi/low risk configuration - place your processes responsible for compiling into low risk - and disable scanning for that profile.
That way, none of the file activity invoked by your compiling actions will be scanned (or hindered by scanning).
It seems the VSE versions (has happened since 8.0 that I am aware of) have suffered with a "spike" on CPU usage when updates are being processed. McScript.exe will hit the CPU processing the mferuntime*.dat and hold for several minutes ( have seen it hitting nearly 100% for 40 min). The resolution has always been "apply patch x" only to have the issue return in the next major revision.
The only solutions I have used with any success are:
1 - contact your account manager and find out about an SDAT released (RTS only) lowering the CPU priority (why is this not a standard setting??) - this provides only limited success.
2 - alternatively you can set your systems to process DATs in the evening and hope everyone leaves their systems running with a running "catch up" command after system start-up after x period of time. This also only provides limited success depending on your environment and the urgency of the update. Many places run their DATs in arrears anyway just in case another SVCHOST issue or similar rears up. The problem with updating late day is the systems may not be online to process the DAT in the off-hours leaving a group of systems to pull and process and update just after starting up the next day - also causing an impact to the network and system resources.
I have seen this issue on production, development, stand-alone, VPN, and any other manner of system - the solution has always been the same "patch to correct".
I have a case where the customer is currently experiencing the same issue on systems using VSE 8.8 P1. After a DAT update mcshield is constantly accessing the file C:\Program Files\Common Files\McAfee\Engine\mferuntimexxxxx.dat thus causing the system to become very slow to almost unresponsive.
The only way to ease the problem so far has been for the customer to disable scan on read.
Any assistance will be appreciated
We have just had a noticable CPU spike we believe when the latest DAT updated (6700 i think). The problem is the machines affected are all on VSE8.8 P1 with the latest hotfix and everything.
I also already utilise the hi/low risk scanning strategy.
I'm wondering if there is a new exception that needs to be created to make the DAT updates easier, they used to be terrible until i followed the VSE best practice guide and added all the recommended exceptions to improve DAT update performance.