High CPU Useage?

Discussion in 'ESET Smart Security v3 Beta Forum' started by fredra, May 17, 2007.

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

    fredra Registered Member

    Joined:
    Jul 25, 2004
    Posts:
    366
    Hi
    I tried searching to find if this subject was raised, or if anyone else has this problem. I can't seem to find any mention, so I started this thread, trying to get some answers.
    I have ESS installed and updated. While sufing the web, IE7 stops responding and nothing is able to be launched (except TM).
    Launch TM and the file "EKRN.EXE" is taking 89-99% of CPU, after a few mins. it drops down to 0% with 27012K, and everything now returns to normal.
    - Is anyone else seeing this?
    - What is "ekrn" doing during the timeframe of high CPU use?
    Could someone shed any light on this annomally?
    Thanks.
    Cheers :)
     
  2. mil3s

    mil3s Registered Member

    Joined:
    Apr 10, 2007
    Posts:
    9
    I have similar problems.

    In Firefox when a large file download gets to 100% Firefox freeze and EKRN.EXE will use 50% CPU for some time depending on the size of the file.

    This also happens when renaming files or moving them.

    It's a little annoying. :p
     
  3. GNaschenweng

    GNaschenweng Registered Member

    Joined:
    May 7, 2007
    Posts:
    10
    Got the same issues on Vista Ultimate/32. I noticed this on any large downloads - especially when using GetRight / OrbitDownloader or using IBM's DownloadDirector.

    CPU spikes then to 100% on EKRN.EXE and in some instances Vista does not respond and needs to be cold-booted (TM does not come up).

    Just now I noticed that I had the same behaviour after logon, and it took about 5 minutes to settle.

    Did not notice this behaviour with the previous release.
     
  4. fredra

    fredra Registered Member

    Joined:
    Jul 25, 2004
    Posts:
    366
    Hi
    I appreciate the posting and clarification from both of you.
    Now that it appears that this is not isolated (or my being picky :doubt: ), I hope someone from ESET will be able to look into this potential problem.
    It is not good to fool Mother Vista :D :D :D :D :D
    LOL :D
    Cheers :)
     
  5. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    I assume that either disabling runtimne packers, advanced heuristics or self-extracting archives will resolve the issue, but especially the first two are vital and I'd never disable them in spite of speed degradation in certain cases when scanning complexly runtime packed files.
     
  6. fredra

    fredra Registered Member

    Joined:
    Jul 25, 2004
    Posts:
    366
    Hi Marcos
    With due respect to your expertize and knowledge ........ you lost me with that response o_O
    I am NOT questioning your help, just making sure I grasp the implications ... so bear with me here and please don't be too harsh :oops:
    I am no expert, so let me see if I understand what you are saying, in order for me to run tests based on your assistance.
    "EKRN" is using (runtime packers, adv. heuristics & self-extracting arch.) doing the following:
    -checking the d/l file
    -checking the existing files on the HD
    If we turn off these, then the possibility is that the "freezing" (for the choice of a better word) will not occur?
    If that is my understanding, I will try turning off each one individually to dechipher which one(s) has the most adverse effect of having high CPU useage.
    I will add to this thread as soon as I have more information after the test.
    Thanks
    Cheers :)
     
  7. IcePanther

    IcePanther Registered Member

    Joined:
    May 28, 2005
    Posts:
    308
    Location:
    (nearby) Paris, France
    Ekrn.exe does scan the HTTP traffic (http/web protection) and the file once it's fully downloaded on the desktop (real-time protection). When it does this, if you have activated one of the options Marcos listed above, the ekrn.exe process (ESS's engine) will decompress and analyse all the contents of the archives/installers/etc. you may just have downloaded, and, as doing so, may temporarily take over all the CPU resources while scanning all elements at once, especially on big/complex archives (like installation packages).

    So, it you de-activate these, it's very likely to make the freezes disappear. But, as Marcos said, these enable a far better malware detection, and it may be a bit risky to de-activate (one of) them.
     
  8. fredra

    fredra Registered Member

    Joined:
    Jul 25, 2004
    Posts:
    366
    Hi Icepanther
    I think (operative word :D ) I understand what both you and Marcos are saying.
    However, if I use the baseline of 2.7.xx, the previous version with IMON does the same function, but IMON does not "freeze" the display of the web page. It does check the d/l, before the file is deposited on the HD.
    But in the previous version there was never any indication of high CPU useage, now in ESS it is happening. :ouch:
    So a lot has changed, agreed, but is it for the better? o_O
    Cheers :)
     
  9. fredra

    fredra Registered Member

    Joined:
    Jul 25, 2004
    Posts:
    366
    Hi
    I spent the past few hours testing, based on Marcos's & Icepanther's valuable input.
    In my case the freeze happens on the initial loading of any application that uses Sun Java 1.6.0. ESS seems to be checking "Java" (CPU goes to 99%) ..... then when "Java" loads, the CPU useage drops to normal and all IE7 functions returns to the usual state, and the original application loads.
    On all subsequent loading of any of the applications, there does not appear to be any adverse effect (freezing).
    Thanks to everyone who contributed.
    Cheers :)
     
  10. veri

    veri Registered Member

    Joined:
    Aug 3, 2006
    Posts:
    138
    I just emailed them about this, except in my case, it doesn't even take a large download: just a few megs worth of some installer or another will cause a long, long program freeze while ESS does its thing.

    Neither 2.7 nor any other AV I've ever used (with all heuristics/unpacking options set to the hilt) showed this behavior.
     
Thread Status:
Not open for further replies.