What you did: Made a default install of CIS 5.0.162636.1135
What actually happened or you actually saw: mbamservice.exe CPU usage went from a few percent up to 80+% on a Pentium III E 650MHz system with 768Mb of RAM.
What you expected to happen or see: I had expected no unfavorable interaction between either CIS or MBAM applications.
How you tried to fix it & what happened: Exiting CIS returned system to normal. Disabling Defense+ made no detectable change.
Details (exact version) of any software involved with download link: CIS 5.0.162636.1135
Any other information you think may help us: During the install process, ticking the “firewall only” box allowed mbamservice.exe to return to normal/acceptable CPU usage.
An excellent issue report thanks. I’ll forward it now. Meanwhile you may be able to make MBAM & CIS work together by disabling real time file scanning in either, and exempting the other’s executable(s) from the real time scanner of the AV left running.
Please note that regrettably CIS cannot be guaranteed to work with other security software.
In order to give you an authoritative answer, I first uninstalled COMODO CIS 5.0.162636.1135 (with Revo Uninstaller) and then I reinstalled with no changes made to the default settings.
After a reboot, I ran the CIS product update check and saw a download/install of some files.
For purity of results, another reboot was made and then I verified the original reported facts as stated in the above original post of this thread. Indeed the CPU usage of mbamservice.exe was generally 30-40%.
I then returned to CIS and ticked the box for permanently disabling Defense+, as you requested, followed by another reboot.
Yes - as with my method of installing with “Firewall Only”, your method also results in return to normal behavior of mbamservice.exe where an idle system shows no elevated CPU usage for mbamservice.exe.
THanks for being so careful with this it is very much appreciated. Please could you a) re-enable D+ and reboot b) try adding the whole MBAM directory (and any related directories & sub-directories) to buffer overflow exclusions under D+ settings ~ Execution control and rebooting.
Although it’s probably abundantly clear to most COMODO staffers, the problem outlined in the original post, now extends to COMODO CIS V5.0.163652.1142 and I have verified that normalcy returns if Defense+ is “Disabled” as was the case with the previous version of CIS.
With COMODO’s permission, I have altered the “Subject” line accordingly.
I have a rahter similar set up. Malwarebytes along with Comodo firewall. I had default install of Comodo firewall because I like network+ functionality. Everything was fine till I upgrade to latest version (5.01636512.1142)
However I see malwarebytes being stuck between 40-50% all the time. No matter what trust or changes I make it still takes a lot of CPU.
Do you have an update on this? Is there a patch in the works that we can apply in the near future
I guess I will chime in on the bug fix ticket as 1Pw is not the only one with that issue.
Please checkout the picture attached showing the mbamservice.exe issue
mbamservice.exe is normally only executing if the system has an activated full version of Malwarebytes’ Anti-Malware (MBAM). mbamservice.exe is part and parcel of MBAM’s real-time protection.
Else mbamservice.exe is dormant on a system with the free/unactivated version of MBAM - even if the free version is doing on-demand scanning.
@Serg - for a more authoritative answer, please post to the Malwarebytes’ Anti-Malware forum where a staffer or voluntary expert may more fully state mbamservice.exe’s function.
http://forums.malwarebytes.org/
Or better yet, join the MBAM forum thread where this situation is being actively discussed:
I have been too busy trying to exclude all traces of malwarebytes in comodo and obviously it didn’t work.
I killed ctfmon process and CPU usage dropped under 5% with a few spikes here and there. Then I completely stopped it from loading and gave machine a reboot.
So far, so good. Malwarebytes and Comodo are getting along just fine now.
It is strange that comodo’s new release causes such odd behavior. Comodo engineers: Would you please have it fixed?
Thanks Spoutnik55 and I let you all know if the issue pops back up again.