ekrn.exe consume 40% CPU since 3 days

[Jesposito 1]

Dear support,

I am using EFSW 6.3.12010.0 on Windows 2008 R2.

ekrn.exe is consuming 40% of the CPU since 3 days on a server. I had the same problem with EES before I moved to EFSW.

Once a week ekrn.exe was consuming the CPU of all my servers, leading to big problems. That's why I do not install ESET product on production servers.

Help to find what is happening to correct this issue. AthenaGS support is turning me crazy since 1 year.

I think you would easily understand that I need to protect all my servers with an antivirus.

I do not understand why it is consuming this much CPU, like if it were running a task, but nothing is visible in the GUI.

The CPU is still consumed, contact me quick before it go back to 0%.

Best regards,

Jonathan ESPOSITO

Deputy IT manager

[Marcos 5,286]

Couldn't it be that an on-demand scan is running? If not, does temporarily disabling real-time protection make a difference?

[Jesposito 1]

Thank you Marcos for your fast reply.

There is no on-demand scan running.

If I turn off the real-time protection and the CPU go back to 0%, how will we find the root cause ?

[Marcos 5,286]

Please generate a Process Monitor log and let it log operations for at least one minute when the issue occurs. Also collect logs with ELC. For instructions, see the appropriate links in my signature.

When done, compress the Procmon log, upload it to a safe location (e.g. Dropbox, OneDrive, etc.) and pm me a download link. As for ELC logs, you should be able to attach the output archive directly to the message, if not too large.

[filips 44]

Hi Jonathan,

you could also try upgrading your EFSW to 6.4 and check if the issue persists

[Jesposito 1]

Thank you filips but I have this issue since I upgraded from v5 to v6. Something must be wrong with my OS 2008 R2.

It appear to run fine on 5 servers with 2012 R2 that we installed last November.

None of my 30 servers 2008 R2 are running fine.

I really doubt that the last version will fix it.

[Marcos 5,286]

We'll see what the logs will show. Maybe they will actually reveal an issue that was fixed in v6.4

[Jesposito 1]

This would make my day

[Jesposito 1]

My pc crashed (Win10) and after all the windows update the ekrn.exe on the server was back to 0% when I reconnected.

I had the time to capture the procmon log (1 minutes = 1Gb) during the issue.

The ekrn RAM went from 200Mb to 125Mb.

I will collect the ESET logs.

[Jesposito 1]

I found this in event log "System"

The ESET Service service terminated unexpectedly.  It has done this 1 time(s).  The following corrective action will be taken in 0 milliseconds: Restart the service.

That explain why the CPU is back to normal and the RAM drop.

[Jesposito 1]

Marcos,

This is the Eset log collected for the last 5 days.

I pm you with the procmon link.

efsw_logs.zip

[Jesposito 1]

We did not have to wait long.

Another server is using 100% CPU (~50% ekrn.exe).

@filips this is the last version EFSW 6.4.12004.0 also on Win2008R2

I am collecting the logs but it is hard to work with 100% CPU...

[Jesposito 1]

Both procmon logs and ESET log collector have been running while ekrn is about 50% CPU.

PML is not corrupt. I PM @Marcos

ESET log collector failed. I try again with realtime process priority on log collector.

[Jesposito 1]

It failed again :

[16:17:23] === Running processes (open handles and loaded DLLs) ===
[16:17:23] Exporting...
[16:22:23] ERROR: Failed to execute the 64bit process info dumper executable
[16:22:23]

[Jesposito 1]

Another server have ekrn.exe at 50%.

Same configuration : latest EFSW and Win2008R2

I am also collecting logs for this server.

[Jesposito 1]

Different error on ESET log collector for the 2nd server :

[16:37:21] === Network configuration ===
[16:37:21] Exporting...
[16:37:31] ERROR: Failed to execute IPCONFIG command

I am sorry but I can't provide you the Eset logs for this server.

I will try with the 3rd server.

[Jesposito 1]

Here is the ESET logs for the 3rd server.

@MarcosPML is on PM (3,7Gb unpacked)

efsw_logs3.zip

[Jesposito 1]

The 2nd server is still at 100% CPU.

This is the one where I can't collect the ESET logs.

Tell me if you want to do further analysis on this server before it crash.

[Jesposito 1]

ekrn.exe is opening the folder "C:\ProgramData\ESET\ESET File Security\Diagnostics" 10 time per seconde.

It is not doing such a thing on a fine running server. It read the disk punctually.

Quote

IRP_MJ_CLEANUP	C:\ProgramData\ESET\ESET File Security
IRP_MJ_CLOSE	C:\ProgramData\ESET\ESET File Security
IRP_MJ_CREATE	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_DIRECTORY_CONTROL	C:\ProgramData\ESET\ESET File Security\Diagnostics\eset_*.tis.log
IRP_MJ_CLEANUP	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_CLOSE	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_CREATE	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_DIRECTORY_CONTROL	C:\ProgramData\ESET\ESET File Security\Diagnostics\eset_*.dmp
IRP_MJ_CLEANUP	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_CLOSE	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_CREATE	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_DIRECTORY_CONTROL	C:\ProgramData\ESET\ESET File Security\Diagnostics\eset_*.mdmp
IRP_MJ_CLEANUP	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_CLOSE	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_CREATE	C:\ProgramData\ESET\ESET File Security\Diagnostics\Modules
IRP_MJ_CREATE	C:\ProgramData\ESET\ESET File Security\Diagnostics\Modules
IRP_MJ_CREATE	C:\ProgramData\ESET\ESET File Security
IRP_MJ_QUERY_VOLUME_INFORMATION	C:\ProgramData\ESET\ESET File Security
IRP_MJ_CLEANUP	C:\ProgramData\ESET\ESET File Security
IRP_MJ_CLOSE	C:\ProgramData\ESET\ESET File Security
IRP_MJ_CREATE	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_DIRECTORY_CONTROL	C:\ProgramData\ESET\ESET File Security\Diagnostics\eset_*.tis.log
IRP_MJ_CLEANUP	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_CLOSE	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_CREATE	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_DIRECTORY_CONTROL	C:\ProgramData\ESET\ESET File Security\Diagnostics\eset_*.dmp
IRP_MJ_CLEANUP	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_CLOSE	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_CREATE	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_DIRECTORY_CONTROL	C:\ProgramData\ESET\ESET File Security\Diagnostics\eset_*.mdmp
IRP_MJ_CLEANUP	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_CLOSE	C:\ProgramData\ESET\ESET File Security\Diagnostics
IRP_MJ_CREATE	C:\ProgramData\ESET\ESET File Security\Diagnostics\Modules
IRP_MJ_CREATE	C:\ProgramData\ESET\ESET File Security\Diagnostics\Modules

 

[Jesposito 1]

Any news ?

I'm still at 100% CPU.

[Jesposito 1]

I really need to protect my servers with an antivirus solution. For now I can't use EFSW.

There is no such problem with EES on Windows 7/10. This is working great.

For administration purpose, I prefer to use the same antivirus editor on PC and servers.

Today I'm challenging you to achieve this goal : Make an ESET antivirus compatible with live environment without breaking my whole server farm at a random time.

[Marcos 5,286]

The problem seems to be with Anti-Phishing protection that cannot be turned off by a policy because the superior protection module (Web access and email protection) is disabled.

I would recommend enabling protocol filtering in the advanced setup and enabling web access protection in gui. Beforehand make sure that the following hotfix is installed to prevent potential issues:

https://support.microsoft.com/de-de/help/2664888/computer-stops-responding-when-you-run-an-application-that-uses-the-windows-filtering-platform-api-in-windows-7,-windows-server-2008-r2,-windows-server-2008,-or-windows-vista

Another workaround would be to stop applying the Anti-phishing setting in the policies that are applied on the server.

The issue will be ultimately fixed in EFSW 6.5 soon.

[Jesposito 1]

Thank you @Marcos , I'll check your solutions.

This is an history for you.

When I 1st installed the EFSW on all my servers, I had 80% of them taking 100% CPU Friday afternoon starting almost the same time. I deployed EFSW during 2 or 3 days during this week. It took 1 hour to the entire week-end the get all servers CPU return to normal. Some weeks later EFSW did the same thing, and take again the entire system unresponsive. I had no choice than uninstall it.

When ESET release a new version I deploy it on test servers and every time I'm getting problems with the CPU, but they don't start this together anymore. That's a good improvement.

We had a security audit and the most important problems is the antivirus on servers and Web application using HTTP. They broke through the Windows security and stole all domain admin password because of no antivirus. HTTP is not related to you, but they stole credentials using man in the middle.

We are deploying new hardware at this time and I have 5 Windows 2012 R2. They are not in production for now. I installed EFSW on them. There is no problems.

[Jesposito 1]

Does it look ok like this ? I prefer the last workaround. Deploying the patch for Windows Filtering Platform can't be automated easily. I run into the issue at the beginning of v6, where the Agent was freezing my W7 with EES and I had to take a look at this MS HotFix.

[Marcos 5,286]

The setting in the last screen shot is the right one. If you leave it disabled in a policy applied on EFSW, the issue should not occur. It's ok to leave protocol filtering disabling on servers as long as they don't serve as terminal servers and users don't use it to browse the Internet or read email.

The issue didn't occur on Windows 2012 because it came with the bug addressed by the hotfix KB2664888 already fixed.

On Windows 7 workstations I would strongly recommend installing the mentioned hotfix. Protocol filtering is essential for protecting computers from web and email threats and therefore should never be disabled on workstations.