Jump to content

Sccomm.exe high CPU after fix


Recommended Posts

Machines that got caught by this weekend's oops are showing sccomm.exe saturating one CPU core after deleting the bad ref file and rebooting.  We terminated sccomm.exe on most machines (which is equivalent to stopping the MEEClientService service except the service doesn't respond to stop commands).  When machines get rebooted and the service restarts, we get a flurry of emails from the Malwarebytes server as a hundred thousand or more blocks of internal servers get reported.  But the high CPU usage continues.  The server was also showing high CPU usage and the database hit 10GB so we truncated it and set the retention to 1 day.  The server side is now under control.  Machines that were off over the weekend show minimal CPU usage by sccomm.

How do we stop sccomm.exe from gobbling CPU, and less important, can we delete the local records of blocks before restarting the MEEClientService?  Email to corporate support hasn't been answered, but they must be swamped dealing with customers in worse shape than us.

Link to post
Share on other sites

Looks like the problem is that sccomm.exe is choking on the local log files.  To fix on a remote target:

Stop the SCCommService .  (SCCommService probably won't respond to a service stop command, so use pskill or other task killer on sccomm.exe.)

Delete all txt and xml files in "C:\ProgramData\Malwarebytes\Malwarebytes’ Anti-Malware\Logs"

Restart the SCCommService with sc.

We see ~20,000 files in the log directory.  Deletion over the network takes around 5 minutes.

Link to post
Share on other sites

Every customer with this product has a suite of documentation that comes along with it.  Read page 5 of this guide:

https://www.malwarebytes.com/pdf/guides/MMLNBPGuide.pdf

It tells you how to fix many of the issues you folks are describing.  In addition to what you have already found, records of each rejected request from endpoints are eating your server hard drive.  You'll need to free that space up, and killing logs at the endpoint assure that you don't create the same situation again.

Link to post
Share on other sites
29 minutes ago, gonzo said:

Every customer with this product has a suite of documentation that comes along with it.  Read page 5 of this guide:

https://www.malwarebytes.com/pdf/guides/MMLNBPGuide.pdf

It tells you how to fix many of the issues you folks are describing.  In addition to what you have already found, records of each rejected request from endpoints are eating your server hard drive.  You'll need to free that space up, and killing logs at the endpoint assure that you don't create the same situation again.

Thanks

It was exactly that guide that eventually clued us in to the fix.  On the server side, we hit the 10GB SQL Express database size limit.  Following instructions in this thread

we truncated and shrunk the database.  And, we temporarily set the retention to 1 day and turned off email notifications.  I wrote a cleanup script customized for our environment.  Cleaning up the logs has worked on a few test machines.  Monday we'll worry about recording who has/hasn't gotten the cleanup and do everybody.

I suspect the fact that you're responding to posts this late on Friday night means you've had a tough week.  Hang in there.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.