Jump to content

High CPU usage from a2start and commservice


SeriousHoax
 Share

Recommended Posts

4 hours ago, JeremyNicoll said:

Which current beta?   The one we've been running for days, or the one released 15 minutes ago?   (it's a bit soon to say for the latter.   For the former, yes it was still not perfect, as I reported on the Beta forum.)

We just released 2020.7 stable, and the new beta (which was moved to stable a few minutes ago) should have had extra fixes for performance issues.

https://blog.emsisoft.com/en/36400/new-in-2020-7-new-rdp-attack-alerts-new-notifications-system/

Link to comment
Share on other sites

  • 4 months later...

I am also experiencing very high CPU usage by Emsisoft Protection Service on my Dell XPS 3431 system running Windows 10 Enterprise 2004. I would probably not notice it on i9-9900 8-core CPU but it stays at close to 40% CPU usage for hours at random times/days. Reboot does not help. I was considering re-install but at the same time, ESET NOD32 on my other system never had this issue so I may just abandon Emsisoft I was using for years since this high CPU usage issue is not fixed for months...

Link to comment
Share on other sites

8 minutes ago, root said:

I am also experiencing very high CPU usage by Emsisoft Protection Service on my Dell XPS 3431 system running Windows 10 Enterprise 2004. I would probably not notice it on i9-9900 8-core CPU but it stays at close to 40% CPU usage for hours at random times/days. Reboot does not help. I was considering re-install but at the same time, ESET NOD32 on my other system never had this issue so I may just abandon Emsisoft I was using for years since this high CPU usage issue is not fixed for months...

One thing that helped me was enabling memory usage optimization.

Link to comment
Share on other sites

1 hour ago, root said:

I am also experiencing very high CPU usage by Emsisoft Protection Service on my Dell XPS 3431 system running Windows 10 Enterprise 2004. I would probably not notice it on i9-9900 8-core CPU but it stays at close to 40% CPU usage for hours at random times/days. Reboot does not help. I was considering re-install but at the same time, ESET NOD32 on my other system never had this issue so I may just abandon Emsisoft I was using for years since this high CPU usage issue is not fixed for months...

How many months have you had this problem?  Why have you not mentioned it before?

What other security software, if any, is on your machine?

Which update "feed" are you on - stable or delayed?

Link to comment
Share on other sites

I think I've noticed this issue about a month or so ago but could be wrong on exact timing as I use multiple systems at home. It could be a 2-3 weeks. I don't have any other protection on that particular system but the reason I've noticed it was that the CPU fan started spinning too frequently and stays audible that wasn't happening in the past. I am IT professional so this system is my primary work machine I'm mainly doing a research via Web browser and editing documents. I have other applications installed that were recently updated (like VMware Workstation Pro, Wireshark, GitHub, Code, NetScanTools etc.) but all software I use is licensed.

What is concerning is that my wife's PC seems to ne experiencing the same problem - Dell Precision 3420 running W10 ENT 2004 with quad core Intel and 16GB RAM. Few days ago she mentioned that the "computer is working hard" which I paid no attention at the moment but today when I've checked her computer during the same time mine had Emsisoft Protection Service at 40%, one her the same service was running at 20%. It was around 9am EST.

I am on "stable" feed.

Memory usage optimization is unchecked.

Link to comment
Share on other sites

7 hours ago, eliastz said:

This has been going on for months now - no attempt by emsisoft to fix it. 

We thought this was fixed. With no one reporting that the issue was still happening, we had no way to know it was still a problem.

We're going to need to know which process is using too much CPU time. If you're on Windows 10 then please be sure to switch to the Details tab in Task Manager so that you can give us a process name that ends in .exe rather than one of the "friendly" names that appear on the Processes tab.

We will also need debug logs from anyone still having this issue. Here's how to enable debug logging:

  1. Open Emsisoft Anti-Malware.
  2. Click on the little gear icon on the left side of the Emsisoft Anti-Malware window (roughly in the middle).
  3. Click Advanced in the menu at the top.
  4. Scroll to the bottom of the Advanced section, and change the option for Debug logging to Enabled for 1 day.
  5. After that, close the Emsisoft Anti-Malware window.
  6. Restart your computer. If you're on Windows 8.1 or Windows 10 then restart by right-clicking on the Start button, going to Shut down or sign out, and selecting Restart from this list to bypass Fast Startup.
  7. Reproduce the issue you are having (wait until the CPU usage gets high).


Here's how to send us the debug logs once you've been able to reproduce the issue:

  1. Open Emsisoft Anti-Malware.
  2. Click on the little icon in the lower-left (right above the question mark) that looks like little chat bubbles.
  3. Click on the button that says Send an email.
  4. Select the logs on the right that show today's dates (if you try to send too many logs, then we may not receive them).
  5. Fill in the e-mail contact form with your name, your e-mail address, and a description of what the logs are for (if possible please leave a link to the topic on the forums that the logs are related to in your message).
  6. If you have any screenshots or another file that you need to send with the logs, then you can click the Attach file button at the bottom (only one file can be attached at a time).
  7. Click on Send now at the bottom once you are ready to send the logs.

Important: Please be sure to turn debug logging back off after sending us the logs. There are some negative effects to having debug logging turned on, such as reduced performance and wasting hard drive space, and it is not recommended to leave debug logging turned on for a long period of time unless it is necessary to collect debug logs.

  • Like 1
Link to comment
Share on other sites

14 hours ago, eliastz said:

Same problem on an HP laptop and Dell desktop, both running the most up to date versions of Windows 10, 16GB RAM, i7 CPU. This has been going on for months now - no attempt by emsisoft to fix it. 

That's not correct  - there's been several attempts, and discussions about it here and on the Beta forum.  And for many of us the problem did seem to be fixed.  You've posted several times in this thread so - unless you didn't stay uptodate reading it between your posts - you should have known that.

  • Upvote 1
Link to comment
Share on other sites

22 minutes ago, JeremyNicoll said:

That's not correct  - there's been several attempts, and discussions about it here and on the Beta forum.  And for many of us the problem did seem to be fixed.  You've posted several times in this thread so - unless you didn't stay uptodate reading it between your posts - you should have known that.

Understood...the problem clearly is my infrequent perusing of the forum rather than Emsisoft's inability to provide an effective fix.  A  paid piece of software ought to simply work - the customer should not have to enagage with developers, provide debug logs, etc.   

Link to comment
Share on other sites

8 minutes ago, eliastz said:

Understood...the problem clearly is my infrequent perusing of the forum rather than Emsisoft's inability to provide an effective fix.  A  paid piece of software ought to simply work - the customer should not have to enagage with developers, provide debug logs, etc.   

As someone on this thread who DID have performance problems, they were fixed for me.  In my view, they have gone to effort to resolve performance issues.  Perhaps what you are experiencing is yet another issue, which isn't widespread, and would benefit if you channel your energy into assisting their support with logs etc rather than to retort in the forum, which probably won't get you very far.   Stay positive, be supportive, you may get a solution!  

Link to comment
Share on other sites

11 minutes ago, eliastz said:

 A  paid piece of software ought to simply work - the customer should not have to enagage with developers, provide debug logs, etc.   

Whether one pays for something or not is largely irrelevant, except that with a commercial company like Emsisoft there are people paid to try to fix things; at least we users do not have to rely on people with goodwill having the time to try to do so.

The problem is that there's a huge variation in the combination of different underlying hardware (and thus drivers installed), amounts of memory, speeds of processors, and all the different application software installed on people's systems.  Then, although in theory every one use "Windows", Emsisoft support Win 7, 8.1 and 10.  As I'm sure you know there's multiple versions of Win 10.  Then, different people have different sets of Windows updates installed.  People may or may not have other security software installed.  None of the other things installed on a machine are likely to be totally bug-free (eg Windows is not - that's why MS continually release maintenance updates).

There is no way that any programmer can predict all the problems that might occur in other people's machines, even if all the ones the programmers and testers use seem to behave "properly".

(Things are worse in Linux because each 'distro' is assembled from many alternative parts of each layer of the OS.  Eg users have different "window managers".  At least in Windows there's only the MS one in use - though of course that's at multiple different levels of underlying OS and affected by different sets of WIndows Updates and screen hardware etc.)

Another Windows example (whose context menus interact with EAM) is "File Explorer"... where /most/ users use the MS-supplied one.  But some people also use third-party ones.
 

As for "the customer should not have to enagage with developers, provide debug logs, etc", the bottom line is that programmers cannot fix problems that they cannot recreate on their own systems if they do not know what is causing the problem.  Getting debug logs from people who do have the problem /may/ provide hints as to where the problem lies.  I know (as a programmer) that such logs - necessarily not hugely detailed in every aspect of what a system does - may need to be made more detailed as one tries to home-in on the actual cause of a problem.  So eg successive betas might not just have improved code, they may also do more detailed logging in the parts of the system that the programmers think might be at fault. 

Link to comment
Share on other sites

7 hours ago, GT500 said:

We thought this was fixed. With no one reporting that the issue was still happening, we had no way to know it was still a problem.

We're going to need to know which process is using too much CPU time. If you're on Windows 10 then please be sure to switch to the Details tab in Task Manager so that you can give us a process name that ends in .exe rather than one of the "friendly" names that appear on the Processes tab.

We will also need debug logs from anyone still having this issue. Here's how to enable debug logging:

 

  1. Open Emsisoft Anti-Malware.
  2. Click on the little gear icon on the left side of the Emsisoft Anti-Malware window (roughly in the middle).
  3. Click Advanced in the menu at the top.
  4. Scroll to the bottom of the Advanced section, and change the option for Debug logging to Enabled for 1 day.
  5. After that, close the Emsisoft Anti-Malware window.
  6. Restart your computer. If you're on Windows 8.1 or Windows 10 then restart by right-clicking on the Start button, going to Shut down or sign out, and selecting Restart from this list to bypass Fast Startup.
  7. Reproduce the issue you are having (wait until the CPU usage gets high).

 


Here's how to send us the debug logs once you've been able to reproduce the issue:

 

  1. Open Emsisoft Anti-Malware.
  2. Click on the little icon in the lower-left (right above the question mark) that looks like little chat bubbles.
  3. Click on the button that says Send an email.
  4. Select the logs on the right that show today's dates (if you try to send too many logs, then we may not receive them).
  5. Fill in the e-mail contact form with your name, your e-mail address, and a description of what the logs are for (if possible please leave a link to the topic on the forums that the logs are related to in your message).
  6. If you have any screenshots or another file that you need to send with the logs, then you can click the Attach file button at the bottom (only one file can be attached at a time).
  7. Click on Send now at the bottom once you are ready to send the logs.

 

Important: Please be sure to turn debug logging back off after sending us the logs. There are some negative effects to having debug logging turned on, such as reduced performance and wasting hard drive space, and it is not recommended to leave debug logging turned on for a long period of time unless it is necessary to collect debug logs.

@GT500 Will do once I hear the fan again 🙂

There is something that could be related to high CPU usage event: at that time, I was doing a research so I had at least 7-8 Chrome windows open with about 100 tabs for number of days, in addition to Firefox with few tabs. Chrome was using 6-7GB of memory and few % of GPU. I was thinking about  uninstalling Emsisoft so I closed majority of browser tabs and around that time things came back to normal. Not sure if that is related but logically, it could be some of the web pages that were dynamically refreshed that were continuously scanned.

Thank you all

 

Link to comment
Share on other sites

FYI: For anyone who wants to monitor Emsisoft Anti-Malware CPU usage, the easiest way is to use a tool like Process Hacker. It's basically an advanced Task Manager, and you can type emsi in the search field to quickly show only the processes from Emsisoft Anti-Malware. Here's a screenshot of what it looks like:

image.png

Link to comment
Share on other sites

16 hours ago, eliastz said:

A  paid piece of software ought to simply work - the customer should not have to enagage with developers, provide debug logs, etc.

I understand that this is frustrating, however every software has bugs, and the developers need information about those bugs in order to fix them. They can't just wave a magic wand and make all of the problems go away. If we're not able to reproduce the issue in our own testing, then someone who is having the issue needs to send us debug information so that our developers know what is causing it. Without this information, fixing the bug is usually impossible.

During the course of this year, a number of people have provided us with debug information for performance issues, and as far as I know we were able to resolve those issues for everyone who sent us logs. Unfortunately I don't think anyone sent us feedback after the last fix was published, and since no one told us this was still a problem we could only conclude that the issues had been fixed. After all if no one is complaining about a problem, then it must not be a problem any longer.

Link to comment
Share on other sites

8 hours ago, GT500 said:

FYI: For anyone who wants to monitor Emsisoft Anti-Malware CPU usage, the easiest way is to use a tool like Process Hacker. It's basically an advanced Task Manager, and you can type emsi in the search field to quickly show only the processes from Emsisoft Anti-Malware. Here's a screenshot of what it looks like:

image.png
Download Image

 

...or tried and true Process Explorer by Mark Russinovich/Sysinternals:

https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer 

 

Link to comment
Share on other sites

15 hours ago, root said:

...or tried and true Process Explorer by Mark Russinovich/Sysinternals:

https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer 

If it has a search field or filter that can accomplish the same thing, then it would certainly work as well. Process Hacker still has some features that Process Explorer doesn't, so developers tend to prefer it over Process Explorer.

Link to comment
Share on other sites

  • 3 weeks later...

So, it was fine for number of days following my posts. Then, I've noticed that Emsisoft Protection Service is using 10+% CPU and followed the instructions to enable the logging for 1 day. As part of this process, I was asked to reboot the computer (and I've closed some of the browser tabs I no longer needed along with few apps). After restart, everything was as normal, a2* services CPU usage stayed low so I never checked the logs or submitted them.

Couple days ago, all the sudden, it started again. Emsisoft Protection Service is eating 20+% of CPU with no apparent reason. It's been now 2-3 days since it is staying this way so I think it is the right moment to troubleshoot this without rebooting computer.

@GT500 any suggestions what to do so I can give you some more info for analysis?

a2 2020-11-22_083019.png

Link to comment
Share on other sites

5 hours ago, root said:

@GT500 any suggestions what to do so I can give you some more info for analysis?

What version of Emsisoft Anti-Malware do you have installed? 2020.11.0.10501?

I assume the CPU is either a dual core or a quad core?

We'll need debug logs at some point so that our developers can look in to this further. Here's instructions for getting debug logs:

  1. Open Emsisoft Anti-Malware.
  2. Click on the little gear icon on the left side of the Emsisoft Anti-Malware window (roughly in the middle).
  3. Click Advanced in the menu at the top.
  4. Scroll to the bottom of the Advanced section, and change the option for Debug logging to Enabled for 1 day.
  5. After that, close the Emsisoft Anti-Malware window.
  6. Reproduce the issue you are having (wait for commservice CPU usage to rise to 7-8%).

And here's how to send us the logs:

  1. Once you have reproduced the issue, open Emsisoft Anti-Malware again.
  2. Click on the little icon in the lower-left (right above the question mark) that looks like little chat bubbles.
  3. Click on the button that says Send an email.
  4. Select the logs on the right that show today's dates (if you try to send too many logs, then we may not receive them).
  5. Fill in the e-mail contact form with your name, your e-mail address, and a description of what the logs are for (if possible please leave a link to the topic on the forums that the logs are related to in your message).
  6. If you have any screenshots or another file that you need to send with the logs, then you can click the Attach file button at the bottom (only one file can be attached at a time).
  7. Click on Send now at the bottom once you are ready to send the logs.

Important: Please be sure to turn debug logging back off after sending us the logs. There are some negative effects to having debug logging turned on, such as reduced performance and wasting hard drive space, and it is not recommended to leave debug logging turned on for a long period of time unless it is necessary to collect debug logs.

Link to comment
Share on other sites

Hi @GT500,

Emsisoft 2020.11.0.10501

CPU is 8-core i9-9900, 64GB DDR4 RAM, Windows 10 Enterprise 2004 20H2

I've just enabled the logging for 1 day as the CPU is constantly around 20% and hovers around 12% for a2service.exe in Process Hacker. How long you'd like me to collect the logging data?

Thanks

 

Link to comment
Share on other sites

15 hours ago, root said:

How long you'd like me to collect the logging data?

Logging needs to happen starting from a fresh boot (restart the PC by right-clicking on the Start button, going to Shut down or sign out, and selecting Restart from that menu to bypass Fast Startup) until the CPU usage has climbed enough to be obviously higher than it should be. If it starts out high then give it 10 minutes or so to make sure that it's completed any updates, and make sure no scheduled scans are running that would increase the CPU usage.

 

15 hours ago, root said:

I've just enabled the logging for 1 day as the CPU is constantly around 20% and hovers around 12% for a2service.exe in Process Hacker. How long you'd like me to collect the logging data?

The 9900 (I would believe all models) has Hyper-Threading, which means Windows would see it as having 16 cores unless Hyper-Threading were disabled. 12.5% would be an entire CPU core if Hyper-Threading were disabled, however with it turned on then that would be two cores maxed out (each core maxed would be 6.25%). Since this issue has thus far only maxed out one core for everyone else, I assume that means you have Hyper-Threading disabled?

Is a2service.exe the only process from Emsisoft Anti-Malware that has abnormally high CPU usage? You can see my CPU usage in an earlier post and I have an 8-core/16-thread CPU as well (AMD Ryzen 7 3800X), so that should help give you an idea of what is "normal" for CPU usage of our processes.

Link to comment
Share on other sites

7 hours ago, GT500 said:
23 hours ago, root said:

How long you'd like me to collect the logging data?

Logging needs to happen starting from a fresh boot (restart the PC by right-clicking on the Start button, going to Shut down or sign out, and selecting Restart from that menu to bypass Fast Startup) until the CPU usage has climbed enough to be obviously higher than it should be. If it starts out high then give it 10 minutes or so to make sure that it's completed any updates, and make sure no scheduled scans are running that would increase the CPU usage.

Last time I had excessive CPU usage by a2 service I've enabled the logging and rebooted the PC as suggested. Following the reboot, everything went to normal and stayed this way for number of days. Yesterday, I've enabled the logging for 1 day and did not reboot the PC until next morning (today). During that time, CPU usage by a2service was between 12-20% in Process Hacker (20-30% in Windows Task Manager) and based on attached screenshot, all cores were engaged (I have HT enabled by default).

After a reboot (with logging enabled) this morning, CPU usage is normal and I no longer see the issue I've reported. Once again, last time there were number of days following the restart when it was normal so keeping the logging at 1 day is probably not sufficient to troubleshoot this issue, I am not even sure that 1 week will be enough.

Any ideas what to do next while I'm waiting for 1 day logging to wrap up without having a CPU spikes after restart? I should have logs from yesterday capturing high CPU usage already.

 

CPU load a2 2020-11-24_081556.png

Link to comment
Share on other sites

15 hours ago, root said:

Once again, last time there were number of days following the restart when it was normal so keeping the logging at 1 day is probably not sufficient to troubleshoot this issue, I am not even sure that 1 week will be enough.

You can configure debug logging for Enabled always if you want. Just be sure to turn it off after you've sent us the debug logs. It wastes a lot of disk space if left on.

 

15 hours ago, root said:

I should have logs from yesterday capturing high CPU usage already.

I think the logs specifically need to start from boot of the PC so that we can see when the issue starts happening in the logs.

 

15 hours ago, root said:

Any ideas what to do next while I'm waiting for 1 day logging to wrap up without having a CPU spikes after restart?

Considering the fact that it's a2service.exe that's causing the high CPU usage, I don't know for certain if there's a way you could trigger it manually. It might be possible if it's due to our network filtering driver to trigger it by downloading large files, or if it's due to our scan engine to trigger it by running some scans.

Link to comment
Share on other sites

8 hours ago, GT500 said:

You can configure debug logging for Enabled always if you want. Just be sure to turn it off after you've sent us the debug logs. It wastes a lot of disk space if left on.

For quite a while (years, I mean) I've run EAM with debug logging on all the time and relied on rebooting the machine every few days to force active logs to be closed, and new ones to be created, and deleted the old ones whenever it occurred to me.  But I reboot much less often now.  So I manually disable and re-enable debug logging just after midnight each day, and also after the end of whole-system scans, and every few days I delete the oldest sets of logs.

In the last few days I've changed this slightly.  Now I'm trying to get into the habit of, when re-enabling logging, always picking the "for seven days" option, so that if I hit a bad patch in my illness and more or less ignore the pc for a while, logging will stop eventually.  I still need to cull the older logs by hand.  Of course I could cull via a script, but a script wouldn't know whether some logs had to be retained because they covered a period where something went wrong.  I'm also toying with trying to write an AutoIt script to do the stop & re-enable thing for me, triggered by a Scheduled task.

Link to comment
Share on other sites

It is annoying....I probably going to do the last attempt and enable the logging for a week and will not try to reboot in the meantime...it must be a way to track what is keeping Emsisoft busy even the logging wasn't enabled when it accured.

emsi 2020-11-30_212300.png

Link to comment
Share on other sites

4 hours ago, root said:

...it must be a way to track what is keeping Emsisoft busy even the logging wasn't enabled when it accured.

It's best to be able to track the CPU usage over time, and being able to do that from the point where it starts to abnormally increase makes the debug logs more useful for determining what's going on.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...