100% CPU Usage

AH and RTP, in my honest opion, have nothing do with anything. I do have AH and RTP checked in version 3.0.669.0 (I went back to this version). But when I first upgraded to the latest version, I also had the same options checked as I had with version 3.0.669.0.
How can NOD32 latest version use 100% of my CPU and the previous version didn't?

I truly don't know what the heck is going on. Eset doesn't either, otherwise a fix would have come out already. What I do know is that when I upgraded to the latest version and the CPU usage went to 100%, I deactivated nod32's active protection and then reactivated it and CPU usage went back to normality.
Could the problem be related to when the system is turned on, and rebooted as well, and somehow nod32 (ekrn.exe) keeps increasing the CPU usage without going back to normal? Once again, no idea of what so ever.

But as I mentioned before, perhaps Eset should try to reproduce the problem using machines with the same configuration as the costumers having such problems, and try to figure what what is causing such CPU usage?

And taking in consideration the car analogy, if you had bought a car that wasted all gasoline in just 1 second, wouldn't something be wrong with that car? Wouldn't the manufacturer have to find out what was causing such tremendous consume of gasoline? Or is the car driver that has to find out by him self?

 

ESET Antivirus v3 is purely and technically a different program from NOD32 v2

A fix is definitely being prepared . By saying "fix" , you shouldn't understand a direct fix to fix something 100% proved problematic because this is not reproducable on the machines of all clients . Additionally , I personally think that most (if not all , but let's say most - sounds better) of those who complain have somehow touched somewhere they shouldn't have.

Hopefully the upcoming releases will work better for some of you .

 

When I mentioned previous version, I mean version 3.0.669.0. The one I am currently using (again), after I uninstalled the latest version of version 3.0.

Here I can say with 100% certainty that I haven't touched anything before I installed the latest version of NOD32 3.0. The only thing I did was to uninstall version 3.0.669.0 as recomended.

[/QUOTE]

They shouldn't work better just for some. Any upcoming version should work better for all Eset NOD32 costumers (of course there will always exist this or that one issue, but nothing that shouldn't be quickly solved).

Note: To everyone having the 100% CPU usage try to deactive NOD32's active protection and reactivate it and see if the CPU problem still stands. If it stops, then the problem is related to when the system starts.

Best regards

 

No, there is no evidence that a fix is being prepared. Marcos is asking the same questions he has been asking users for months, implying Eset are nowhere near a fix. If Eset want to prove otherwise then that's fine by me - of course they can only do this by releasing a real fix (i.e., one that works).

That is very disrespectful of you, and I for one resent your remark. You can't blame users just because they encounter a problem with a product. I can personally attest to this problem arising on systems using NOD32 v3's default settings, simply by installing the product. I can reproduce it at will. In the cases I encounter - there have been many, but my experiences are not exclusive - just install NOD32 v3 on a machine on which certain large files are written to frequently during startup. That's just about standard on a domain-attached workstation, where log files are added to during startup. Over time, these files can grow reasonably large - once they reach about 40MB (yes, I know, that's not exactly large) they start to cause NOD32 v3 to barf).

NOD32 v3 seems particularly bad at scanning frequently-updated .log files, causing 100% CPU usage for minutes on end. Actually, NOD32 v2 bad with these files too, but not nearly to the same extent as v3. In our case (and that of our clients), excluding .log files works around the issue. It works, as I say, but it is not a solution.

I suspect the same issue is the cause of other people's problems, maybe with different file types or with specific files. But then, it is Eset who need to solve this.

 

THANK YOU!!!!!!!!!!! FINALY SUMONE WHO SEES HOW MARCOS IS SO REPITITIVE.....FINALLY....ive be trying but u nail ma point.........

geez they make seem like other anti virus do da same thing and like its da active protection we pay for thats the problem. Its a waste a money if u ask me. Marcos its better if u just ADMIT IT and STOP ASKING DA SAME THINGS.....i mean you don't get enough INFO?? geez

 

I've made a test when a text file was continually being filled with data (about 3 MB/s on average). During this process, the file was scanned about 300,000 times by the real-time protection module and the cpu utilization had never exceeded 5-6%. I'll carry on trying various versions to see if it makes a difference.

 

I recently fixed my 100% cpu usage problem quite simply, I think nod32 is taking more work than it can handle. This is an old PC (P4 HT) but still 3.4Ghz. I wondered why every time I froze my shortcut icons on the dekstop went blank, it seemed to be related to a minimize/maximize of an application that refreshed teh desktop, which causes eset not only to scan the shortcuts, but the file in the DIR AND the ENTIRE DIR. This can easily kill any pc for several minutes assuming you have many shortcuts, and can also explain startup lag.

My vista laptop never suffered from this problem probably because it hardly has any desktop shortcuts.

 

The issue that bugs me is that after a year of running version 3 at the same settings why does the software give issues now. All of a sudden we must lower the settings when all along it has run fine.

 

I must ask again since you haven't provided any details - do you use default settings, ie. advanced heuristics and runtime packers are disabled on access?

 

Hi Marcos I have always had heuristics set to high, and detect potentially dangerous apps selected, and potentially unsafe apps selected where available in options. Runtime packers I left default. Logs I left at default. I have removed Eset from my computers recently, but I still have user licenses good for a couple of months and I have a couple systems I want to try Eset on again so I will give them a shot and see how things go.

 

We never recommend leaving advanced heuristics enabled on file access. Code emulation is a time consuming operation and it may take up to several seconds to scan certain runtime packed files.

 

Thanks Marcos then I will leave that setting to default in the future. I have had it set to high though for a long time and never had an issue before and my cpu at idle is always only at 0-2% then all of a sudden it shot up on my laptop to 100% which runs Vista. Then within a day or two later my desktop computer which runs WinXP also went to 100% cpu from ekrn.exe all of a sudden after a long time running this way too. I never had this issue before and then it just showed up on two totally different setups at nearly the same time so at the time my best guess was that an update caused this. Anyway I will turn advanced heuristics on file access to default in the future and see how things go. Thanks

 

Remember that advanced heuristics (AH) is continually being updated so the scan time may vary with different modules of AH.

 

Marcos, I'm not sure if you read any of my previous posts, but when I installed NOD32 v3.0.672 the CPU usage went to 100%. But the 100% CPU usage only started to happen when I rebooted the system. I deactivated its active protection and reactivated it again, there was no high CPU usage.
Could it be related to this?

Also, can anyone else try the same thing and say if it worked or not? We must find a common point, otherwise everyone will be asking: do you have this, do you have that. No one will get nowhere.

By the way, everyone using version 3.0 or that was using any previous version, did this issue (cpu usage) started to happen after upgrading/installing a new version or you have used more versions before and it started to happen just now?

I ask this, because I was wondering if all this issue was due to the fact that we have to uninstall any previous version installed (not a must, but recommended) and for some reason any files/drivers/services left behind conflict with the new installation?
I'll try it out, but I was just wondering...

 

What ESET should do is have a group of us be the testers. Make all of us install version 3(latest) with out any updates. Have us use the our pc like regular, open some files that claim to cause the high cpu and make us monitor it(or software da writes logs). After 1hr, make us all update to the latest definitions then do da test again. Make sure all of us have different machines and different things running. Also make sure at least 2-3 of US have the same thing doin or running on the same machine configuration.

I think this would greatly help you find the cause. Its an idea. Its a start.

 

Marcos,
This thread spans from April to October of 2008. I came into it later than some, but it is all confusing to me. I can troubleshoot computers enough to get things working, but I feel like I am approaching it with a rubber band and chewing gum approach. I spent all of yesterday slowly wading through the 12 pages of opinions, trial and error and theories about what to do with excess cpu usage.
I have sold NOD32 to quite a few people and thankfully, I have only had one person with the problems noted here. However, I hesitate to sell it to more until the issue is resolved or at least defined so that we can control it. I am on the verge of some big accounts on my list and right now I am waiting to see whether I will be creating a huge problem for myself by selling to them. You know that one bad experience produces a bad reputation. One bad car can brand the rest as lemons and that is not what I want to see happen to ESET.
Marcos, is it possible for you to summarize the previous 12 pages into a concise troubleshooting and tactics list for us? That would be a tremendous help and it would be worth putting it as a sticky at the top of NOD32 so that others will not need to digest this volume of posts to find the unclear answers.
I look forward to the day (soon?) when we can just throw that list away because it works right. If there is a section of the software that does a more intensive search and destroy, it needs to be stated that way so that those needing heavy cleaning can employ those tools. For those who need less, that should be clearly stated and those people encouraged to not hunt mice with a shotgun.

I hope that we can get past this troublesome time soon and I can go ahead and offer people NOD32 with confidence again.

ForgeMaster

 

Frankly I'm getting a bit annoyed because I've been researching this for a while now and so far you've gave me either a less than helpful reply or completely ignored me.

 

if marcos was in jamaica he would a been shot already cause him cant give we a straight answer. Jah know star a pure joke thing

 

That's a great idea. Other idea would be for Eset to develop a tool that would collect info regarding eset nod32 antivirus activity and figure out what could be wrong. I think it could work out. Then again, its their call.

 

It is the same old story. You bought NOD, supposedly because of the detection rate. And if you are one of the ones that have 100% CPU problem you are told to turn off the protection you paid for. Not acceptable.

 

This statement is completely wrong, no one tells you to disable certain features. As long as you are using default settings, you shouldn't have problems with excessive cpu usage. It's like purchasing a new fast car. You cannot blame it for higher fuel consumption just because you drive much faster with it. No one tells you to drive so fast either, it's just because you intentionally do so and it is only your personal decision. Common people wouldn't drive so fast and thus the fuel consumption would be even lower than with their older car. Of course, the new car allows them to accelerate faster, but then they drive at an average speed (maybe the equivalent to advanced heuristics for newly created/modified files?

For those having issues with high cpu usage, please do the following:
1, make sure you use default settings (ie. advanced heuristics/runtime packers were not enabled on file access as this may cause several second delays when scanning certain runtime packed files)
2, try setting the real-time protection to scan files with default extensions (ie. files that may potentially carry malicious code) instead of all files
3, run Process Monitor from Microsoft to monitor the operations performed by ekrn. This will help you pinpoint the issue to a particular file that probably takes a long time to scan, or is updated so frequently that continual scanning causes the cpu to spike.

 

If advanced heuristics/ runtime packers are not to be used why are they there?

 

That's not the right comparison and you know that!
As a software representative you should be more fair. It's better to be told that you bought fast car but when you try to drive as fast then engine completely block...and this isn't driver's fault!

 

Damn , they are used - by default they are enabled - but for newly created files in real-time , in the web-access protection , in the email protection , for on-demand scans and for the kernel scannings . ONLY not in the real-time permanent on-access scan !

 

I most humbly apologize if I have upset anyone. It really doesn't bother me anymore. I no longer use NOD. I wish you all good luck.