high cpu use since trial extended

hi, i was trying nod 32 v3 (not eset suite) after restarting pc after yesterdays update which extended license till end of nov. my cpu use is 50/51% continuosly, task manager says eset service is the cause? didnt have this problem before, any ideas?
vista ultimate
amd 6400x2, 2 gb 6400 ram, vista firewall and defender running.

 

yeah this is a problem which seems to have creeped back into NOD AV and im a bit pissed off with eset.

When i originaly downloaded the NOD32 V3 Trial at the beinning of september (cant remember what the AV module number was) I would get this on every boot that cpu would sit at 50%. Fast forward to middle of october when the av module was 1098. I tested this thoroughly and rebooted the laptop 30 times, some from cold start others from warm boot and NOD32 v3 would work/boot fine and cpu load was 2%

Now whichever muppet at eset development developed AV module 1099 it has reintroduced this bug. IM very annoyed because when this first happened back in sept i didnt realise what had happened and my laptop battery had drained within an hour where usually it would last for 5 hours. All because the cpu was sat on 50%. The fact eset quality control has lapsed and allowed this to be reintroduced has given me little confidence that come monday when i download the final, i will find the same problem. I guess eset just doesnt care about its customers or producing quality software. I havnt got the time and i shouldnt have to need to check task manager on every boot just to make sure that the cpu isnt throttling. I have even tried formatting the laptop and reinstalling v3 and i still get the same problem sigh The offending culprit in task manager is ekrn.exe Is there any possibility that the av module can be rolled back to 1098 ?

 

Ive attached settings exported from NOD32 V3

 

i couldnt figure out a fix, have gone back to 2.7, which works, as always on pretty much no resources. to be honest i found v3 only slightly more hungry than 2.7 from the start, is this the gui? if so i think i will stay with 2.7. i love it's leaness. don't take that away please eset.

 

Actually we have not been reported this issue from anyone else so it shouldn't be a general problem of the firewall module. I will ask our developers if they can think of a reason that could cause this issue.

 

mine was just the av beta software (not suite) with vista firewall, defender and spyware blaster on vista ultimate if that helps any. was fine before yesterdays update, tried re-instals i guessed it may be vista as vista seems incompatible with most things!

 

Hi Marcos

The issue was not only reported by myself to eset beta development but it has also been brought up on the forums at least twice

https://www.wilderssecurity.com/showthread.php?t=189313

https://www.wilderssecurity.com/showthread.php?t=186869

I know for certain its due to module 1099 because with 1089 i rebooted between 30 to 40 times on my laptop as i was amazed the problem had been fixed or at least seemed to have been fixed. Previously when i downloaded in september (cant remember what the AV module was) i would get this 50% cpu usage on every boot which would cause the laptop battery to drain rapidly. With module 1099 its so far happening once every 5 reboots on average. This is a serious problem especially for laptop users, who unless they check task manager on every boot, could get caught out on this like i did. I dont believe its an isolated problem either judging by the 2 threads i have linked to. As stratoc points out this is the NOD32 AV RC1 not the ESS suite. I dont know if this happens with ESS suite as i didnt trial that product. The difference i have noticed between last week when hings were ok and the recent update is the splash screen takes slightly longer to appear and the system seems sluggish at startup. This was not happening prior to the updates. Out of interest what did change in module 1099 anyway ??

Regards

 

Well after downloading the new release version of NOD32 3.0 it appears as though this problem has been fixed in the final. It may have been a problem in the release candidate with the new module. So far spent an hour or so doing 10 reboots and not been able to duplicate the issue.