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)
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.
Comment 1•6 years ago
|
||
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.
Comment 2•6 years ago
|
||
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.
Comment 3•6 years ago
|
||
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.
Updated•6 years ago
|
Reporter | ||
Comment 4•6 years ago
|
||
(In reply to Marco Bonardo [::mak] from comment #3) > Are you on Firefox 64 or 32 bits? I am using 64bit Firefox
Comment 5•6 years ago
|
||
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.
Reporter | ||
Comment 6•6 years ago
|
||
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...
Comment 7•6 years ago
|
||
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.
Comment 8•6 years ago
|
||
(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.
Comment 9•6 years ago
|
||
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.
Reporter | ||
Comment 10•6 years ago
|
||
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)
Comment 11•6 years ago
|
||
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.
Reporter | ||
Comment 12•6 years ago
|
||
Setting a needinfo for myself to check in on that next week.
Reporter | ||
Comment 13•6 years ago
|
||
(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.
Comment 14•6 years ago
|
||
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
Comment 15•6 years ago
|
||
(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.
Comment 16•6 years ago
|
||
ehr, looks like Connect has been retired and now the supposed way to report bugs is the Windows Feedback Hub app.
Comment 17•6 years ago
|
||
(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...
Comment 18•6 years ago
|
||
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.
Comment 19•6 years ago
|
||
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"
Comment 20•6 years ago
|
||
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 :)
Comment 21•6 years ago
|
||
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.
Comment 22•6 years ago
|
||
mkaply, since you often worked with AV providers, do we have any contacts with Microsoft we could use here?
Comment 23•6 years ago
|
||
Does it change anything if instead of excluding the mozilla profile folders, you just temporarily exclude the *.tmp extension?
Comment 24•6 years ago
|
||
(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
Comment 25•6 years ago
|
||
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?
Comment 26•6 years ago
|
||
I haven't worked much on the Microsoft side, but I know Jim has.
Comment 27•6 years ago
|
||
(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.
Comment 28•6 years ago
|
||
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.
Comment 29•6 years ago
|
||
I can readily repro this, in case anybody needs another tester.
Comment 30•6 years ago
|
||
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.
Comment 31•6 years ago
|
||
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.
Comment 32•6 years ago
|
||
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.
Comment 33•6 years ago
|
||
Fwiw, I notified our Microsoft contacts through the mailing list, I guess for now it's just matter of waiting.
Comment 34•6 years ago
|
||
It seems the problem is gone me. Windows 10 1709 Build 16299.547 Firefox 61.0.1 (64-bit)
Comment 35•6 years ago
|
||
(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
Comment 36•6 years ago
|
||
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.
Comment 37•6 years ago
|
||
(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?
Comment 38•6 years ago
|
||
We have contacted them.
Comment 39•6 years ago
|
||
(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.
Comment 40•6 years ago
|
||
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...
Comment 41•6 years ago
|
||
(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.
Comment 42•6 years ago
|
||
(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.
Comment 43•6 years ago
|
||
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.
Comment 44•6 years ago
|
||
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.
Comment 45•6 years ago
|
||
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.
Comment 46•6 years ago
|
||
(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).
Comment 47•6 years ago
|
||
Anyway, at this point there's no strict reason to keep this under Storage, we already clarified it's not mozStorage causing the problem.
Comment 48•6 years ago
|
||
(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
Comment 49•6 years ago
|
||
unrelated |
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.
Comment 50•6 years ago
|
||
unrelated |
Logs, taken with Windows Defender disabled and using a new Firefox profile. https://bugzilla.mozilla.org/attachment.cgi?id=8995411
Updated•6 years ago
|
Comment 51•6 years ago
|
||
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
Comment 52•6 years ago
|
||
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!
Comment 53•6 years ago
|
||
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/
Comment 54•6 years ago
|
||
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...
Comment 55•6 years ago
|
||
(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.
Updated•6 years ago
|
Comment 56•6 years ago
|
||
Should we contact Microsoft about this problem or is there a workaround we could employ?
Comment 57•6 years ago
|
||
I wound up disabling Windows Defender via the registry, because it was making my dual-Xeon workstation unusable. :-/
Comment 58•6 years ago
|
||
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
Comment 59•6 years ago
|
||
Comment 60•6 years ago
|
||
(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.
Comment 61•6 years ago
|
||
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).
Comment 62•6 years ago
|
||
(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?
Comment 63•6 years ago
|
||
(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.
Comment 65•6 years ago
|
||
I see we already contacted Microsoft, I've contacted them again to make them aware that the problem persists for some users.
Comment 66•6 years ago
|
||
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.
Updated•5 years ago
|
Comment 67•5 years ago
|
||
Sorry, I'm constantly not getting to this; releasing for anyone else to take over.
Updated•5 years ago
|
Comment 68•5 years ago
|
||
Marco - what has happened with Microsoft here? Do you know if it's still happening; if so can you guess how common it is?
Comment 69•5 years ago
|
||
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.
Comment 70•5 years ago
|
||
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.
Comment 71•4 years ago
|
||
Thunderbird also sometimes encounters performance issues with defender - https://mzl.la/2X0xpze
Comment 72•4 years ago
|
||
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.
Comment 73•4 years ago
|
||
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.
Comment 74•3 years ago
|
||
(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.
Comment 75•3 years ago
|
||
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.
Comment 76•3 years ago
|
||
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.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 77•1 year ago
|
||
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.
Updated•1 year ago
|
Comment 78•1 year ago
|
||
Comment 79•1 year ago
|
||
Comment 80•1 year ago
•
|
||
(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.
Comment 81•1 year ago
•
|
||
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:
- 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.
- Close as many open applications as possible to avoid noise in collecting the data.
- Open Windows Performance Recorder and configure it as shown in attachment. Click
Start
. - 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).
- Back in Windows Performance Recorder, click
Save
, clickSave
, clickOpen in WPA
. - 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).
- In Windows Performance Analyzer, unroll
Computation
, drag and dropCPU Usage (Precise)
to the currently emptyAnalysis
tab. A graph shows up. - Under
Series
, navigate to the top. The processes are sorted based on which were the most active (hopefully, somefirefox.exe
processes andMsMpEng.exe
). By using shift-clicking or control-clicking, select the most activefirefox.exe
processes andMsMpEng.exe
, but notIdle
(which is not a process). Then, right-click,Disable
,All but selection
. - Near,
Utilization by Process, Thread, Stack
, there is aSelect Chart Type
button. Click it and selectStacked bars
, then move the cursor towardsMax
. - (Optional) Select the relevant portion of the graph, right-click,
Zoom
. - 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.
Comment 82•1 year ago
•
|
||
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 theMsMpEng.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 useSet-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 toVirtualProtect
was forwarded to us by Microsoft, and I confirm it. In Firefox, disabling JIT makesMsMpEng.exe
behave much more reasonably, as JIT engines are the source of the vast majority of calls toVirtualProtect
. - 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 toVirtualProtect
together, if possible. Even after the performance issue will be mitigated, each call toVirtualProtect
will still trigger some amount of computation inMsMpEng.exe
(or third-party AV software); the computation will just be more reasonably expensive.
I will provide more details with numbers later.
Comment 83•1 year ago
•
|
||
(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
tofalse
; - set
javascript.options.wasm_baselinejit
tofalse
; - set
javascript.options.wasm_optimizingjit
tofalse
.
If that doesn't solve the issue, you might be experiencing a different issue from the one mentioned in comment 82.
Comment 84•1 year ago
•
|
||
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.
Comment 85•1 year ago
|
||
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.
Comment 86•1 year ago
|
||
(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?
Comment 87•1 year ago
•
|
||
(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.
Comment 88•1 year ago
|
||
All this investigation is worth a blog post along the lines of the blog written by Bruce Dawson.
Comment 89•1 year ago
|
||
(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 toabout:config
in Firefox and changing the following preferences:
- set
javascript.options.baselinejit
tofalse
;- set
javascript.options.wasm_baselinejit
tofalse
;- set
javascript.options.wasm_optimizingjit
tofalse
.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.
Updated•1 year ago
|
Comment 90•1 year ago
•
|
||
(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.
Comment 91•1 year ago
•
|
||
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 forProduct 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.
Comment 92•1 year ago
•
|
||
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.
Comment 93•1 year ago
|
||
Yannis, is the fix by Microsoft going to be deployed to all users or only users on recent updates of Windows?
Comment 94•1 year ago
•
|
||
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.
Comment 95•1 year ago
•
|
||
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.
Comment 96•1 year ago
•
|
||
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.
Comment 97•1 year ago
|
||
By the way, the observations from comment 91 have been confirmed by a few Reddit users:
"Can confirm, CPU usage from constant 20% to only a couple %."
"MsMpEng on my home machine has dropped from 15-20% util to 0-1% util, on my work machine it's still at 50% as awaiting the definitions update."
Updated•1 month ago
|
Description
•