High CPU Consuming on Endpoint Security on Windows Server

[Frank_Aguilieri]

Hello,

We have some Windows Server 2016 scenarios with high CPU usage by EndPoint Forensic Recorder service. Apparently this only happens on servers that have more simultaneous connections or more network traffic.

Endpoint version 86.10

Can someone help me?

Thanks

[G_W_Albrecht]

Better contact CP TAC to discover the reason for this behaviour !

[Frank_Aguilieri]

Thanks  G_W_Albrecht

[the_rock]

I use E86.20 and had not seen this issue. Are you using just vpn endpoint or sandblast suite (harmony endpoint)?

Andy

[G_W_Albrecht]

This is EFRService.exe - Forensics Recorder, part of SandBlast...

[Chris_Atkinson]

In such cases we have sk178706 in particular for Exchange Servers...

[G_W_Albrecht]

Please provide a link - sk178706 is not found...

[Chris_Atkinson]

sk178706: Endpoint Security Client policy optimization for Microsoft Exchange Server 

[G_W_Albrecht]

Thanx - looks good...

[djhornby]

Any update on this as I am seeing the same on some 2019 Servers.

[lucas-ferreira]

Hey guys!

We were facing the same problem. In contact with Check Point's TAC, a developer generated a new EPS.msi where he disabled the Interface, and changed some parameters. Unfortunately he did not provide us with the commands executed to generate this (.msi).

The problem happened on Windows Servers 2012 and 2019, today I have the endpoints installed thanks to this file that the developer generated.

Because it is a Terminal Server (TS). The endpoint analyzed each connection that communicated with TS and ended up increasing the CPU a lot and even crashing to the point where we restarted the server.

[rmsource_dotcom]

If anyone finds a solution please post as we are seeing same symptoms with a customer with same scenario. Happens everyday multiple times a day for last couple weeks. We have a TAC case open.

[Chris_Atkinson]

Are you running E86.25 or newer?

[Frank_Aguilieri]

Hello Chris,

I am running 86.10 and 86.25

[Ruan_Kotze]

Might be worthwhile testing version E86.40.  There is a fix for high CPU usage on Windows Servers.

[John_Richards]

Any luck finding a solution? We had a case open with TAC for 6 months. After much back and forth it seemed to improve somewhat. 3 months later and we are now back to square one (100% cpu on the recorder). We are opening another ticket with TAC today. Server exclusions, latest recommended version and following a number of SK's has not helped. Any ideas appreciated.

[djhornby]

What version are you running?

We were seeing this occasionally on random Machines (PC's & Servers) quick fix was a reboot.

87.31 & 87.51 has been quite stable though.

I'm currently trialling 88.1 & 87.57

[John_Richards]

Thanks, we are on the latest "recommended DHS" version. It seems the only solution is to reboot (not a solution) or wait for another upgrade. I think we have tried 7-8 different versions over 6 months. We have reopened a TAC case.

[G_W_Albrecht]

This EFRService issue on MS Servers is ongoing for a long time now. Several customers complained during the last two years, and although R&D is fixing and excluding, the issue still can appear.

[John_Richards]

I fully agree and Check Point should either say there is no fix or "fix it". I'll be escalating this high up the chain for a definitive answer.

[Frank_Aguilieri]

Hello John,

When the TAC answer your ticket please post update for us.

Thanks

[asafebelo]

Hey, John.

Did you have a return for this case? I'm have same issue.

[John_Richards]

So this case was closed a while back. First and foremost you need to be on the latest build. At the time we applied E87.31. Below is th original fix from TAC. This may or may not be fixed in newer versions. The developer below is Check Point.

Files.db is a database that the EFRService uses. Normally a purging mechanism keeps the files size down as it shouldn't be even close to the size you saw, but for some reason it isn't working on your systems. The Developer wanted to look at the files size because they were seeing a lot of manipulation from the WPR we collected. There were fixes to how the files.db database is handled in the newer versions of the client, hence why the developer states that upgrading will fix this.

As for disabling self protections, the following steps are the best way:

• The best way to disable self protections is to do the following:
• Start an uninstall of the client
• When it asks for the uninstall password do not enter it and open Task Manager
• Go to the Details tab and then look for PassDialog.exe
• Right click on it and choose to open file location
• Cancel out of the uninstall
• Open PassDialog.exe and it will ask for the uninstall password, once entered it will disable self protections
• To reenable self protections you'll need to reboot the machine

[the_rock]

Amazing feedback.

Andy

[rmsource_dotcom · Accepted solution]

We had the exact same symptoms with one of our clients. The underlying issue was due to a network ACL blocking traffic. We initially found logs that indicated an issue with Forensics data not being uploaded. This pointed us towards checking connections from the CPHE clients with the Connectivity Tool ("C:\Program Files (x86)\CheckPoint\Endpoint Security\Endpoint Common\bin\CheckConnectivity.exe"). After seeing multiple fails we had our Network team whitelist the proper domains based off SK116590.

After adding the domains we no longer see CPU performance issues from the "Endpoint Forensic Recorder service". Hope this helps at least one person.