Caught (and logged) ekrn.exe mass-Reading local.db, w/ slowdown/freeze

TL;DR I captured ekrn.exe hogging my system resources using Process Monitor. It appears ekrn.exe is performing a huge amount of Reads on local.db once a month which causes slowdowns and freezing. Can this info help ESET find out what this monthly system-hogging-ritual in version 5 is about? And possibly fix it? These two questions go for mass-Read operations on local.db in general too (not just the monthly ones).​

Hi,

I'm having the same issue that is described in this thread:
(1) https://www.wilderssecurity.com/showthread.php?t=312305

This happens to me once a month since I installed NOD32 version 5. What happens is that 10 minutes after my laptop has booted, ekrn.exe starts hogging my CPU which can significantly slow down my system. It can be so bad that my whole system freezes and I have to shut down the laptop by holding the power button. When I boot it up again, the same thing happens after 10 minutes and it keeps doing this until I let ekrn.exe finish its business (whatever that is).
Also ekrn.exe's memory usage goes up to 480000+ k in taskmanager. The pic I attached is from last month's event. It shows ekrn.exe using 379000+ k memory (its usage went further up in the 400000+ k in that session, can't remember exactly how much).
This is the third time that this has happened. The first time was in mid-October, the second time was 17-11-2011 and the most recent event was on 18-12-2011. Interesting point: note the date when this problem was reported in the above thread (1).
So I decided to log the latest event with Process Monitor (SysInternals).
What I see in my log file is that ekrn.exe performs a huge amount of Reads on my local.db in a period of ~12 minutes. When it's done, it performs a series of Writes which it completes in ~15 seconds followed by a small series of Reads. And then my system is free again. The total amount of Reads was 223440 and 41528 Writes on local.db during a period of 752 seconds (see pic).

Now, I've searched the forum for other people who have problems with local.db and I've found these two threads:
(2) https://www.wilderssecurity.com/showthread.php?t=309539
(3) https://www.wilderssecurity.com/showthread.php?t=307889 (there's a mention of local.db file reads on page 2)

Incidentally, I've experienced the issue described in thread (2): my local.db file has grown in size and is continuing to do so. It is now 91+ Mb.
To make matters even more complicated, up until two days ago I had the issue that 10 minutes after every boot, I got a period of constant disk activity. It lasted about 2 minutes in which 68488 Reads (no Writes) were performed on local.db, causing slowdown. I was going to make a thread similar to this one about it until I noticed my NOD32 version was v 5.0.93.0 so I updated it for formality's sake, but the problem did not occur again. So this issue is gone, but my point is that there seems to be a pattern with slowdowns where ekrn.exe is mass-reading local.db.

After reading thread (2) I'm thinking that toggling the "Enable Self Defense" option off and back on could probably fix the file size issue and might also fix the main issue I've described here. But I wanted to wait and bring this to ESET to see if they can use the information so they can track down and fix the problem entirely?
I'm willing to wait with any fixes and offer myself to get more diagnostic information, but do note that the next time that this issue may occur - if it does - is probably next month (19-01-2012?).

Specs:
1.3 GHz Centrino
2 Gb RAM
120 Gb HDD (~10 Gb free)
WinXP Pro SP3
ESET NOD32 v 5.0.94.0

Sorry for the long-winded post. Hope it made sense.

 

Reading / writing to local.db does not cause any slowdowns. Quite the contrary, this is done in order to speed up the scanning and overall performance. If you experience slow down and disabling real-time protection actually makes a difference, upload the Procmon log somewhere and PM me the download link so that I can have a look at it. You can also try disabling HIPS in case there was a problem with 3rd party software. When you notice a huge memory consumption by ekrn, use ProcDump to generate a complete dump of ekrn.exe by running "procdump -ma ekrn". Once generated, upload it and PM me the download link.

Besides the log and dump, supply us with local.db as well. Also check if disabling startup scan tasks in Scheduler makes the issue go away.

 

Thanks for your reply.
Well the thing is, NOD32 only does this once a month. Therefore it's hard to figure out if it's indeed NOD32's real-time protection that causes this.
I think I'll try pushing my system clock one month forward to see if ekrn.exe slows down again. And if it does, I'll see if turning off real-time protection/HIPS/Enable Self Defense makes a difference. Otherwise I have to wait one month before I can report back
I took another look at the procmon log, this time I've also enabled registry/network/process activity, and profiling events and the entire log is dominated by ekrn.exe. In addition to what I've said in the post above, I see that ekrn.exe is intermittently performing some registry operations on the keys inside

Code:

HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Plugins\01000101\Profiles\@My profile

Other than that, there is some process activity (ZCfgSvc.exe etc.) scattered across the log in small patches and there is an intermittent Process profiling.

I've checked my windows scheduler and NOD32's scheduler but I couldn't find any tasks that would fit the monthly pattern I've described here. (I was thinking maybe windows was doing some other monthly task which triggered NOD32 to scan its operation, causing the problems, but nope)

I can upload my log file and local.db and send you the link, no problems there, but I haven't met this condition in your post:

But I can PM you the link right now if you want to take a look in advance. I'm in the process of uploading my local.db which takes quite some time.

Thanks for the link to procdump. I've made a .bat file that executes that code for convenience. It'll come in handy if my entire system has slowed down so much that I can barely do anything.
I'll try adjusting my system clock and move on from there...

<procmon log and local.db sent via PM>

Update: I set my system's calendar to 19, 20 and 18 January 2012, each time doing a cold reboot after changing the calendar. No results. I'll keep it on the 18th now and follow it for 24 hours to see if I get anything. I haven't changed any NOD32 settings so far btw

 

Just a minor update: changing my system's clock had no effect. I guess the next time I get to do some logging will be next month.