Jump to content

Malwarebytes and Microsoft Security Essentials conflicts


Recommended Posts

I meant to type that in yesterday, but I guess I never hit submit. Now I can confirm that this is happening with not only MSE. Yesterday I had the same exact lockup issue with a computer that has never had MSE. It ran MBAM and MBAE, and only recently had a managed version of Viper installed, and had conflicts with this as well. I cannot confirm that it was a direct conflict with MB as I didn't have time to run tests. I can confirm that Uninstalling MB completely seemed to help.  Ultimately I Uninstaller Viper and reinstalled MB and installed MSE with exclusions, and the workstation was fine. But the initial lockups were exactly like the MSE/MB Lockups, and I seemed to gain control only initially after Uninstalling MB in safe mode. It was weird seeing the same problem without MSE being present. It now makes me wonder if this was a chance initiated by updates to both MSE and MB... 

Link to post
Share on other sites

  • Replies 180
  • Created
  • Last Reply

Top Posters In This Topic

I wonder if the underlying issue isn't a windows issue with the presence of two real-time scanning engines?  Since Microsoft says this is an unsupported configuration.  Maybe it doesn't matter what those two real-time engines are, just that there are two of them.

If that's the case and we can't truly solve this, even with exclusions, then I'll have to make a choice between SCEP and MBAM.....

Link to post
Share on other sites

1 minute ago, BryanWright said:

I wonder if the underlying issue isn't a windows issue with the presence of two real-time scanning engines?  Since Microsoft says this is an unsupported configuration.  Maybe it doesn't matter what those two real-time engines are, just that there are two of them.

If that's the case and we can't truly solve this, even with exclusions, then I'll have to make a choice between SCEP and MBAM.....

I really hope that is not the case. Especially since there is no one real time engine that is good enough to catch all threats... 

And it is so crazy, considering that before the problem crept up on us a few weeks back, we all seemed to run this same combination for years before running into a problem. 

Now I do run the same managed version or Viper on several other machines. We manage the entire BBB call center and main office out here in Las Vegas, NV, and their entire office of around 50 Workstations and a sever use the Managed Viper and MB Endpoint combination, all on Windows 7 64bit Pro and Server 08, and has No problems whatsoever, so far it is just this one workstation I have seen with the Conflict with Viper, so hopefully it has more to do with the setup on this one workstation, and we don't start seeing another trend arise. 

I just wish we would find a way to solve the problem within MB and MSE so we can all go back to the combination we are comfortable with and know works. If not, it may be time to come up with a new combination. I personally just don't trust another piece of anti Malware software like I do MB, and their is not another AV software out that works so well and takes so little resources to run like MSE. Hopefully someone can point a few out for us to test that play nice with MB. Just no Symantec or McAfee or Avast or AVG please, lol. I am sick of advertising and resource hogging... 

Link to post
Share on other sites

I have another question: Why does this issue only effect a certain number of workstations instead of every single one? For us, the issue has only effected a certain number of workstations and appears to be limited to those workstations.   All of our workstations have identical setups, yet only 25% have experienced any issues at all.  From what I can see, the issue doesn't appear to be effecting all workstations at your workplaces as well, correct?  I might add that we have individual MSEs installed so exclusions were not put in place for all PCs when they were made.  Could this randomness possibly be decrypted to solve the issue?

Link to post
Share on other sites

27 minutes ago, anthonyp said:

I have another question: Why does this issue only effect a certain number of workstations instead of every single one? For us, the issue has only effected a certain number of workstations and appears to be limited to those workstations.   All of our workstations have identical setups, yet only 25% have experienced any issues at all.  From what I can see, the issue doesn't appear to be effecting all workstations at your workplaces as well, correct?  I might add that we have individual MSEs installed so exclusions were not put in place for all PCs when they were made.  Could this randomness possibly be decrypted to solve the issue?

I can't answer that. I went into panic mode as soon as I found out this was a problem a few weeks back, and made it a point to login to every single Win7 workstation running MB Corporate and MSE, and added the exclusions to minimize productivity loss with all clients. That act stopped all out Chaos for my Modest IT Consulting and Support Business. However, my belief that it was not effecting MB Premium (or home) users came back to bite me, as increasingly more and more Workstations are being effected by this conflict as well. And that is where I first thought the same thing you just mentioned; this didn't seem to be effecting ALL users. With MB home users, at first it seems to be completely random, some seem to need the exclusions, others seem to be fine without them. 

However I have noticed that a lot of my home users tend not to update their MB. MB is supposed to update itself, but when a version update comes out, instead of automatically updating it prompts the client to hit ok and approve of updating the version, and the client never does, and that's when it starts to get really out of date. In those cases those users seem to not be effected until MB is finally updated, and even then the problem doesn't seem to effect them right away. It seems to take hold after they update the version build of MB, then update definitions, then restart, then a MSE scan. They always seem to be effected after all of those conditions have been met, and then a MSE scan is triggered then all hell breaks lose.

I was testing on a computer that had not been effected just a few days ago, and it wasn't until after update, restart, and then MSE scan that the lock up started happening, so maybe that's why not all users are experiencing it. Some might need version updates to MB to be installed, and because those version updates have never happened they are behind on their definitions. Others might have theirs updated, but have never restarted since their new MSE definitions have been installed. It seems to take a restart to ensure the problem to kick in. And then some clients have the default of only one MSE scan a week, which is defaulted to Sunday at 2am, so their problems don't seem to be noticed until the Monday Morning after all those conditions had been met and then their scan finally triggered the problem. 

As a precaution, since it does seem to bite us sooner or later, I would probably take the time to add the exclusions on all of your workstations, even the ones that haven't shown problems yet, because it seems to be inevitable that they will one day have the lockup, I believe it's just a matter or having to meet the right conditions for the problem to take effect. 

Link to post
Share on other sites

We just had another system today running updated MSE defs and MBAM MSP Corporate/business 1.8 with the extreme lock ups.  The client was very frustrated and wanted to return the (brand new) system, which we just sold them recently, so I didn't even bother leaving MSE real time on to avoid any possibility that the lockups would creep up again.  I rebooted to safe mode, disabled MSE real time scanning, added exceptions anyway, and rebooted.  System is now working fine.

I've sent the diagnostic logs to MWB Corporate Support as they've requested, but again have yet to hear any updates from them.

*sigh* It seems we are seeing more and more systems with this issue creep up daily.  Clients are frustrated and we still don't have a permanent fix for these systems aside from disabling MSE realtime scanning.

Link to post
Share on other sites

1 hour ago, oreonutz said:

I can't answer that. I went into panic mode as soon as I found out this was a problem a few weeks back, and made it a point to login to every single Win7 workstation running MB Corporate and MSE, and added the exclusions to minimize productivity loss with all clients. That act stopped all out Chaos for my Modest IT Consulting and Support Business. However, my belief that it was not effecting MB Premium (or home) users came back to bite me, as increasingly more and more Workstations are being effected by this conflict as well. And that is where I first thought the same thing you just mentioned; this didn't seem to be effecting ALL users. With MB home users, at first it seems to be completely random, some seem to need the exclusions, others seem to be fine without them. 

However I have noticed that a lot of my home users tend not to update their MB. MB is supposed to update itself, but when a version update comes out, instead of automatically updating it prompts the client to hit ok and approve of updating the version, and the client never does, and that's when it starts to get really out of date. In those cases those users seem to not be effected until MB is finally updated, and even then the problem doesn't seem to effect them right away. It seems to take hold after they update the version build of MB, then update definitions, then restart, then a MSE scan. They always seem to be effected after all of those conditions have been met, and then a MSE scan is triggered then all hell breaks lose.

I was testing on a computer that had not been effected just a few days ago, and it wasn't until after update, restart, and then MSE scan that the lock up started happening, so maybe that's why not all users are experiencing it. Some might need version updates to MB to be installed, and because those version updates have never happened they are behind on their definitions. Others might have theirs updated, but have never restarted since their new MSE definitions have been installed. It seems to take a restart to ensure the problem to kick in. And then some clients have the default of only one MSE scan a week, which is defaulted to Sunday at 2am, so their problems don't seem to be noticed until the Monday Morning after all those conditions had been met and then their scan finally triggered the problem. 

As a precaution, since it does seem to bite us sooner or later, I would probably take the time to add the exclusions on all of your workstations, even the ones that haven't shown problems yet, because it seems to be inevitable that they will one day have the lockup, I believe it's just a matter or having to meet the right conditions for the problem to take effect. 

I was going to add exclusions to all workstations until we had one workstation that started freezing that had exclusions in place.  The only solution for that workstation was to disable RTS and I don't want to do that across all workstations. I also had hoped that this issue would be solved quickly and now I don't have hope that it will ever be resolved.  

Also, I thought it was MSE not updating because all of our MB clients are up-to-date. However, I have forced updates on MSE and there hasn't any new workstations acting up after receiving new definitions.  

@Cleatus Adding a startup delay to MB helped the problem at first and then a couple days later the workstations started locking up before the login screen again.  I will mention that these seemed slightly different and in one case the spinning stopped but the ctrl+alt+delete instructions never came up and nothing happened when pressing key combinations. Then I disabled RTS on that workstation and haven't had the problem since.

Edited by anthonyp
Link to post
Share on other sites

1 hour ago, oreonutz said:

...as increasingly more and more Workstations are being effected by this conflict as well. And that is where I first thought the same thing you just mentioned; this didn't seem to be effecting ALL users. With MB home users, at first it seems to be completely random, some seem to need the exclusions, others seem to be fine without them. 

 

We are seeing MBAM consumer, MBAM corporate both fully updated, MSE with/without exclusions and fully updated, still having the issue.  The only consistent fix so far has been disabling RTS in MSE.

Link to post
Share on other sites

Hey everyone, I'm sorry for the dead air this past week. I had been visiting family for Christmas break. The hits just keep on coming with this issue. I've read up on the latest posts, all you guys have been awesome with your research and updates for us, thank you. Anthony, nd1818 and Bryan; you guys bring up some great points in your questions, I'll explore those when I'm back in the office this coming week.

oreonutz, this issue does affect home users on the consumer builds, I apologize you had to find that piece out alone. I should've brought that up sooner to warn those who support a mix of client types. Our consumer team had been receiving some tickets regarding the issue at the same time it blew up on the business side. It's not as prevalent but it is happening.

We will do our best to get this solved for you guys, I know it's taken some time. Those of you who have machines which can reliably reproduce the issue, please PM me. I'll get you setup with some tools and steps for deeper investigation to help us get this figured out.

Link to post
Share on other sites

I'll check with our support team to see if they are still seeing reports of this.  At this point, when issues persist, they end up removing the malwarebytes client.

 

In our environment, we've disabled realtime scanning with MWB completely via policy, and only have it on with SCEP yet that didn't seem to do it for all machines.  If I hear of some more machines with the problem (reproducibly) I'll PM you.  Tough thing is that users get so frustrated that support just rips off MWB to get them back up and running, which I definitely understand.  Will ask them to give a user a loaner if they run into the problem again. 

Link to post
Share on other sites

59 minutes ago, Saidin said:

Any other updates about this issue?

We are currently at an impasse until more data is gathered. What is needed to troubleshoot is...

1.) A machine that can reliably lockup.

2.) This machine must also be able to recover from the lockup on its own with time. If the machine must be hard reset, we will not be able to use any tools to record processes while the lockup is happening.

If you have a machine that meets this criteria, PM me and I will send you the tool and instructions.

Link to post
Share on other sites

Hello,

We have around 200 licenses and installed on roughly 151 machines (Managed Client & Anti-Exploit). We have roughly 5 (that we know of) that lock up every single day, multiple times. We have the Microsoft Security client paths in the "Ignore List" in the management console, as well as the listed paths in the first post for SCEP. I can confirm the machines both have these exclusions when locking up.

We have also tried the delayed start and unticking random "Scan etc. etc." boxes in the policy to try and fix it. I discovered by accident that "Ending Process" on the MBAM executable in task manager instantly locks the machine and becomes unusable.

None of the machines we have recover from the lock-up. They need to be hard-reset and they then seem to work for a while. We have had reports of people 'Switching User' in windows and having the lockup but we haven't seen this ourselves.

On the most affected PCs we have had to remove MalwareBytes Managed Client as they were becoming unusable. 

I understand it's a wide spread problem and no one is really to blame; but people are not impressed here as we're a new MB customer and have just started rolling it out to all employee PCs.

Thanks,

Link to post
Share on other sites

  • 4 weeks later...

Hi guys, it's been a while since we had an update but things are looking promising again. The cases where folks had put in the exclusions but were still experiencing lockups, we dived a bit deeper into those and found a common thread.

Again the issue from page 3, post 90, is coming up; using 8.3 truncated short names for the file path locations in the Microsoft product's ignore list (due to Microsoft's denial of our path name with the apostrophe) are not pointing to the actual locations for the executable files, rendering the exclusions non-functional.

Not every computer is going to have the "%programfiles%\malwar~1" location mean the same place due to; different bitness (%programfiles% can be two locations depending on if the machine is 32 or 64), other folders in the same directory starting with the name "Malwarebytes" and the order in which the software was installed. This makes some Anti-Malware paths "%programfiles%\malwar~2" or "%programfiles%\malwar~3". Using the dir /x command to see the actual truncated name for that particular machine will show you what that machine is using. This was described in this post... 

 

We want to prevent mistakes in the ignore list so I came up with an ignore list scheme that should take into account every possible path for Anti-Malware, managed or un-managed, on either a 32 or 64 bit machine. I've gotten a lot of positive feedback on this list from the folks who I have been working with one-on-one in support tickets and PM's, so I'd like more of you guys to try it out. Let me know if this helps you guys!

C:\progra~1\malwar~1\mbam.exe
C:\progra~1\malwar~2\mbam.exe
C:\progra~1\malwar~3\mbam.exe
C:\progra~2\malwar~1\mbam.exe
C:\progra~2\malwar~2\mbam.exe
C:\progra~2\malwar~3\mbam.exe

C:\progra~1\malwar~1\mbamdor.exe
C:\progra~1\malwar~2\mbamdor.exe
C:\progra~1\malwar~3\mbamdor.exe
C:\progra~2\malwar~1\mbamdor.exe
C:\progra~2\malwar~2\mbamdor.exe
C:\progra~2\malwar~3\mbamdor.exe

C:\progra~1\malwar~1\mbamgui.exe
C:\progra~1\malwar~2\mbamgui.exe
C:\progra~1\malwar~3\mbamgui.exe
C:\progra~2\malwar~1\mbamgui.exe
C:\progra~2\malwar~2\mbamgui.exe
C:\progra~2\malwar~3\mbamgui.exe

C:\progra~1\malwar~1\mbamapi.exe
C:\progra~1\malwar~2\mbamapi.exe
C:\progra~1\malwar~3\mbamapi.exe
C:\progra~2\malwar~1\mbamapi.exe
C:\progra~2\malwar~2\mbamapi.exe
C:\progra~2\malwar~3\mbamapi.exe

C:\progra~1\malwar~1\mbamhelper.exe
C:\progra~1\malwar~2\mbamhelper.exe
C:\progra~1\malwar~3\mbamhelper.exe
C:\progra~2\malwar~1\mbamhelper.exe
C:\progra~2\malwar~2\mbamhelper.exe
C:\progra~2\malwar~3\mbamhelper.exe

C:\progra~1\malwar~1\mbampt.exe
C:\progra~1\malwar~2\mbampt.exe
C:\progra~1\malwar~3\mbampt.exe
C:\progra~2\malwar~1\mbampt.exe
C:\progra~2\malwar~2\mbampt.exe
C:\progra~2\malwar~3\mbampt.exe

C:\progra~1\malwar~1\mbamscheduler.exe
C:\progra~1\malwar~2\mbamscheduler.exe
C:\progra~1\malwar~3\mbamscheduler.exe
C:\progra~2\malwar~1\mbamscheduler.exe
C:\progra~2\malwar~2\mbamscheduler.exe
C:\progra~2\malwar~3\mbamscheduler.exe

C:\progra~1\malwar~1\mbamservice.exe
C:\progra~1\malwar~2\mbamservice.exe
C:\progra~1\malwar~3\mbamservice.exe
C:\progra~2\malwar~1\mbamservice.exe
C:\progra~2\malwar~2\mbamservice.exe
C:\progra~2\malwar~3\mbamservice.exe

C:\progra~1\malwar~1\SCComm.exe
C:\progra~1\malwar~2\SCComm.exe
C:\progra~1\malwar~3\SCComm.exe
C:\progra~2\malwar~1\SCComm.exe
C:\progra~2\malwar~2\SCComm.exe
C:\progra~2\malwar~3\SCComm.exe

C:\progra~1\malwar~1\mbae.exe
C:\progra~1\malwar~2\mbae.exe
C:\progra~1\malwar~3\mbae.exe
C:\progra~2\malwar~1\mbae.exe
C:\progra~2\malwar~2\mbae.exe
C:\progra~2\malwar~3\mbae.exe

C:\progra~1\malwar~1\mbae64.exe
C:\progra~1\malwar~2\mbae64.exe
C:\progra~1\malwar~3\mbae64.exe
C:\progra~2\malwar~1\mbae64.exe
C:\progra~2\malwar~2\mbae64.exe
C:\progra~2\malwar~3\mbae64.exe

C:\progra~1\malwar~1\mbae-cli.exe
C:\progra~1\malwar~2\mbae-cli.exe
C:\progra~1\malwar~3\mbae-cli.exe
C:\progra~2\malwar~1\mbae-cli.exe
C:\progra~2\malwar~2\mbae-cli.exe
C:\progra~2\malwar~3\mbae-cli.exe

C:\progra~1\malwar~1\mbae-svc.exe
C:\progra~1\malwar~2\mbae-svc.exe
C:\progra~1\malwar~3\mbae-svc.exe
C:\progra~2\malwar~1\mbae-svc.exe
C:\progra~2\malwar~2\mbae-svc.exe
C:\progra~2\malwar~3\mbae-svc.exe

 

Edited by djacobson
Link to post
Share on other sites

  • 2 weeks later...

Is there an update regarding this issue?

We have got to the stage now where we are no longer installing Malwarebytes on clients machines due to the lock ups and incredibly slow start ups.

Not the best for protecting our customers machines, and is also causing increased workloads for us due to these installation issues, and also if a machine does get infected, it takes longer to resolve when they dont have malwarebytes installed. 

Link to post
Share on other sites

4 hours ago, weryourit said:

Is there an update regarding this issue?

See my post right before yours. The cases we've taken on where the exclusions were not fixing the issue, those have turned out to be because the location doesn't exist. This is due to the use of path variables which cannot apply to all possible locations on each computer in the environment. Exclusions were not being properly honored because of this. Implement the ignore list that I've posted on your environment and let me know if you still have any stragglers.

Link to post
Share on other sites

Jacob thank you for the response.

I can see this is a possible work around and I will try this out on a machine, but is not a fix for us in most scenarios as we use a third party Antivirus (Trend Micro), which when installed obviously disables MSE, therefore you are unable to add the exclusions to MSE. We can get them added to Trend, but that would not affect the high number of clients already running Trend/Malwarebytes that do not have these exclusions in place.

Do the exclusions need adding to MSE, and the third party antivirus?

Also with MSE, I believe you can only add a single exclusion at a time so this is a long process to add all of those exclusions for each installation. If they already have trend installed, we have to fully uninstall trend, install malwarebytes, add all of the exclusions, then reinstall Trend.

Is there a patch or update fix on its way that you are aware of?

 

 

Link to post
Share on other sites

Mutual whitelisting is always recommended, this is not really a workaround, this is a best practice when running more than one real time protection product.

You can edit this list to be one whole thing you can paste in, just separate each location with a ; character. There is no patch, Microsoft's official stance is that only their product should be used and that they do not support more than one real time protection engine to be ran at any given time.

This particular ignore list applies to MSE and SCEP, not Trend. I am not aware of any conflicts with Trend at this time. Since your Trend disables MSE, I don't think the issue covered in this thread is truly applicable to your situation, I would encourage you to open a support ticket with the business team at corporate-support@malwarebytes.com and have us review a system with you one on one to identify the cause of your login problems.

Link to post
Share on other sites

  • 3 weeks later...
On 22/02/2017 at 6:30 PM, djacobson said:

Mutual whitelisting is always recommended, this is not really a workaround, this is a best practice when running more than one real time protection product.

You can edit this list to be one whole thing you can paste in, just separate each location with a ; character. There is no patch, Microsoft's official stance is that only their product should be used and that they do not support more than one real time protection engine to be ran at any given time.

This particular ignore list applies to MSE and SCEP, not Trend. I am not aware of any conflicts with Trend at this time. Since your Trend disables MSE, I don't think the issue covered in this thread is truly applicable to your situation, I would encourage you to open a support ticket with the business team at corporate-support@malwarebytes.com and have us review a system with you one on one to identify the cause of your login problems.

Could you please explain what the problem is between the two products? Is it not possible to fix this issue with a software update?

My worry is if we add those 78 exceptions to SCEP/MSE what's stopping people renaming ransomware.exe to mbam.exe on PCs without MB and placing it in that path which is excluded from the AV?

Thanks,

Link to post
Share on other sites

Is there any ETA on when this will be resolved.  We have 200 boxes using Trend and Malwarebytes.  About 25% of our boxes lockup for 10 minutes a couple times a day.  The only thing that fixes the lockups is to REMOVE MALWAREBYTES.  I really hate doing this, but I don't see a patch anywhere to address these lockups.  We're pretty pissed.

Link to post
Share on other sites

1 hour ago, mrizos said:

About 25% of our boxes lockup for 10 minutes a couple times a day. 

Make sure the ignore path for mbam.exe and mbamservice.exe in your Microsoft product is pointing to the correct location on all endpoints. The fix is whitelisting Malwarebytes' processes in your Microsoft product, there is nothing we can change within our application to stop MsMpEng.exe's interference.

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.