Microsoft Security Essentials Taking 40% of CPU at Start

[W]

When some of our computers reboot, MsMpEng.exe (the Security Essentials
executable) takes 25% to 40% of CPU on *every* available core of the
computer, for a period up to 10 minutes after startup. What is this
application doing, and is there any way we can limit the activity of this
executable to a single core of the computer?

What are instructions for limiting to one core under Windows XP and under
Windows 7?

--
W

[VanguardLH]

_MSSE load on CPU_

Perhaps the program is doing an update. I've noticed almost every
security product that I've tried that does program updates (not
signature updates which are usually quick) will impact the
responsiveness of the host to some degree with some being worse than
others. I don't use MSSE on the host from where I am replying (and
don't feel like walking to the other end of the house where it is used
on another family member's host) but perhaps you can configure a time
when MSSE updates itself, like off-hours (when you're typically away
from the host) assuming you leave the host powered on. As I recall,
MSSE will check for updates (or there is an option) before it runs a
scheduled scan, so turn off automatic updates and schedule a scan during
off-hours and have MSSE update then before the scan.


_Processor affinity_

There are manual methods of assigning a process to a processor. Some
are command-line programs, like SysInternals' psexec (using its -a
switch), that let you specify to which processor a process gets assigned
(i.e., you use psexec to load a program and specify the affinity);
however, that's only useful when the program gets loaded by that
shortcut using psexec. In Windows 7 (but not Windows XP), the 'start'
command has an affinity switch. Run 'start /?' from a command shell to
see its usage. While this works when you use the shortcut to load a
program, it will not assign affinity if the process is loaded as a child
process; i.e., when another program calls the one to which you want to
assign affinity. For example, if you wanted your e-mail program
assigned to a particular processor, using the shortcut to assign
affinity would work but not when you click on a mailto: link in a web
page or use "Send to E-mail" in some program's menu.

http://www.google.com/search?q=%22windows+xp%22+processor+affinity
http://www.google.com/search?q=%22windows+7%22+processor+affinity

To cover both cases (when you load the program or when it is loaded by
something else) to have its affinity configured a certain way, there are
several background utility programs that will automatically manage the
affinity of processes as they get loaded, like:

Process Lasso
http://www.bitsum.com/

Bill2 Process Manager
http://www.bill2-software.com/processmanager/
(site & forums are in French; use a translator or get from an English
download site; e.g., Softpedia.com, Download.com)

THG Task Assignment Manager
http://www.tomshardware.com/reviews/bang-dual-processing-buck,815.html

I'm not sure these will work on a new process (the downloaded setup
program to install an AV program update). I've used Process Lasso but
not for affinity control. I've looked at Bill2 and would've used it if
I didn't already have a courtesy copy of Process Lasso payware. THG was
something I found in the above searches.

I've never bothered trying to assign MSSE to a particular processor so I
don't know if it likes getting pushed around, plus the updater that gets
downloaded for a program update is a new file and probably cannot be
identified (its hash would be different each time and it gets deleted
after it runs).

"some of our computers" has you make it look like you are asking about
the property of your employer; i.e., these are company workstations.
Any solution involving the installation of software will require the
permission of whatever department (likely IT) that manages those
workstations. They don't want you installing software that is not in
their sysprep images or not in their list of authorized software. Get
permission before putzing with their property. The same goes for
reconfiguring MSSE, especially since any efforts to change its setup may
be futile if the company pushes policies for that program; e.g.,
http://fabienduchene.blogspot.com/2010/01/administrative-template-for-microsoft.html.

[W]

"VanguardLH" <V...@nguard.LH> wrote in message
news:kb4sv3$7hm$1...@news.albasani.net...

> "W" wrote:
> > When some of our computers reboot, MsMpEng.exe (the Security
> > Essentials executable) takes 25% to 40% of CPU on *every* available
> > core of the computer, for a period up to 10 minutes after startup.
> > What is this application doing, and is there any way we can limit the
> > activity of this executable to a single core of the computer?
> >
> > What are instructions for limiting to one core under Windows XP and
> > under Windows 7?
>
>
> _MSSE load on CPU_
>
> Perhaps the program is doing an update. I've noticed almost every
> security product that I've tried that does program updates (not
> signature updates which are usually quick) will impact the
> responsiveness of the host to some degree with some being worse than
> others. I don't use MSSE on the host from where I am replying (and
> don't feel like walking to the other end of the house where it is used
> on another family member's host) but perhaps you can configure a time
> when MSSE updates itself, like off-hours (when you're typically away
> from the host) assuming you leave the host powered on. As I recall,
> MSSE will check for updates (or there is an option) before it runs a
> scheduled scan, so turn off automatic updates and schedule a scan during
> off-hours and have MSSE update then before the scan.

The MSSE instances that take 40%+ of CPU are NOT doing updates. I can
update manually to the latest update and I still see this behavior where it
grabs significant amounts of CPU. It is NOT scanning the system while this
happens. On the surface MSSE appears to be doing nothing.

One of the things I would like to understand is what is MSSE actually doing
in the background when it takes up so much CPU for so long?

I was able to use psexec to change affinity under XP for a program started
by a shortcut. I was not able to affect the behavior of MSSE, even after
changing affinity. What I did was start a shell as the SYSTEM, then start
Task Manager. I manually adjusted affinity on MsMpEng.exe to use a single
processor core instead of all four. It made no difference on overall
system performance. The computer continued to be incredibly slow while
MsMpEng took up 40%+ of CPU. During these periods of MsMpEng.exe intense
CPU usage, Windows Explorer becomes virtually unusable. Just entering a
folder can take two minutes to accomplish.

> "some of our computers" has you make it look like you are asking about
> the property of your employer; i.e., these are company workstations.
> Any solution involving the installation of software will require the
> permission of whatever department (likely IT) that manages those
> workstations. They don't want you installing software that is not in
> their sysprep images or not in their list of authorized software. Get
> permission before putzing with their property. The same goes for
> reconfiguring MSSE, especially since any efforts to change its setup may
> be futile if the company pushes policies for that program; e.g.,
>
http://fabienduchene.blogspot.com/2010/01/administrative-template-for-microsoft.html.

I am the manager so no problems with permissions. The problem is Microsoft
Security Essentials is doing more harm to my computer than the viruses it is
trying to fight.

--
W

[VanguardLH]

"W" wrote:

> The problem is Microsoft Security Essentials is doing more harm to my
> computer than the viruses it is trying to fight.

You could use SysInternals' ProcMon to see what MSSE is doing.

[W]

"VanguardLH" <V...@nguard.LH> wrote in message

news:kbd75l$pmj$1...@news.albasani.net...

Well, here are some clues:

1) When I load Procmon 3.03, it fails to load because the application cannot
load the Procmon device driver.

I am logged in as Administrator, and I verified in RSOP.MSC that the user
rights policy to Load and Unload device drivers includes Administrators
group.

In the Windows Security EventViewer, there is a confirmation of the above
because the security failure audit is recorded that the Administrator userid
cannot obtain the SeTcbPrivilege

2) I then tried to launch Procmon in the security context of SYSTEM (how you
do that is the subject of a whole different discussion). To my surprise,
THAT ALSO FAILED.

So at this point it really starts to look like something in the basic
operating system is not functioning correctly. It may be my system is
hacked.

Does anyone have any insights into this weird behavior?

--
W

[VanguardLH]

"W" wrote:

> "VanguardLH" wrote ...

MSSE does not have high coverage. It is better than nothing but not as
good as others. If you look at:

av-comparatives.org
http://www.virusbtn.com/vb100/rap-index.xml

you'll see MSSE doesn't fare too well. You might want to disable MSSE
for now (to use as a secondary manual scanner) and try MalwareBytes and
SuperAntispyware as manual scanners to provide overlap coverage (and
Avira or Avast to replace MSSE). I'd start off with MalwareBytes (free
version).

You could also ask in the ProcMon forum if someone knows why it doesn't
get the permissions it needs to load its class driver (dynamically
loaded driver).

http://forum.sysinternals.com/process-monitor_forum19.html

You could try loading Windows into its safe mode but I've often found a
service needed by a user-mode app won't load in safe mode. Instead you
have to use msconfig.exe to do a selective startup: all the startup
programs are disabled but not the services. If ProcMon then loads under
safe or selective mode then other software is conflicting with it.

I don't see a separate file that procmon.exe could load for its driver.
The download of Process Monitor only has its procmon.exe and procmon.hlp
files. So procmon.exe must be unrolling the driver from its own code to
create a separate file and load it. Apparently it unrolls the
procmon20.sys and procmon23.sys files. There are also service defines
for those drivers in the registry at:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PROCMON20
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PROCMON23
which point to the enumerations of
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_PROCMON20
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_PROCMON23
both of which point to a class GUI of
{8ECC055D-047F-11D1-A537-0000F8753ED1}
which looks to use SysSetup.DLL to call some method to define/load a
legacy (non-PnP) driver.

I actually first came across the service defines by loading the Device
Manager (devmgmt.msc), showing hidden devices, and seeing under the
"Non-Plug and Play Drivers" group the ProcMon20 and ProcMon23 drivers.
That doesn't mean they are currently loaded only that they were
previously defined (and are still defined in the registry). I don't to
what path procmon.exe unrolls its .sys driver files (%temp% maybe?) but
you'll need permissions for that folder. I suppose it could unroll the
drivers into a file, load the driver, and then delete the files since
only the memory copy is needed. After loading ProcMon, a file search on
procmon* didn't find and .sys driver files. Maybe there's a way to
dynamically load a driver without ever creating a file for it.

I ran out of time right now so I couldn't go see what methods were in
syssetup.dll to see which ones might be used to load a class driver.
Just in case, have you ran "sfc /scannow" to ensure you've got a good
copy of this file (and following with all Windows updates)? On my
Windows XP SP-3 host, syssetup.dll's version info says 5.1.2600.5512.
Some info here:

http://xpdll.nirsoft.net/syssetup_dll.html

When logging locally onto the problematic host, are you still logging
into the domain or using a local Windows account? Administrators in
domains may not have all the privileges of a local Administrator. I've
ran into this where the IT folks gave us in the QA dept administrator
rights over our own workstations but we found out we didn't have *all*
possible admin rights. We had to login under Administrator but using a
local Windows account (since these were our test hosts that we built and
installed the OS, we knew the login credentials for the local
Administator account).