How I fixed my 100% CPU after upgrade problem (.657)

OK when I upgraded 100+ systems to .657 a couple months ago, 5 systems exhibited the "100% CPU/Impossible to use computer unless ekern is disabled" problem.

The systems had very little in common other than they were all running XP.

I booted in safe mode, and ran the uninstall via the start-->eset menu (it works in safe mode even though the Windows installer is off, Add/Remove won't work).

Go into C:\Docs & settings\all users\application data and delete the eset folder.

Go into Program Files and delete the Eset folder.

Use a good registry tool (I like "Reg Organizer") to search and destroy Eset and NOD32 entries (won't be many).

I then used Reg Organizer's auto repair, which mostly just finds dead links (missing files, folders, keys) and deletes the registry entries. Lots of similar utils out there to choose from.

Rebooted, reinstalled .657

They've ran like a dream since.

This also solved other strange problems I had been hearing about a couple of these systems (ie: intermittent long logins).

Hope this helps.

 

Couldn't it be that you had options like advanced heuristics and runtime packers enabled on access before and, after reinstallation, you've kept them disabled as they are by default?

 

Nope, because they were installed with a preset cfg.xml that I use for all of my clients.

They were installed and reinstalled using the same install file and same cfg.xml, hosted on the server and controlled by Windows' managed software group policies.

What I'm saying is that it's not NOD per se, but more so messed up registries and NOD32 is just showing the flaws. It's not nessicarily reacting well, but still I wouldn't say it's NOD's "fault" in the slightest, it's the messy registries.

Since it helped me also get rid of other nagging oddities on those systems, it actually helped me to have NOD puke.

 

I just had a server last night where I had to uninstall EAV 3.0 and clean out files because of messed up settings and I think you might both be right.

The XML-file that i use to install EAV with had Advanced Heuristics disabled but when I went into setup on the server it was still enabled and it didn't help to reapply the configuration on this server (the other servers were fine).

My point is that you may have some of the clients not picking up the settings correctly. Did you really check that Advanced Heuristics was disabled on the clients where you had the problem or did you just assume it as they were installed using the same XML-file?

My server even started complaining about a defect Firewall configuration when I enered setup (and it was EAV and not ESS) so I uninstalled/rebooted/delete files and ran setup again and now the settings are correct again.

/Preben

 

Marcos I found something interesting last night. and have been able to repeat it it seems the 657 on 3 computers of mine spike a 100% and hold there when Microsoft SYSTEM restore is activated and it try's to do ANYTHING with those files eg. like a Restore point is created, modified or Accessed. I shut system restore off on 2 of those computers this morning and so far the computers are running with no problems.. I'm wondering if maybe the 100% has something to do with restore files. also I noticed if you LEAVE the files on your computer it can mess with the on demand scanner. So I deleted them on both and so far Eset is running very fast on those 2. need more people to test this. as I have a limited number of computers to mess with and I wont test my client base as there not my Ginny pigs

 

XP SP3 Nod32 3.0.667. I just created a restore point. Took less than 15 seconds, and CPU never went over ~15%.

I've created several in the last few weeks as I'm installing new software (Office 2007, new VMWare, etc) and never noticed any issues with that.

NOD32 will scan into your system restore point. I see viruses in the scan logs show up in there, such things as VNC. I turned advanced heuristics back on and didn't see any difference with it on or off. Perhaps you have something in system restore that Nod is not liking? A corrupt archive?

Something odd I've justed noticed one one of "my" PC's is that Windows security center is telling me my NIS2006 is out of date when I log in even though I run Nod32. I had NIS2006 as it came on the OEM image, but after the 60 day trial I removed it. The installer is in the OEM partition, but there are no drivers or services listed in manage my computer. Usually I walk away from the PC after I login, so I don't see the balloon.

 

Try to install 3.0.667 and tell us if the 100% CPU usage continue.

 

Mac has stated that It would have no effect becuse all that was in the 667 was a few network updates. no client side updates

 

The only 'assumption' I had to make was that using the exact same installer from the exact same install source with the exact same XML file used for both installs would result in the same install and configuration.

Uninstalling, cleaning the App Data and Program files (etc) of ESET folders, searching and destroying just NOD32 and ESET from the registry and reinstalling didn't fix it; but a complete registry cleanup in-between the next set of (un)installs fixed it.

So I think, at least in the case of the 5 computers I dealt with, it was something else wrong in the registry and NOD32 was just reacting badly to it.

BTW my XML file is a custom Workstation config that was hammered out over time by myself with some help from Eset, the manuals and time spent determining Exclusions.

I have a Server one I use as well that works on all types of servers I've thrown it at, including domain controllers, both 2K and 2K3, including SBS2003. Haven't tested it against an Exchange server yet, but I'm confident it'll work, as it already has the suggested exclusions included.

So I'm pretty confident my configuration files are not what was causing problems on 5 out of 100+ systems that all use the same set.