AutoStartup Scans causes 25% cpu and memory creep

I have a machine that is now experiencing what others here have, where ESET startup scan will run with 25% cpu load, and the memory will creep up from 50k, to max memory over a period of time. Memory usage ramps up about 200bytes per second.

I disabled and then removed the "auto startup scan when machine starts up" scheduled job from ESET. Restarted machine, and EKRN.exe process is once again running 25%. After about 3 minutes of a user logging in, the memory usage is nearing 600megs of a 2gig ram machine. And, according to ESET main screen, it is scanning files.

Watching it this time, it does not seem to be going over 600megs.

I have now disabled the "auto startup scan upon virus definition update" scheduled scan. Will reboot and see how that fares.


After a restart, and not having any startup scans in the scheduler, the computer started scanning files again. CPU usage of EKRN.exe process at 25-30%. Memory at 730meg. Can see on ESET status page that files are being scanned slowly.

Memory usage seems to be holding firm around 730meg this time.

But why? Why so much cpu usage when the initial installation scan of files does not even use more than 5% cpu cycles?

Why is there a startup scan when nothing is scheduled to occur at startup?

Set scheduled scan of files occurs at 6pm. this is occurring at noon. Running Eset Endpoint v5.02. I am domain admin and enterprise admin, and users are local admins.

 

The known memory leaks are caused by certain 3rd party drivers, a workaround for this will be incorporated in v6. If you experience memory leaks, a fix can be provided on demand.

 

would this memory leak also be associated with WinVNC.exe?
And WBEMLog(s) ?

I found, using VNC to remote in to two machines this is happening on, that the startup scan seemed to be stuck on two files. WinVNC.exe and a WBEMCore.log file. This also caused the memory usage to skyrocket to 1.2gig.

I placed the c:\program files\UltraVNC\*.* and c:\Windows\System32\WBEM\Logs\*.* in to my Scan Exclusion path for each machine.

After I did that, the CPU cycles went to 0% and the scan went on to other files. However, the memory stayed way up.

After a restart, cpu went back to 25-30% with memory hovering around 720meg. I have screen caps of this if you want them. And I am also downloading their 800meg dump files. (wth? and those are the small ones).

Also, why are scans are being run when the autostart scan is turned off? With CPU usage @30% for all cores?

 

Please see the attached screen caps. Notice the 25% cpu usage and the memory of 1.35gig (varying up and down around that).

There is no scanning going on now. This was noticed before I utilized VNC to remote in. Scan shows 100% of files scanned. (vnc is always running as a service however).

 

You wrote "Running Eset Endpoint v5.02", however, such version of Endpoint does not exist. Did you mean v. 5.0.2126 or an older one?

 

Yes, that is our version. I was being brief.
Or, to be more specific,
v. 5.0.2126.0 with hourly definition updates currently 7474

 

Hi Marcos,

I am also having this issue. Using 5.0.2126 and whenever Notebook started, it freeze. Need to wait for about 1.5 min or 2 (3 incidents) and get back to normal.

Will your patch resolve this? Is it possible for eset to push in next daily updates?
If not, appreciate if you can share me a patch to test on one notebook..

Thanks

 

This is really weird as this (latest) version of Endpoint has a workaround for problematic 3d party drivers causing memory leaks already incorporated. Please carry on as follows:
1, download ProcDump and extract it to the disk
2, when you notice a memory leak by ekrn, run the command "procdump -ma ekrn.exe"
3, compress the dump, upload it to a safe location and PM me the download link. If necessary, I can provide you with access to our ftp server.

 

Hello,
please configure Windows to generate kernel dumps as per the instructions here.
When the system appears to be frozen, hold Ctrl and press ScrollLock twice as mentioned in the KB article to trigger BSOD during which a kernel dump will be generated. When done, compress it, upload it to a safe location (I can grant you access to our ftp server) and PM me the download link. I'd suggest creating a separate thread as it's most likely a different issue.

 

Thank you Marcos. Will do.

 

The program begins, creates a *.dmp file, begins to write the file... but then ends. The file then disappears.

 

I sent you a pm.

Thanks

 

EKRN.exe will remain fairly stable for a bit. Then it will slowly creep up using more cpu and memory resources, until a point when the program or memory causes a windows error. Then, ekrn will go back down to @0%cpu and memory around 550-750 megs where it will remain until a reboot or memory begins to creep again.

Right now, after the last screen cap and error popup, memory is holding steady at 652,412 megs.

 

Any updates?

 

None yet. I am still working with marcos to gather log files to assist with a determination.

 

Hello Marcos,
Any word from the engineers?

 

Any updates or patches? It has been more than a month now.

 

It seems that ESET support cannot handle customers' response properly. I have been working as a system integrator and helping eset endpoint to customers. Reported issues in field and helping them to resolve but no proper info passed back to us and keeping mum. I have decided to start selling McAfee Endpoint in parallel with eset in some area and will compare the support levels.

They didn't even make our field support level to be satisfied. Regretted for this behavior and learn lessons!

 

It's Captainfish's turn to let us know if the the latest version of the SysInspector module provided 5 days ago resolved his issue. The module is already available for all users.

 

Apologies, but our customers could not wait any longer so we re-imaged the machines. The image that was used contained the ESET installed already.

After a week of monitoring, the machines are operating like normal and have not experienced any further issues.

This was done before I found the message about the SysInspector modules being updated. Though, our users were tired of being the test guinea pigs and just wanted their machines back so they could do some work.

Anyways, regards and many thanks for everyone's support.
Thanks Marcos for trying to assist.