ekrn.exe CPU utilization - a discovery

I'll preface this with the statement that I'm certain there are multiple causes for all the high ekrn.exe CPU issues people have encountered. But I also believe that what I've discovered may be at least part of the cause for some of the issues.

My problem was high ekrn.exe CPU when logging into any userid on any of my computers. Utilization was high throughout the login process.

To troubleshoot the problem, I used SysInternals 'procmon' to monitor what ekrn.exe was doing during the login. I found that it was repeatedly reading a 6+ MB file in its entirety. The file turned out to be the log file for ProcessGuard (yes, I know it's obsolete, but it plays a role in the multi-layer security approach I use). ProcessGuard appended information to the log file every time it allowed a program to run or blocked a program from running. Every time it appended info to the log, ekrn.exe read the entire 6+ MB file. There are a LOT of apps that start during login, so ekrn.exe was VERY busy reading this large file over and over in its entirety.

I excluded TXT extensions from real time scanning and logins went much faster!

I've also observed the same ekrn.exe behavior (read a file in its entirety) for .ini and .log files - so I've excluded these extensions as well.

The bottom line is that 'procmon' can be a valuable tool to see what is going on when ekrn.exe is burning a lot of CPU. The specific cause(s) for your problems will likely be different, depending on the software you've installed, but 'procmon' may give you insight into what is going on and provide clues about how to mitigate it.

I'd also be curious to see what, if any, comments the ESET developers would have with respect to the necessity of reading .txt, .log, .ini, etc files as a part of real time threat scanning - especially when there are situations where this can cause significant CPU consumption and performance impact when they are large and/or read repeatedly.

 

I can have PC at idle after running for hours.

I then right click Task Bar to bring up the Task-Manager, my CPU Cores will hit 100% and stay there for 30+seconds and that's how long it takes the Task-Manager to appear.

Funny builds up to and inc .650 do not cause this, only the later buggy builds.

 

Just to make sure, do you use default settings (ie. advanced heuristics and runtime packers are disabled on file access)? It'd be interesting to know if it makes a difference if you export the settings, install 3.0.650 and import the settings.

A complete memory dump (or at least a dump from ekrn.exe) would shed more details. Would it be possible for you to create one? A zipped complete memory dump will be several hundreds MB in size, depending on the amount of installed RAM.

 

Yes, posted about 100X (slight exaggeration) all settings default (in many other threads).

Up to and inc .650 works all newer builds are a joke, bring fixes for Mail but break other aspects.

Opening any folder can cause it, I'm just pointing out to the OP its not just to do with logging into Windows.

I have many times rolled back to .650 with same settings I have had since day 1, I do not really want to manually set up the Firewall again so that's good.

I cant do anything now as back on .650 and will be staying on it.

I'm 100% done with messing about, I'm on .650 and when my Subscription is over I'm off this POS.

 

Soory Marcos but am I misunderstanding you? These appear to be ON by default v669.

FWIW I have fewer issues with high CPU Time since I removed all other spyware catchers

Edit. I think I see what you mean now is it the Additional Threat Sense Parameters that should contain advanced heuristics and runtime packers?

 

There are currently 2 places in the real-time protection setup where you can enable advanced heuristics (AH) and runtime packers (RTP).

By default, these options are enabled for newly created and modified files only. This is because code emulation is a time consuming and performance intensive operation. However, it should suffice when installed on a clean computer as any new potential malware that is written to the disk would be scanned with maximum settings.

V3 has introduced a new option that enables the use of AH/RTP on file access. With normal files that are not protected against emulation, you should not notice a significant difference in speed even with these options enabled. However, files that are protected somehow (usually malware, but also some commercial applications use various protectors) may take time for advanced heuristics to emulate their code. If you frequently use such files, it's recommended to keep AH/RTP disabled on file access.

 

I don't have the high CPU issue per say but I have noticed my drives thrashing at startup. I turned off indexing on the HDs and disabled the service so I know that is not it and then I used PROCMON to see what was going on as well as PROCEXP...I have a 20MB XML file showing ESS scanning alot of files at startup and many of them time and time again with buffer overflows. Now I could understand things on C: however some are on D: that are not called at startup unless it is because I have an Icon in my quicklaunch tray for that application (like procmon and procexp). I see several of the items in the c:\windows\installers directory that concern me.

a few examples....

<event>
<ProcessIndex>7</ProcessIndex>
<Sequence>88489</Sequence>
<Time_of_Day>1:15:56.9210508 AM</Time_of_Day>
<Process_Name>ekrn.exe</Process_Name>
<PID>2276</PID>
<Operation>QueryAllInformationFile</Operation>
<Path>C:\Windows\Installer\175b43.msp</Path>
<Result>BUFFER OVERFLOW</Result>
<Detail>CreationTime: 4/18/2008 2:56:18 PM, LastAccessTime: 7/21/2008 3:58:04 PM, LastWriteTime: 4/18/2008 2:56:18 PM, ChangeTime: 7/28/2008 12:16:39 AM, FileAttributes: RA, AllocationSize: 6,217,728, EndOfFile: 6,215,680, NumberOfLinks: 1, DeletePending: False, Directory: False, IndexNumber: 0x50000000160d7, EaSize: 0, Access: Generic Read, Position: 0, Mode: Synchronous IO Non-Alert, AlignmentRequirement: Word</Detail>
</event>

<event>
<ProcessIndex>7</ProcessIndex>
<Sequence>88490</Sequence>
<Time_of_Day>1:15:56.9210682 AM</Time_of_Day>
<Process_Name>ekrn.exe</Process_Name>
<PID>2276</PID>
<Operation>ReadFile</Operation>
<Path>C:\Windows\Installer\175b43.msp</Path>
<Result>SUCCESS</Result>
<Detail>Offset: 0, Length: 511, Priority: Normal</Detail>
</event>



I am running with EVERYTHING ESS has to offer and I have the logon scan disabled in the scheduler. It takes about 2 minutes for the thrashing to stop and my PC is very usable during this time. This seems to have started around the 650 timeframe but that was also when I was playing around with HSF's and overclocking my rig ... been a while but now I am back on other things...