VERY high CPU usage!

Discussion in 'ESET NOD32 Antivirus' started by kopierkatze, Feb 2, 2011.

Thread Status:
Not open for further replies.
  1. kopierkatze

    kopierkatze Registered Member

    Joined:
    Feb 2, 2011
    Posts:
    3
    VERY high CPU usage! (NOD32 and Firefox)

    I have very serious issues with my two NOD32 Antivirus installations!

    "ekrn.exe" causes VERY high CPU usage. It virtually renders my systems completely unusable!
    According to the activity monitor, NOD32 doesn't do anything at all, but it's using two cores all the time (see screenshot)

    My Systems:

    1. Intel Core 2 Quad Q6600, 6GB RAM, Win7 Ultimate x64
    2. Intel Core 2 Duo T5670, 3GB RAM, Win7 Ultimate x86

    Both are running the latest NOD32 Antivirus v4.2.71.2, but these issues also occured with earlier versions.

    What causes these problems?

    I disabled NOD32 for now...
    NOD32 v2.7 was such a good antivirus system, but since then it's only getting worse and worse, slower and slower :-(
    I recommended NOD32 to a lot of other people... I sure won't do that again.

    http://kopierkatze.net/nod32-problem.png
     

    Attached Files:

    Last edited: Feb 2, 2011
  2. Woodgiant

    Woodgiant Guest

    Hello kopierkatze
    Just a wild shoot, but if you have bitlocker turned on, try to turn it off to see if it makes a difference.

    Regards

    Woodgiant
     
  3. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    What were you actually doing when that happened? Copying files, doing a backup, browsing the web, running a disk scan, etc. Does enabling pre-release updates and running a manual update make a difference?
     
  4. bmcchesney

    bmcchesney Registered Member

    Joined:
    Feb 2, 2011
    Posts:
    4
    I am having very similar problems to you.

    System: AMD Phenom 9750 Quad-core 2.40GHz. 4 GB Memory.
    OS: Windows 7 Professional x64 v6.1.7600 (All available updates installed).
    ESET NOD32 Antivirus Business Edition v4.2.71.2

    During my reproduction of the problem I am running:
    Skype
    GIMP - For taking screenshots
    Notepad - For writing this note
    Firefox

    For my test, the above programmes were already running. I enabled ESET protection, switched to Firefox and opened google.co.uk. I followed the link for Google News, and I went back and forward twice. ESET immediately jumped to 50% usage and stayed there for a while, locking Firefox. In this state, firefox is incredibly slow and responds infrequently. Behaviour returns to normal shortly after ESET is disabled again.

    Note that no mail clients are open, and that HTTP protection is disabled. Only file protection can be causing this usage. I can see that ESET is scanning files in the Mozilla profile during reproduction of the problem, which I would expect; yet the CPU usage appears to be disportionately high.

    Screenshot also attached.

    ESET modules:
    Virus signature database: 5840 (20110202)
    Update module: 1031 (20091029)
    Antivirus and antispyware scanner module: 1293 (20101110)
    Advanced heuristics module: 1115 (20101116)
    Archive support module: 1124 (20101214)
    Cleaner module: 1050 (20101207)
    Anti-Stealth support module: 1024 (20101227)
    SysInspector module: 1217 (20100907)
    Self-defense support module : 1018 (20100812)
    Real-time file system protection module: 1004 (20100727)

    Regards,
    Bob McChesney
     

    Attached Files:

    • eset.png
      eset.png
      File size:
      212.9 KB
      Views:
      63
  5. kopierkatze

    kopierkatze Registered Member

    Joined:
    Feb 2, 2011
    Posts:
    3
    I don't use any disk encryption software.

    I found out my problem is probably related to Firefox (and Firefox basically runs all the time on all my machines).

    Seems like there are many other people having the same issue:
    http://support.mozilla.com/de/questions/780370


    @Bob: Try killing Firefox, NOD32 doesn't seem to like that browser. I have no idea WHAT NOD32 actually does and why, as there is no detailed information, only this stupid colorful user interface which doesn't tell you anything. Just try to stop Firefox.


    Are there people from the ESET staff on this board?

    It's a shame they don't even test their software with the most popular browser :gack:
     
  6. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    There are no known problems with Firefox except that SSL scanning doesn't work with Firefox 4 x64.

    Please do some tests and let us know what of the following makes a difference (assuming that you're using the latest version of EAV 4.2.71):
    - disabling web access protection
    - disabling http checking in the advanced setup (F5)
    - disabling real-time protection
    - enabling pre-release updates and running a manual update

    A log from Process Monitor might shed more light.
     
  7. bmcchesney

    bmcchesney Registered Member

    Joined:
    Feb 2, 2011
    Posts:
    4
    Please could you tell me how to turn on pre-release updates? I have enabled the pre-release option, but I get my updates from a company mirror. Anything else I need to do? Still on version 4.2.71.2.

    Regards,
    Bob
     
  8. kopierkatze

    kopierkatze Registered Member

    Joined:
    Feb 2, 2011
    Posts:
    3
    Get it from here:
    http://kopierkatze.net/ekrn-exe_process-monitor-log.rar

    Just a few minutes of logging, but it shows that NOD32 reads "sessionstore.js" (and "sessionstore-4.js", "sessionstore-5.js" ...) all the time...
     
  9. techonecs

    techonecs Registered Member

    Joined:
    Nov 23, 2010
    Posts:
    3
    I'm having this exact same issue. Works fine if Firefox is closed, but if I have FF open and Eset enabled, the CPU usage for ekrn.exe*32 goes WAY up.

    Win7x64 w/ latest FF version.

    (Not trying to hijack, just adding a "me too".)
     
  10. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    Unfortunately, the log has only operations of ekrn.exe filtered. Your sessionstore*.js files are extremely large (> 10 MB) and Firefox is probably frequently writing into them which invokes scanning that takes time. As an interim solution, exclude them from scanning. In order for us to analyze the issue, provide me with a PML log without any filter applied as well those sessionstore*.js files.
     
  11. bmcchesney

    bmcchesney Registered Member

    Joined:
    Feb 2, 2011
    Posts:
    4
    Thanks everyone.

    I've added the exclusion C:\Users\*\AppData\Roaming\Mozilla\Firefox\Profiles\*\sessionstore*

    This appears to have solved my problem. I'll watch this thread for updates.

    kopierkatze, are you happy for me to leave you liaising with ESET in this thread, or would you like me to submit my case too? My Windows installation is one day old, my Firefox the same with new profile, and add-ons are only those that would get installed with common software installations (Adobe Acrobat, Java Development Toolkit, Java Platform SE, Microsoft Office 2010, Shockwave Flash, Silverlight Plug-In). I think it should be easy for ESET to reproduce, but I can submit if required.

    Regards,
    Bob
     
  12. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    Alternatively you can select Tools -> Clear recent history (everything) to reduce the size of sessionstore*.js.
     
  13. foolbritannia

    foolbritannia Registered Member

    Joined:
    Feb 4, 2011
    Posts:
    1
    Yep,

    Just to confirm I have been having the same issue between NOD32 (v4.0.424.0) and Mozilla Firefox (v3.6.13). It started on Tuesday 01/02/11 and I could not resolve so had to switch to IE (yuck!).

    Thanks for the posts above - putting the exclusion into NOD32 worked a treat and like Bob I will watch for an update/resolution.

    Jeremy
     
  14. nicklaz

    nicklaz Registered Member

    Joined:
    May 12, 2009
    Posts:
    2
    same issue here as well. windows xp, eset build 4.0.437.0 with firefox 3.6.13

    i added the whole profile directory to the exclusion list which did the trick for now. hoping for a better resolution though.
     
    Last edited: Feb 7, 2011
  15. bmcchesney

    bmcchesney Registered Member

    Joined:
    Feb 2, 2011
    Posts:
    4
    Come on ESET! The kind of people that buy your software are the kind of people that use Firefox! Reealistically, you've got to test your software against your software against it, and you can't blame it for reading a file too often.

    Do we need to report this elsewhere, or are you working on it?
     
  16. stratoc

    stratoc Guest

    need to find out what's causing this, I am running 2 machines (1 vista 32 bit and 1 64 bit 7) only use firefox and am having no issues at all. Maybe something clashing?
    Just wanted to post so everyone is aware it doesn't happen on every configuration.
    both pc's have latest eset smart, malwarebytes (realtime disabled) and hitman pro.
    if this helps at all.
    oh and firefox 3.6.13
     
  17. razen

    razen Registered Member

    Joined:
    Feb 6, 2011
    Posts:
    1
    Ruh nning 3 machines. 2 @ W7 64bit and 1 @ xp. 2 64bit machines are each core. One machine has multiple FF windows open all the time and experiences 50% usage (1 core) by eset. Other two machines have no windows open on a normal basis.

    Put sessionstore exclusion in. Everything work fine now.

    (had been wondering why this problem had started up some 5 days ago - how did this get by testing?)
     
  18. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    Yep, we'd better ask Mozilla. I'll try to get in touch with them to sort this out. How large is your sessionstore.js ?
     
  19. emjay125

    emjay125 Registered Member

    Joined:
    Feb 7, 2011
    Posts:
    1
    I also have this on 2 machines, both running XP and Firefox I even tried downgrading Firefox as the problem seemed to have started when I upgraded to FF 3.6. something.

    I am getting 100% CPU usage by ekrn.exe

    I added sessionstore*.js to the exclusion list with no effect. ie Docs and Settings\me\app data\mozilla\profiles\\myprofile\sessionstore*.js

    I deleted 700mb of sessionstore*.js but it made no difference. Still horribly slow.
    to the point of uselessness.

    1 hour later ...

    I have now restarted and it seemed OK for 3 minutes, then 100 % but now, after 10 minutes or so it plunges to 93 % occasionally.
     
    Last edited: Feb 7, 2011
  20. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    We've got a couple of such large js files and investigating what could be done to circumvent the issue safely. A log from Process Monitor should always shed more light when scanning of certain files causes problems.
     
  21. techonecs

    techonecs Registered Member

    Joined:
    Nov 23, 2010
    Posts:
    3
    emjay125: Try putting this exact string in your exclusions; it's what I had to do to get it to work (except I have Win7, so D&S is "users" on mine):

    C:\Documents and Settings\*\AppData\Roaming\Mozilla\Firefox\Profiles\*\sessionstore*

    (assuming your FF profile/installation is in the default location)
     
  22. BobbyZee

    BobbyZee Registered Member

    Joined:
    Aug 9, 2009
    Posts:
    7
    No,no,no chesney, not all ESET users use FF! Did use it once but progressed to
    Google Chrome and am now using Opera11 which is actually faster than Chrome
    and now at last has plentiful extensions/add-ons, granted, not as many as FF!

    Don't really care which browser one uses, this post is really about your inference
    that "ESET users are the kind of people that use FF", tosh!

    Cheers, BobbyZee
     
  23. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    Does anybody still experience the issue after removing the sessionstore*.js files from the exclusion list?
     
  24. Modulo

    Modulo Registered Member

    Joined:
    Feb 9, 2011
    Posts:
    1
    I removed the exclusion and now for me everything is fine.
    Thanks !
     
  25. Nick0

    Nick0 Registered Member

    Joined:
    Feb 18, 2010
    Posts:
    32
    Just had another case of this, adding the exclusion solved the issue perfectly:

    C:\Documents and Settings\"usersname"\application data\mozilla\profiles\\"randomtext"\*
     
Thread Status:
Not open for further replies.