Closed Bug 1441918 Opened 6 years ago Closed 1 year ago

Antimalware Service Executable (Windows Defender) very active / high CPU when using Firefox

Categories

(External Software Affecting Firefox :: Other, defect, P3)

Tracking

(firefox-esr102 wontfix, firefox61 wontfix, firefox62 wontfix, firefox63 wontfix, firefox110 wontfix, firefox111 wontfix, firefox112 wontfix)

RESOLVED FIXED
Tracking Status
firefox-esr102 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox110 --- wontfix
firefox111 --- wontfix
firefox112 --- wontfix

People

(Reporter: designakt, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Keywords: perf:resource-use)

Attachments

(7 files)

I noticed that for some time now most of the time Firefox is active, the Windows 10 built in `Antimalware Service Executable` is using well above *30% of my CPU*, and is reading and writing random files in `Windows/Temp`, all starting with `etilqs_`. 

This is considerably slowing me down and makes Firefox feel really slow.

I reproduced this in a new profile, and so far the only thing that helped is excluding the Firefox process from Windows Defender Antivirus. (something most of our users will probably not do)
Here is a recording of opening Nightly and navigating to a few websites, with disk and cpu activity visible. https://drive.google.com/open?id=1KqJxhVKE1xi3TRYAuFKhgEPz7wAUnleX (licecap is the recording tool)

I am on Windowns 10 on Surface Pro 4, running the current Nightly

I first raised this as a question in slack and so far Randell Jesup failed to be able to reproduce on his machine: https://mozilla.slack.com/archives/C4D3JFF26/p1519827897000296

I also check to only exclude the profile directory, which reduced the `Antimalware Service Executable` - Activity, but it is still around 10-15% when browsing this way.
That's a lot of temporary SQLite database activity!  Running with MOZ_LOG=mozStorage:5 will get you reallllly detailed logs, with the output file controlled by MOZ_LOG_FILE.  Setting environment variables in Windows can be very awkward, however, so you can also set the string preference "logging.mozStorage" to "Verbose" to enable the logging and set the string pref "logging.config.LOG_FILE" to wherever you want the log file.  If using preferences, you probably want to restart the browser, because I think some of the more interesting attaching we do only happens when we establish the connections.

See https://searchfox.org/mozilla-central/source/xpcom/base/LogModulePrefWatcher.cpp for other interesting prefs and the string version of the levels.
Note that Defender also scans anything we are writing to the web content (HTTP) disk cache.  I believe this is a normal behavior and personally I find it preferable.

Note that exclusions in Defender don't work well (or at least used not to) e.g. for excluding mozilla source tree and obj dir to speed up builds.  I can still build way faster (and only that way) when I completely disable the runtime protection of Defender regardless of how my exclusions are set up.
Are you on Firefox 64 or 32 bits?
I'm asking because on 64 bit systems we should default to a memory temp store for any Storage consumers, while on 32 bit it's the consumer that must opt-in to using a memory temp store.
https://searchfox.org/mozilla-central/rev/769222fadff46164f8cc0dc7a0bae5a60dc2f335/db/sqlite3/src/moz.build#93
If you're on a 64 bit build, this is a bit more puzzling.
Flags: needinfo?(mjaritz)
Priority: -- → P3
(In reply to Marco Bonardo [::mak] from comment #3)
> Are you on Firefox 64 or 32 bits?

I am using 64bit Firefox
Flags: needinfo?(mjaritz)
The other thing I'm puzzled about is files are created in Windows/temp rather than under AppData where I'd expect us to create them. Sorry for the many questions, comment 1 suggested getting a moz_log, that may still be useful.

Since our version *should* always store temp files in memory, not disk, I'm thinking about an external helper using sqlite to store some data. modulo a bug that prevents SQLITE_TEMP_STORE from working.
Do you have any add-ons that may use an external helper process? Could you try if the problem persists in Safe Mode or with all add-ons disabled?

Last thing, you could try launching Process Explorer 64 (https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer), click on the Binocular (Find Handle or DLL), type "etilqs_" and click search, it could help finding which process is using those files.
Trying to do the logging now, I could not reproduce the effect anymore... I am totally puzzled what changed. Yesterday I saw that happen in my default profile, as well as a new blank profiel. Now I only see very short, low spikes of `Antimalware Service Executable` activity... barely higher then 10%, and I do not see any of the etilqs_ files I saw yesterday. ¯\_(ツ)_/¯

Only big thing I changed was enable "Cloud-Delivered Protection" and "Automatic sample submission"... in Windows Defender yesterday, but still after turning those off again, I couldn't reproduce. Will try again tomorrow, and if I can not reproduce I will close this bug. Sorry...
Ah, so after reading :mak's comment 5, if I pay more attention when I go to look at the gif again, I see that the "etilqs_" accesses are coming from the "System" Image with PID=4, so it's not directly Firefox.  (Which makes sense, because it's SQLite itself that does `# define SQLITE_TEMP_FILE_PREFIX "etilqs_"` if it's not already defined.  Only software that #define's it to be something else would use a different prefix.)

I wonder if we should define it to be a different value for Firefox builds so that we can have support pages like https://support.mozilla.org/en-US/questions/987495 and others say "If it was firefox, it would be ff_etilqs_", it's not Firefox.
(In reply to Andrew Sutherland [:asuth] from comment #7)
> I wonder if we should define it to be a different value for Firefox builds
> so that we can have support pages like
> https://support.mozilla.org/en-US/questions/987495 and others say "If it was
> firefox, it would be ff_etilqs_", it's not Firefox.

It sounds like a good idea, feasible where we don't use System Sqlite. Maybe with an mz prefix, considered Storage is also used by TB, SM and other products. I'll file a bug for that.
Depends on: 1442370
from next Nightly, our temp files will be prefixed with "mz_etilqs_", so if you should notice this again, you will be able to tell if it's Firefox or another app in the system creating all of those files.
I did a comparison with chrome today, and for both browsers I see those sqlite files. However, when Firefox is running, `Antimalware Service Executable` seams way more active, when doing basically the same browsing. So the files might be part of the Defender activity.

I did some recordings to show how Firefox and Chrome impact `Antimalware Service Executable` - Firefox triggers it way more!
And there might also be a relation to Defernder settings. It seams to me that Defender is even more active with Firefox after Cloud-Delivered Protection and Automatic Sample Submission is off. 
For Chrome Defender does not seam to use nearly as much resources. (no matter the defender settings.)


rough CPU estimates from the recordings:
Defender CDP off & ASS off 
Firefox ~ 25% Defender activity
Chrome  ~ 10% Defender activity
redording: https://drive.google.com/file/d/11kCNeV2a8kS1q6yntlOgMjVf71gGwFbw/view

Defender CDP on & ASS off
Firefox ~ 15% Defender activity
Chrome  ~  8% Defender activity
recording: https://drive.google.com/file/d/11lvSim7WT-dB_8Yt4eqfGHT90Bj_S4Ry/view

Defender CDP on & ASS on 
Firefox ~ 5% Defender activity
Chrome  ~ 1% Defender activity
recording: https://drive.google.com/file/d/11q-__1rfDQ3EGIQBrC3ILQTQarU08NMV/view


(both are new profiles, on chrome and on Firefox, and I restarted the machine and reset the profiles before every re-run)
It's possible Defender itself uses Sqlite internally, nobody knows.
Btw, please let us know if after the next Nightly the temp files are mz_ prefixed, if not, this is very likely not a Storage bug, we may just be storing things in the cache (or elsewhere) differently from Chrome, and maybe Defender doesn't like that.
Setting a needinfo for myself to check in on that next week.
Flags: needinfo?(mjaritz)
(In reply to Marco Bonardo [::mak] from comment #11)
> please let us know if after the next Nightly the temp files are mz_
> prefixed, if not, this is very likely not a Storage bug, we may just be
> storing things in the cache (or elsewhere) differently from Chrome, and
> maybe Defender doesn't like that.

I still see those files when running the latest Nightly, but they are not mz_ prefixed.
Flags: needinfo?(mjaritz)
Yesterday noticed that my HHD start slowing down whole system. I have moved temp folders (in env. vars) to it, and page file.
Checking task manager shown me that MsMpEng.exe do something hard with disk, ~70mb/s
So i moved temps to RAMdisk and page file back to ssd.

Then i noticed that in system temp folders root (which one is originally c:\windows\temp) appears and disappears etilsq files 0 bite size. It appears, and immediately swaps with different with different letters in name, and it happens in constant cycle.

I start google it, and find out that it is SQL temp files, and stuff, and Firefox create such things. But it not Firefox's files as i understand

https://filestore.community.support.microsoft.com/api/images/8dccb3f1-2d78-430c-9731-925b4290e621?upload=true

They created by MsMpEng and for some reason when Firefox is working, it creating deleting them in constant loop.

I'm installed nightly and it stops, for some time, but then after time (or after i opened some site) it start happens again.
Until i closed firefox.

Also they didn't stop appear disappear INSTANTLY after i close firefox, but i think after 1 or 2 minutes only.
And probably starting up creative cloud aslo cause spaming this files, but only for short time.

So i'm started nightly right now, and it DOESN'T cause any temp files in system temp, i think it's mean that some site caused it, but i don't know.

Strange issue, it's like something have seen like i figured out my usb problem with new PC, and decided throw this cursed bug on me =_=

i think this is related, but no resolution:

https://answers.microsoft.com/en-us/windows/forum/windows_10-security/windows-defender-constantly-creates-and-reads/f5d48ecf-6446-40fd-b9e3-32ae5962b688
(In reply to silentprayercg from comment #14)
> They created by MsMpEng and for some reason when Firefox is working, it
> creating deleting them in constant loop.

I honestly think MsMpEng is just misusing Sqlite, they should set TEMP_STORE to memory, especially on 64 bit systems. You should report the bug to MS Connect.
ehr, looks like Connect has been retired and now the supposed way to report bugs is the Windows Feedback Hub app.
(In reply to Marco Bonardo [::mak] from comment #15)
> (In reply to silentprayercg from comment #14)
> > They created by MsMpEng and for some reason when Firefox is working, it
> > creating deleting them in constant loop.
> 
> I honestly think MsMpEng is just misusing Sqlite, they should set TEMP_STORE
> to memory, especially on 64 bit systems. You should report the bug to MS
> Connect.

and they will ask me to do scf scannow which never helps and stuff...

at leas for now it doesn't did anything like that, at least with nightly.
it will be hard to report something that i can't fully understand why and how happens.

well if something like this happen i will try feedback thingy...
if enough people report the problem in feedback, they may look into it, if nobody does they'll not even be aware, so I still suggest reporting it. I'll do the same now.
I reported this as a Problem in Security & Privacy / Windows Defender exploit protection
"Antimalware service misuses Sqlite"
"Antimalware service doesn't set Sqlite TEMP_STORE to memory, and ends up creating hundreds of apparently 0-size temporary Sqlite files in windows/temp, slowing down the system. The problem can be reproduced for example using Mozilla Firefox. Also see https://bugzilla.mozilla.org/show_bug.cgi?id=1441918"
I started having this issue yesterday (Firefox 60 and 61) out of nowhere, and I have previously seen this on other people's laptops, so I decided to investigate.

Process Monitor [https://docs.microsoft.com/en-us/sysinternals/downloads/procmon] showed the same behaviour as described in this issue. I decided to try to figure out what changed that triggered this, and to see if there was a workaround.

Current guess of the mechanism:
-------------------------------

1. Firefox starts up, MsMpEng starts scanning everything read/written by Firefox

2. Something (new!) in both the Roaming and Local (profile) directories of Firefox makes MsMpEng start writing out `etilqs_xxx` files into C:\Windows\Temp (probably to parse them)

3. MsMpEng detects that MsMpEng is writing out sqlite files, so it reads them, and (to parse them?) writes to the same (or new) `etilqs_xxx` files in C:\Windows\Temp

4. If you shut down Firefox, (3) eventually converges and completes (after a few minutes)

Attempts at workarounds:
------------------------

* Setting SQL_TMPDIR in environment variables (and restarting Windows) in the hopes that MsMpEng.exe writes them there, and that can be excluded. `etilqs_xxx` were still written into C:\Windows\Temp [ref: https://www.sqlite.org/tempfiles.html]

* Excluding AppData\Local\Mozilla. Did not work, same behaviour.

* Excluding AppData\Roaming\Mozilla. Did not work, same behaviour.

* Excluding both AppData\Roaming\Mozilla and AppData\Local\Mozilla. WORKED!

Possible fixes:

a) Windows Defender should use in-memory temporary sqlite dbs (who knows how long this will take to fix)

b) Figure out what triggered MsMpEng to use sqlite to parse something in Firefox's profiles. My best guess right now is that the size of some file (an sqlite db?) increased enough to trigger this codepath in MsMpEng, but the trace I have doesn't reveal anything to me. The internal structure of Firefox profiles has changed since I last looked at it.

I'm attaching some Process Monitor traces next, so that someone smarter than me can look at it :)
This process monitor log follows MsMpEng and starts from when Firefox was started, till when MsMpEng starts going crazy trying to read/write/create files in C:\Windows\Temp.

Filters you may want to use:

1. Show only disk I/O events
2. Include events with paths in AppData\Local\Mozilla and AppData\Roaming\Mozilla

Please tell me if you need any other traces.
mkaply, since you often worked with AV providers, do we have any contacts with Microsoft we could use here?
Flags: needinfo?(mozilla)
Does it change anything if instead of excluding the mozilla profile folders, you just temporarily exclude the *.tmp extension?
Flags: needinfo?(nirbheek.chauhan)
(In reply to Marco Bonardo [::mak] from comment #23)
> Does it change anything if instead of excluding the mozilla profile folders,
> you just temporarily exclude the *.tmp extension?

I tried this:

1. Close Firefox, and all other programs

2. Open procmon and filter MsMpEng file I/O events

3. Remove profile folders from exclusion in Windows Defender

4. Add a filetype exclusion with extension 'tmp'

5. Start Firefox

Result: bad behaviour by MsMpEng, read/write/create `etilqs_xxx` files in C:\Windows\Temp
Flags: needinfo?(nirbheek.chauhan)
It doesn't happen to me anymore, at least yet.
I have theory that some opened site or may be addon cause this.

Also how can i exclude extension from windows defender?
I haven't worked much on the Microsoft side, but I know Jim has.
Flags: needinfo?(mozilla) → needinfo?(jmathies)
(In reply to Mike Kaply [:mkaply] from comment #26)
> I haven't worked much on the Microsoft side, but I know Jim has.

(In reply to Marco Bonardo [::mak] from comment #22)
> mkaply, since you often worked with AV providers, do we have any contacts
> with Microsoft we could use here?

Post to the microsoft list.
Flags: needinfo?(jmathies)
Sounds like this affects the current Nightly and versions as far back as 60, at least. 
Tracking for 62 and 63 so that I can keep an eye on the answers from Microsoft.
I can readily repro this, in case anybody needs another tester.
I'm currently using Firefox 61 x64 release and Windows 10 1803 with latest patches for OS including Windows Defender. I can confirm this is happening and only with Firefox. However I have tried to exclude Firefox's process (https://support.microsoft.com/en-ph/help/4028485/windows-10-add-an-exclusion-to-windows-defender-antivirus) (in exclusion page select process and enter "C:\Program Files\Mozilla Firefox\firefox.exe") and so far Windows Defender isn't exhibiting the problem anymore.
Wow glad someone pointed me here. I noticed this problem 2 days ago and since then was looking for people with same slowdown so I asked on reddit: https://www.reddit.com/r/techsupport/comments/8v5hrk/anyone_have_windows_defender_slowing_down/

If you have read my post on reddit, you'll see that Windows Defender 4.18.1806.18062 was installed on June 27th and that seems to coincide with my issue. Anyone else able to see when that version was installed and see if it coincide? Just look at the 4.18.1806.18062-0 folder date in "C:\ProgramData\Microsoft\Windows Defender\Platform".

Like pointed out by someone else above, the issue happens also when running Chrome so for now my only solution was to disable Windows Defender and use Malwarebytes (2 weeks free on pro version) until Microsoft comes up with a fix.

Tonight I saw Mark solution so I turned on WD again and it works! But I also had to add Chrome to the exclusion list.

How come this was reported early in May (when we look at https://answers.microsoft.com/en-us/windows/forum/windows_10-security/windows-defender-constantly-creates-and-reads/f5d48ecf-6446-40fd-b9e3-32ae5962b688) and today we have to fight with this issue?

Hopefuly someone from Microsoft will be notified quickly and a fix will come in a timely manner.
It still didn't happen for me, since I've installed ff beta (firefox quantum 62.0b4 64bit version)
My windows is 1803 17134.112 right now.
My temp on HDD now, and if it will happens again I'm pretty sure I will notice it.

And now it apparently now only FF, but Chrome too... last time i noticed only that Creative Cloud cause same behavior but only for short time, when started up.
Fwiw, I notified our Microsoft contacts through the mailing list, I guess for now it's just matter of waiting.
It seems the problem is gone me.

Windows 10 1709
Build 16299.547

Firefox 61.0.1 (64-bit)
(In reply to Jason Metz from comment #34)
> It seems the problem is gone me.
> 
> Windows 10 1709
> Build 16299.547
> 
> Firefox 61.0.1 (64-bit)

It seems the problem is gone for me. typo
There should be a Defender update incoming in the next days/weeks. Someone using insider versions may already have it.
Open Windows Defender Security Center, click Settings, there should be a link on the right "information" or "about" (I'm sorry I have another locale than English, so I'm not sure what's the expected label here).
You "Engine Version" should be greater or equal to 1.1.15100.1.

Once you can confirm you have that version, please test and let us know.
Thanks Microsoft for investigating the problem.
(In reply to Marco Bonardo [::mak] from comment #36)
> Thanks Microsoft for investigating the problem.

How do you know they have acknowledged the problem and that they are working on fixing it?
We have contacted them.
(In reply to Marco Bonardo [::mak] from comment #36)
> There should be a Defender update incoming in the next days/weeks. Someone
> using insider versions may already have it.
> Open Windows Defender Security Center, click Settings, there should be a
> link on the right "information" or "about" (I'm sorry I have another locale
> than English, so I'm not sure what's the expected label here).
> You "Engine Version" should be greater or equal to 1.1.15100.1.
> 
> Once you can confirm you have that version, please test and let us know.
> Thanks Microsoft for investigating the problem.

I have Engine Version 1.1.15000.2 and the problem still exists. Huge disk usage by creating and writing etilqs files.

It happens with any network traffic, not only Firefox. But I've only started noticing it after installing Firefox yesterday (Jul 16).

Disabling WD real-time protection stops the issue.
Marco said we need to wait for 15100, unfortunatly for such an issue it's slow to get the fix.

I wish I could see the patch notes for this new release. "We have contacted them." don't tell us much...
(In reply to rhialto from comment #37)
> (In reply to Marco Bonardo [::mak] from comment #36)
> > Thanks Microsoft for investigating the problem.
> 
> How do you know they have acknowledged the problem and that they are working
> on fixing it?

Mozilla developers and Microsoft developers have discussed this issue over email.
(In reply to rhialto from comment #40)
> Marco said we need to wait for 15100, unfortunatly for such an issue it's
> slow to get the fix.
> 
> I wish I could see the patch notes for this new release. "We have contacted
> them." don't tell us much...

Totally mistook the 1 for a 0. Not a good thing for a software person, ha.
As noted previously here: this has been identified as a MS issue, and they are rolling out a fix soon. So nothing for us to track, not a Firefox bug.
I am using Engine Version: 1.1.15100.1 and I am still seeing higher cpu usage with windows defender when using firefox then with chrome for the same browsing still.
I am using Firefox 61.0.1 x64 on Windows 10 ver. 1803 build 17134.167

When I run or close Firefox, Windows Defender loads the CPU on almost 30%. It is slowing down my OS for a minute, maybe.
(In reply to atosdo from comment #45)
> When I run or close Firefox, Windows Defender loads the CPU on almost 30%.
> It is slowing down my OS for a minute, maybe.

What's your Windows Defender Engine Version? (see comment 36).
Anyway, at this point there's no strict reason to keep this under Storage, we already clarified it's not mozStorage causing the problem.
Component: Storage → General
Product: Toolkit → Firefox
(In reply to Marco Bonardo [::mak] from comment #46)
> (In reply to atosdo from comment #45)
> > When I run or close Firefox, Windows Defender loads the CPU on almost 30%.
> > It is slowing down my OS for a minute, maybe.
> 
> What's your Windows Defender Engine Version? (see comment 36).

Anti-malware client version: 4.18.1806.18062
Subsystem version: 1.1.15100.1
The version of the antivirus program: 1.273.266.0
Anti-spyware version: 1.273.266.0
Even with Windows Defender turned off, there are instances where Firefox has excessive disk activity. Heavy writes to SSD just by scrolling down on a webpage using a new profile. Bug 1478417.
Logs, taken with Windows Defender disabled and using a new Firefox profile.

https://bugzilla.mozilla.org/attachment.cgi?id=8995411
Component: General → Other
Product: Firefox → External Software Affecting Firefox
I fixed the issue, for now, by deleting some Windows Defender database files as mentioned in this thread:

[MODIFYING SYSTEM FILES. DO IT AT YOUR OWN RISK.]
https://www.tenforums.com/performance-maintenance/114874-high-cpu-usage-windows-defender-4.html#post1432496

I removed all the exclusions in Defender. Defender's CPU usage still spikes when browsing with Nightly but Defender does not affect the performance as much as before.

Antimalware Client Version: 4.18.1807.18075
Engine Version: 1.1.15100.1
Antivirus Version: 1.273.1208.0
Antispyware Version: 1.273.1208.0
OH MY GOD,

I can't believe how fast my Laptop is right now after uninstalling "Microsoft Security Essentials" and installing "Avast" antivirus on my "Windows 7 Professional x 64 bit"!

I really still can't believe that "Microsoft Security Essentials" was the culprit for my Laptop slowness for over 1 to 2 months! (problem started from June!)

I was already thinking that my relatively new purchased Laptop was already malfunctioning and I was already thinking on replacing it!

Shame on you Micro$oft, 2 MONTHS ? 2 MONTHS and you still didn't fix this bug yet?

I am\was a 8 years "Microsoft Security Essentials" user, but "This Is It", I will never ever use it again! NEVER EVER!
One user reports this happening whenever prefs.js is altered which occurs almost every page load when sync is enabled due to services.sync.globalScore changing between 0-4. Disabling sync, using a private window or whitelisting prefs.js in Windows Defender avoids the problem.

https://www.reddit.com/r/firefox/comments/97ye1k/windows_defender_makes_firefox_virtually_unusable/e4c8pms/
Flags: needinfo?(dolske)
This problem happens on Windows 8.1 as well, I had to add Firefox to excluded processes to avoid the 30% CPU usage from MsMpEng whenever I did an action on Firefox (adding the prefs.js file to exclusions dind't work for me).

Problem reported back in february, we're midway into august and the problem is still happening.

Why is Firefox having so much bad luck lately? first chrome-only pages, next youtube slowing it down and now Microsoft slowing it down as well...
(In reply to Fanolian from comment #51)
> I fixed the issue, for now, by deleting some Windows Defender database files
> as mentioned in this thread:
> 
> [MODIFYING SYSTEM FILES. DO IT AT YOUR OWN RISK.]
> https://www.tenforums.com/performance-maintenance/114874-high-cpu-usage-
> windows-defender-4.html#post1432496

This worked for me too. I killed the msmpeng.exe process with process hacker, deleted all three mpenginedb.db files from the folder C:\ProgramData\Microsoft\Microsoft Antimalware\Scans, restarted the process, and it was happy. Yes, it automatically re-created the files at a much smaller size. The main db file was 114MB before deleting, now is 4KB. I haven't noticed any negative consequences resulting from deleting these files so far.

Before deleting those files, msmpeng.exe would consistently drain 8% cpu when browser was open and in foreground. Now it spikes to 1% briefly only when a page is loading, then returns to idle. Sounds like it's back to normal.
Flags: needinfo?(dolske)
Should we contact Microsoft about this problem or is there a workaround we could employ?
Flags: needinfo?(jmathies)
I wound up disabling Windows Defender via the registry, because it was making my dual-Xeon workstation unusable. :-/
I don't see the etilqs files or high IO activity reported previously which may have been fixed by 1.1.15100.

I tried reproducing comment 53 myself but could only see small 3% MsMpEng spikes when changing prefs.js, not the "15% of my CPU for 4 or so seconds" which was claimed. However I do see this kind of behavior when loading websites.

I reloaded youtube.com six times with Ctrl+F5 on Firefox, Edge and Chrome, visualizing MsMpEng performance with Process Explorer. Firefox produces consistent 15% CPU spikes while the others only around 3%. I tried looking for a regression on the Firefox side but the behavior was the same going back to 2014. Excluding the process "firefox.exe" from Windows Defender avoids any CPU usage.

Testing was done on a new Windows 10 1803 installation running in a VM (1 CPU @ 3GHz) with default Windows Defender settings.

Antimalware Client Version: 4.18.1807.18075
Engine Version: 1.1.15100.1
Antivirus Version: 1.273.1723.0
Antispyware Version: 1.273.1723.0
(In reply to Kestrel from comment #58)
> I reloaded youtube.com six times with Ctrl+F5 on Firefox, Edge and Chrome,
> visualizing MsMpEng performance with Process Explorer. Firefox produces
> consistent 15% CPU spikes while the others only around 3%. 

Can you please try to disable the disk cache in 'about:config' with browser.cache.disk.enable switched to false and let us know?  Thanks.
Flags: needinfo?(ke5trel)
With browser.cache.disk.enable = false, MsMpEng is around 3% CPU with the same test case, similar to other browsers (also observed in comment 53 with private windows). Excluding the profile's cache folder in Windows Defender has a similar effect.

Using Process Monitor to count MsMpEng events for 30 seconds after reloading youtube.com (Ctrl+F5) I get the following (numbers are very rough):

Firefox (disk cache on): 1300 total events, 800 cache events, 50 files, 3MB
Firefox (disk cache off): 300 total events, 0 cache events, 0 files, 0MB
Chrome: 500 total events, 90 cache events, 10 files, 2MB
Edge: 400 total events, 0 cache events (800 ignored), 45 files, 7MB

A large number of cache events requires MsMpEng to do more work. Chrome has fewer cache events and writes fewer files to disk while Edge is excluding cache files from real-time scanning (and treats them as protected OS files).
Flags: needinfo?(ke5trel)
(In reply to Kestrel from comment #61)

Thanks!  These are very interesting numbers and findings.

Can you please define what exactly a "cache event" means?

The other interesting bit about Edge treating the cache files as protected files, how exactly have you determined that and where does the storage resides for you on disk?
(In reply to Marco Castelluccio [:marco] from comment #56)
> Should we contact Microsoft about this problem or is there a workaround we
> could employ?

Seems like a good place to start would be to post to the Microsoft list. We shouldn't be getting dragged down by Microsoft's any-malware activities.
Flags: needinfo?(jmathies)
Kestrel, please see comment 62.  Thanks.
Flags: needinfo?(ke5trel)
I see we already contacted Microsoft, I've contacted them again to make them aware that the problem persists for some users.
Microsoft suggested to send feedback directly to them through the feedback hub, with these steps:
1. When submitting new feedback for Windows Defender, please be sure you file a ‘Problem’ (not suggestion);
2. Pick "Category: ’Security and Privacy’" and "Subcategory:’Windows Defender Antivirus’";
3. After summarizing and giving verbose details, press "Recreate my problem". Make sure you check "Include Data about' Windows Defender Antivirus (Default) and press "Start Capture" to start collecting logs/traces;
4. Reproduce your scenario that causes the issue;
5. Once you are done reproducing the issue, go back to the Feedback app and click the ‘Stop Capture' link;;
6. And of course submit you the feedback to finalize the process!

After this, you should receive an email with a feedback ID. If you send it to me I will send it directly to Microsoft to speed up the investigation.
Assignee: nobody → honzab.moz

Sorry, I'm constantly not getting to this; releasing for anyone else to take over.

Assignee: honzab.moz → nobody
Flags: needinfo?(ke5trel)
Whiteboard: [qf]

Marco - what has happened with Microsoft here? Do you know if it's still happening; if so can you guess how common it is?

Flags: needinfo?(mcastelluccio)

Marking this as p2 since any user with an HDD will likely experience real pain from anything that triggers windows defender to be more active.

Whiteboard: [qf] → [qf:p2:resource]

No news. This was the discussion with Microsoft: https://groups.google.com/a/mozilla.com/forum/#!topic/mozilla-microsoft-discuss/r9-o4W7kBMo.
In the last email they sent me (directly, not on that mailing list) they pretty much asked what I said in comment 66.

Flags: needinfo?(mcastelluccio)

Thunderbird also sometimes encounters performance issues with defender - https://mzl.la/2X0xpze

Summary: Antimalware Service Executable very active when using Firefox → Antimalware Service Executable (Windows Defender) very active / high CPU when using Firefox

Still happening today. After a while with Firefox Nightly 80 open the laptop fans start going to max and I check the Task Manager, lo and behold there's Firefox choking the entire CPU and the AntiMalware service CPU usage a little bit higher whenever that is happening. Every single day this annoying thing happens and every single time I have to close Firefox and open it again to stop it. Every single time I have to lose any progress I have just to stop this idiotic nonsense.
I already excluded all the Firefox folders from scans, I also excluded temp folders and cache folders, this is an absolutely horrible experience.
There have been situations where the Firefox was left open overnight and all night long the CPU was hammered and the fans at max speed, the whole night. This deteriorates the laptop lifetime and I don't know how much longer I will be waiting for this to be fixed before just dropping Firefox completely.

Hi, can you follow the steps in https://bugzilla.mozilla.org/show_bug.cgi?id=1441918#c66 and report the feedback ID? We can try to nudge Microsoft to look into it perhaps.

There's nothing actionable in Firefox itself here, unfortunately.

Flags: needinfo?(particlecore)

(In reply to Gian-Carlo Pascutto [:gcp] from comment #73)

Hi, can you follow the steps in https://bugzilla.mozilla.org/show_bug.cgi?id=1441918#c66 and report the feedback ID? We can try to nudge Microsoft to look into it perhaps.

There's nothing actionable in Firefox itself here, unfortunately.

I already disabled the AntiMalware service entirely and Firefox continues to lock at 25% cpu usage after a while, randomly. This is on a fresh profile with no addons installed. I have to restart the browser to get this under control, otherwise it just chugs the process constantly for absolutely no reason whatsoever.

Is there any way we can inspect what Firefox is writing to during that time? This is f*ing annoying and is driving me nuts for months.

Flags: needinfo?(particlecore)

I have been able to reproduce the high CPU usage on my end consistently and it is always always always after Firefox updates itself while I am still using it and I do not restart it for a while.

This is how I am reproducing it (at least on Nightly, regardless of which version it is):

Use the browser for an entire day without restarting it once, keep it always open and use it as normal with as around 12 tabs or just 4, makes no difference

Firefox options menu will eventually show a green dot notification typically associated with the restart prompt, ignore it

Keep using the browser and, again, never restart it or close the browser once during this whole process

Eventually the CPU usage will start ramping up on its own, especially when you're idle, and will stay locked at that CPU usage permanently. For me it has been lately locked at constant 25% usage


How do I know this is because of the update? Because I disabled the auto update option in the browser and now it has NEVER EVER DONE IT AGAIN until I tell it to download the update. Then it happens again, without exception.

This is the difference between keeping the browser open for 3 days, never closing it once, with the PC going into sleep mode at the end of the day and the CPU NEVER RAMPS UP on its own. It only does whenever it is doing demanding tasks, like watching high FPS videos on YouTube.

vs

Letting the browser update itself and never restarting it, guaranteed to start ramping up the CPU over time and staying completely locked at 25% CPU usage for no fng reason whatsoever. And I mean, I am away from the PC with nothing running and I start hearing the fans blowing constantly as a result of this. Every. Single. Time. It's Firefox locked at 25% cpu usage. EVERY. SINGLE. TIME.

I am seeing Firefox become unusable sometime after an update becomes available, but if it is related I am not in a position to say. I use the update restart to reduce memory usage as at that time memory will be out to around 4Gb and my system frantically paging, a restart will bring it back to less that 500mb usually. I use ESET, not Defender, though.

Performance Impact: --- → P2
Whiteboard: [qf:p2:resource]
Severity: normal → S3
Performance Impact: medium → ---

Some new reports of this popping up: https://www.reddit.com/r/firefox/comments/zyzsk6/high_cpu_usage_from_windows_defenderantimalware/

I'm personally running Win10 22H2 Build 19045.2604, all latest updates and I encounter this problem too.

Excluding the Appdata/Roaming/Mozilla and Appdata/Local/Mozilla folders alleviates the problem and brings the CPU usage down to what other browsers (Edge, Chrome) cause.

Things I've tried to alleviate

  • Disable accessibility services
  • Uninstall Firefox, manually getting rid of all Mozilla folders, and reinstalling, starting a new profile

I've started noticing it now because I have a new CPU (5900X) that gets a bit hotter when a thread spins up, resulting in a variation of my fan speed.

(In reply to Jeroen Baert from comment #77)

Some new reports of this popping up: https://www.reddit.com/r/firefox/comments/zyzsk6/high_cpu_usage_from_windows_defenderantimalware/

I'm personally running Win10 22H2 Build 19045.2604, all latest updates and I encounter this problem too.

Hello,

Thank you for sharing this. I think I can reproduce the problem, so I will provide some data that describes what happens on my machine in this comment. It would be helpful if you could confirm if the data looks similar on your machine, to be sure that I can use my own machine as a basis for investigating this issue. I will describe how to collect similar data by yourself in a second comment.

I recorded a session with Windows Performance Recorder, then opened it in Windows Performance Analyzer. I only had Firefox open when I did the test. What I did was launch youtube.com once, wait for 10 seconds, refresh it, and again (in total, 5 loads). I did the same in Chrome (after disabling Software Reporter Tool which was somehow having a lot of CPU activity on my machine, which could have affected the experiment). Attachments show the activity graph for the most active processes in each session, then the details of where MsMpEng.exe spent CPU time in both sessions. Firefox session is always shown at the top, and Chrome at the bottom.

MsMpEng.exe's CPU activity is shown with red bars, while the useful processes are shown with other colors. We can see that with both Firefox and Chrome, MsMpEng.exe's activity is correlated to the activity of the other processes: it is high when Firefox or Chrome processes themselves have high CPU activity. This is explained by the fact that MsMpEng.exe spends most of its CPU time in sechost.dll!ProcessTrace, in other words it is busy processing ETW events that result from the activity of other processes. However, the CPU time used overall by MsMpEng.exe seems indeed much higher (5x) with Firefox compared to Chrome. By trying to list the specific ETW events which MsMpEng.exe is listening to, we may identify that there are some events which Firefox's current behavior generates a lot of, and in that case we could then try to reduce the amount that we generate. So, if the Firefox graph looks similar on the reporter's machine, then I can try doing that.

Note: I see no disk activity from MsMpEng.exe, so for the moment this looks like legitimate MsMpEng.exe activity (although high) to me, unlike (my understanding of) the original bug.

Attached image wpr-config.png

To produce the data, first I recommend looking at the short video tutorial here from Microsoft to have an overview of the interface of Windows Performance Analyzer. Then, here are the steps to reproduce the graph and numbers from the first image:

  1. Install Windows Performance Recorder and Windows Performance Analyzer from the Windows ADK for your version of Windows. For Windows 10 22H2 I think this one should work. You only need to select Windows Performance Toolkit as a feature after launching the ADK installer.
  2. Close as many open applications as possible to avoid noise in collecting the data.
  3. Open Windows Performance Recorder and configure it as shown in attachment. Click Start.
  4. Open Firefox and do the steps for which you want to analyze performance (e.g. load YouTube 5 times separated by intervals of 10 seconds).
  5. Back in Windows Performance Recorder, click Save, click Save, click Open in WPA.
  6. If Windows Performance Analyzer fails to load with error 0x80070032, install Windows Performance Analyzer Preview from the Windows Store and load the saved file from there to avoid the error (I personally have to do this).
  7. In Windows Performance Analyzer, unroll Computation, drag and drop CPU Usage (Precise) to the currently empty Analysis tab. A graph shows up.
  8. Under Series, navigate to the top. The processes are sorted based on which were the most active (hopefully, some firefox.exe processes and MsMpEng.exe). By using shift-clicking or control-clicking, select the most active firefox.exe processes and MsMpEng.exe, but not Idle (which is not a process). Then, right-click, Disable, All but selection.
  9. Near, Utilization by Process, Thread, Stack, there is a Select Chart Type button. Click it and select Stacked bars, then move the cursor towards Max.
  10. (Optional) Select the relevant portion of the graph, right-click, Zoom.
  11. Use Snipping Tool to save and share the graph.

Note: Please share only the graph, and not the raw file saved by Windows Performance Recorder which may contain private information.

Note: The graph and numbers should be enough assuming that it looks reasonably similar to mine. To reproduce the detailed activity of MsMpEng.exe, the steps are mostly the same, but you would need to set Detail level to Verbose when recording, then after all the previous steps in WPA you would click the Trace menu, click Load Symbols, wait a long time, and then progressively unroll the top-most entries under MsMpEng.exe like in the image I shared.

Hello,

Here is a short update on this issue:

  • There is a serious performance issue in the current version of MsMpEng.exe, which I was able to pinpoint using the WPR profiles from comment 78 and some debugging. We have reported the details to Microsoft, and they have acknowledged it.
  • This performance issue makes calls to VirtualProtect (among other things) unreasonably expensive on Windows platforms when Windows Defender's Real-time Protection feature is active (the unreasonably expensive computations execute in the MsMpEng.exe process). Microsoft has applied a patch that will mitigate the issue with the upcoming March release (engine version 1.1.20200.2), which means that users will gradually get the fix within the next 4 weeks. People who would like to bypass the progressive rollout and get the patch sooner (i.e. next week) can use Set-MpPreference -EngineUpdatesChannel Preview.
  • With a standard Firefox configuration, the amount of calls to VirtualProtect is currently very high, and that is what explains the high CPU usage with Firefox. The information that the most impactful event originates from calls to VirtualProtect was forwarded to us by Microsoft, and I confirm it. In Firefox, disabling JIT makes MsMpEng.exe behave much more reasonably, as JIT engines are the source of the vast majority of calls to VirtualProtect.
  • On Firefox's side, independently from the issue mentioned above, we should not consider that calls to VirtualProtect are cheap. We should look for opportunities to group multiple calls to VirtualProtect together, if possible. Even after the performance issue will be mitigated, each call to VirtualProtect will still trigger some amount of computation in MsMpEng.exe (or third-party AV software); the computation will just be more reasonably expensive.

I will provide more details with numbers later.

(In reply to Jeroen Baert from comment #77)

Some new reports of this popping up: https://www.reddit.com/r/firefox/comments/zyzsk6/high_cpu_usage_from_windows_defenderantimalware/

I'm personally running Win10 22H2 Build 19045.2604, all latest updates and I encounter this problem too.

Can you confirm if MsMpEng.exe behaves more reasonably after navigating to about:config in Firefox and changing the following preferences:

  • set javascript.options.baselinejit to false;
  • set javascript.options.wasm_baselinejit to false;
  • set javascript.options.wasm_optimizingjit to false.

If that doesn't solve the issue, you might be experiencing a different issue from the one mentioned in comment 82.

Flags: needinfo?(jerbae)

This image shows the impact of the preferences listed in comment 83 on my personal machine: top is with JIT, bottom is without JIT. We can see that for the specific case of loading youtube.com 5 times in Firefox:

  • MsMpEng.exe total CPU time decreases from 16s to 6s by disabling JIT in Firefox (so 63% less CPU time);
  • firefox.exe total CPU time summed for the most active processes is around 23.5s independently of whether or not we are using JIT in Firefox.

I would also like to add that this high CPU usage issue while using Firefox is not exclusive to Microsoft Defender. It's an issue for Norton's AV products also and should be the same for Symantec Endpoint products too.
So, you should also test them.

(In reply to SeriousHoax from comment #85)

I would also like to add that this high CPU usage issue while using Firefox is not exclusive to Microsoft Defender. It's an issue for Norton's AV products also and should be the same for Symantec Endpoint products too.
So, you should also test them.

Hello, if you have one of these AV products installed, can you confirm if the steps comment 83 impact the CPU usage of your AV processes? Can you share some CPU usage measurements like described in comment 81?

Flags: needinfo?(serioushoax)

(In reply to Yannis Juglaret from comment #82)

  • There is a serious performance issue in the current version of MsMpEng.exe, which I was able to pinpoint using the WPR profiles from comment 78 and some debugging. We have reported the details to Microsoft, and they have acknowledged it.

Let me share more details on this, as this may be interesting for other AV vendors who would be watching this discussion. The TdhFormatProperty can be used to get information associated with ETW events. This function has the following prototype:

TDHSTATUS TdhFormatProperty(
  ...,
  [in, out]       PULONG            BufferSize,
  [out, optional] PWCHAR            Buffer,
  ...
);

This is a classic Windows API pattern: you can first call it with a NULL pointer as Buffer to know the required buffer size. Then you can call it a second time with a properly-sized buffer.

// First call to get the required buffer size
ULONG BufferSize = 0;
if (TdhFormatProperty(..., &BufferSize, NULL, ...) == ERROR_INSUFFICIENT_BUFFER && BufferSize > 0) {
    // BufferSize now holds the required buffer size: allocate a buffer and call again
    LPVOID Buffer = HeapAlloc(GetProcessHeap(), 0, BufferSize);
    if (TdhFormatProperty(..., &BufferSize, Buffer, ...) == ERROR_SUCCESS) {
         // All good, we can now use Buffer
    }
}

Except that if you use this classic pattern here, you will have very bad performance with the current implementation of TdhFormatProperty. The code above is, in the best case scenario, equivalent to the one below:

#define KB 1024
// First call to get the required buffer size
ULONG BufferSize = 64 * KB;
LPVOID Buffer = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, BufferSize);
if (TdhFormatProperty(..., &BufferSize, Buffer, ...) == ERROR_SUCCESS) {
    HeapFree(GetProcessHeap(), 0, Buffer);
    // BufferSize now holds the required buffer size: allocate a buffer and call again
    Buffer = HeapAlloc(GetProcessHeap(), 0, BufferSize);
    if (TdhFormatProperty(..., &BufferSize, Buffer, ...) == ERROR_SUCCESS) {
         // All good, we can now use Buffer
    }
}

In other words, with the current implementation of TdhFormatProperty, every call to TdhFormatProperty with a NULL buffer yields an allocation of a 64-KB zero-ed heap buffer. So, for example, because the ETW event for monitoring VirtualProtect has 18 properties, if as an AV vendor you are listening to this event and calling TdhFormatProperty on each of its property using the pattern described above, each call to VirtualProtect on the system will result in the allocation and zero-ing of 18 64-KB buffers in your AV process. If moreover the AV code considers that TdhFormatProperty is not expensive, and calls it multiple times for the same property, that makes the situation even worse.

As a result of using the pattern described above, MsMpEng.exe was spending 48% of its time allocating and zero-ing 64-KB buffers in the recording from comment 78. Microsoft coincidentally already had a new implementation for TdhFormatProperty on its way when we reported the issue; the new implementation is not there yet but it should enhance the performance of the pattern described above when it gets shipped. However the best fix is to not rely on the pattern from above, and instead reuse the same buffer all the time, and something along those lines will get shipped with Windows Defender engine version 1.1.20200.2.

All this investigation is worth a blog post along the lines of the blog written by Bruce Dawson.

(In reply to Yannis Juglaret from comment #83)

(In reply to Jeroen Baert from comment #77)

Some new reports of this popping up: https://www.reddit.com/r/firefox/comments/zyzsk6/high_cpu_usage_from_windows_defenderantimalware/

I'm personally running Win10 22H2 Build 19045.2604, all latest updates and I encounter this problem too.

Can you confirm if MsMpEng.exe behaves more reasonably after navigating to about:config in Firefox and changing the following preferences:

  • set javascript.options.baselinejit to false;
  • set javascript.options.wasm_baselinejit to false;
  • set javascript.options.wasm_optimizingjit to false.

If that doesn't solve the issue, you might be experiencing a different issue from the one mentioned in comment 82.

I can confirm that toggling these options does seem to have an impact, but haven't reduced the CPU usage of MsMpEng.exe to the low levels of Chrome or Edge. I'm still seeing loads that are 3x that of loading the same website (I usually test with cnn.com, because it's large and full of mixed content) in Chrome/Edge.

Flags: needinfo?(jerbae)

(In reply to Jeroen Baert from comment #89)

I can confirm that toggling these options does seem to have an impact, but haven't reduced the CPU usage of MsMpEng.exe to the low levels of Chrome or Edge. I'm still seeing loads that are 3x that of loading the same website (I usually test with cnn.com, because it's large and full of mixed content) in Chrome/Edge.

Thanks. Your observations align well with the numbers I have obtained experimenting with this. I counted how many events are generated on the Microsoft-Windows-Threat-Intelligence ETW provider when loading YouTube (didn't see significant difference with CNN), and here are the numbers I obtained:

  • Firefox with normal configuration: ~14000 events, 98% of which are PROTECTVM_LOCAL;
  • Firefox with the preferences from comment 83: ~6500 events, 95% of which are PROTECTVM_LOCAL;
  • Edge: ~2000 events, 91% of which are ALLOCVM_LOCAL;
  • Chrome: ~300 events.

So indeed, even with switching the prefs, we still have a high number of calls to VirtualProtect. This problem has two sides: Microsoft was doing a lot of useless computations upon each event; and we are generating a lot of events. The combination is explosive. Now that Microsoft has done their part of the job (comment 82), we need to reduce our dependency to VirtualProtect. Bug 1822650 in particular will help with that.

(In reply to SeriousHoax from comment #85)

I would also like to add that this high CPU usage issue while using Firefox is not exclusive to Microsoft Defender. It's an issue for Norton's AV products also and should be the same for Symantec Endpoint products too.
So, you should also test them.

It is true that we should analyze the situation with other AV vendors, however, given the numbers shared above, and given how relevant it is to keep track of memory protection changes in order to detect malicious behavior, it is very likely that the explanation for Windows Defender also applies (at least in part) to other AV vendors.

I was able to install mpengine.dll version 1.1.20200.3, which should incorporate the fix for the performance issue mentioned in comment 82 and described in comment 87. I confirm that this performance issue has been addressed correctly. Attached is a comparison of a previous recording (top) with a new recording (bottom) when loading YouTube.

The numbers suggest a ~75% improvement in CPU usage from MsMpEng.exe when browsing with Firefox (the specific number applies to browsing youtube.com on my machine), bringing it close to where CPU usage was when browsing with Chrome back in comment 78 (of course, since the performance improvement benefits all programs installed on the system, the new numbers for Chrome should be lower if measured with version 1.1.20200.3 of mpengine.dll).

You can get mpengine.dll version 1.1.20200.3 (currently Beta) as follows:

  • run a Powershell terminal as administrator;
  • type Set-MpPreference -EngineUpdatesChannel Beta, press Enter;
  • open Windows Update, browse updates, a new update should appear, install it;
  • back in the terminal, you can type Set-MpPreference -EngineUpdatesChannel Broad and press Enter if you don't want to stay in Beta for the future.

You can check your version of mpengine.dll as follows:

  • navigate to C:\ProgramData\Microsoft\Windows Defender\Definition Updates\;
  • look for a folder named something like {7C9E9F14-9A1B-4833-AC74-DA15E21884D4}, open it;
  • right click on mpengine.dll, Properties, Details, look for Product version.

Disclaimer: I have also received updates for my whole system and Firefox between the two recordings, which may also partially affect the numbers observed here.

See Also: → 1823634

I am closing this bug as per comment 91 the specific problem for Windows Defender seems fixed. I filed bug 1823634 for future work. Thank you!

Note: Feel free to reopen if the problem is not fixed on your own computer with a version of mpengine.dll higher than 1.1.20200.2.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED

Yannis, is the fix by Microsoft going to be deployed to all users or only users on recent updates of Windows?

According to Microsoft, this will be deployed to all users as part of regular definition updates, which are packaged independently from OS updates. This includes even Windows 7 and 8.1 users, even though these platforms should not have had the performance issue with Firefox in the first place because the ETW events that cause it do not exist on these older versions of Windows. So as far as I understand, only users that would explicitly reject definition updates (which does not sound like something reasonable to do with your AV) would not get the fix.

mpengine.dll version 1.1.20200.4 was released on April 4, so the fix should be available for everybody now. See the end of comment 91 to know what version you are using. Also, the latest discoveries in bug 1822650 comment 6 suggest that we can go even further down in CPU usage, with all antivirus software this time, not just Windows Defender.

There has been some coverage in online news about the fix mentioned in comment 82. You may read online that Defender was making too many calls to VirtualProtect, and that global CPU usage will now go down by 75% when browsing with Firefox. This is absolutely wrong!

The impact of this fix is that on all computers that rely on Microsoft Defender's Real-time Protection feature (which is enabled by default in Windows), MsMpEng.exe will consume much less CPU than before when monitoring the dynamic behavior of any program through ETW. Nothing less, nothing more.

For Firefox this is particularly impactful because Firefox (not Defender!) relies a lot on VirtualProtect (which is monitored by MsMpEng.exe through ETW). We expect that on all these computers, MsMpEng.exe will consume around 75% less CPU than it did before when it is monitoring Firefox. Which is really good news.

This will bring a nice performance bump for our users that have limited CPU resources, where MsMpEng.exe would sometimes consume 20%-30% CPU, and will now consume a single-digit percentage of CPU. It will also benefit other users through lower power consumption.

Blocks: 1835323
Flags: needinfo?(serioushoax)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: