Jump to content

zeromido

Members
  • Content Count

    5
  • Joined

  • Last visited

Everything posted by zeromido

  1. It depends on how ESET is programmed to update the counts. The way I see it, counting logs should be done like this: 1. Counts should be saved somewhere. Maybe in a file or a registry key. 2. When an event is finished, ESET would increment the log count of that event type by one. 3. Every time a user clicks the Log drop-down menu, saved counts are reloaded. FYI, Windows Explorer monitors context-menu registry keys in real-time and any changes are applied immediately. But of course if the change causes unacceptable delays or any other unexpected problems, then it would cause
  2. Description: Show number of events in Log drop-down menu Detail: In Tools > More tools > Log files, the number of recorded events is shown for the selected log type only. I think it would be useful if it was shown for all items in the drop-down menu without being selected. I'm not good with words so I edited a screenshot with MSPaint to make my point clear. You can find it in the attachments.
  3. Description: Prevent scheduled actions Detail: Prevent any scheduled actions that might interrupt a scan or any security related operation. For example, scheduled shutdowns, restarts, sleeps, log offs, hibernates, etc. I think this can be done using an option in settings. Maybe somebody got a better idea to do this?
  4. Sorry, I can't believe I forgot to mention that. The spike takes about five minutes but it was reduced when I deleted Path and PATHEXT. And unfortunately, my connection speed is slower than you can imagine. Uploading anything as much as 10 MB would take forever, let alone uploading a Procmon log (100+ MB) and a full dump of ekrn (300+ MB). Are there no other ways to figure out the problem?
  5. System Information: Product: ESET Internet Security, Version 12.0.31.0 OS: Windows 7 Ultimate (32-bit) CPU: Pentium(R) Dual-Core CPU E5700 @ 3.00GHz Memory: 2.00 GB RAM Description: Whenever EIS finds a threat 1 on the hard drive 2, ekrn.exe uses a constant amount of about 50% of CPU. Running an in-depth computer scan for a couple of minutes doesn't use a constant amount, but rather a variable one that almost never reaches 49%. Process Explorer showed that the ekrn.exe thread that caused the spike is at address NODIoctl+0x19910. NODIoctl is a function exported from multiple EIS mo
×
×
  • Create New...