Jump to content

Recommended Posts

I clean installed this version on Windows 10 x 32 1703 15063.250. Defender with all recommended exclusions.

Seemed to work, then I tried starting Chrome, IE, Edge and Firefox in rapid succession, whilst randomly turning off/on various MB protection layers. IE and Chrome crashed.

The issues from the event log are attached, as are MB logs.  All seem to be related to mbae.exe.

I should add that I haven't installed MB for a while, I've been waiting for the problems to be fixed. So I don't know if previous versions would also exhibit these issues.

 

 

events.txt

MBAMSERVICE.zip

Link to post
Share on other sites

Hello @John A:

The MBAMSERVICE.LOG, within the MBAMSERVICE.zip archive, seems to document the system is still running MB3 v3.1.0.1716 and not the newest Beta version 3.1.1.1722.

Could you also please post the MB-CheckResult.txt report, produced by mb-check-3.0.7.1003.exe, as a helpful cross-check?

Thank you.

Edited by 1PW
Link to post
Share on other sites

Hello @John A:

Please download/run https://downloads.malwarebytes.org/file/mb3_check as this will result in currently using mb-check-3.0.7.1003.exe which is a new and improved reporting tool.  This is what will produce the desired MB-CheckResult.txt report.

Although the system's IE 11 appears to be current, you may wish to use the Google Chrome stable channel update (x86) to v58.0.3029.96 because of the rather obscure 0xc00001a5 exception code.  Staffers may also wish to see the two diagnostic reports from the Farbar Recovery Scan Tool (FRST) when it's convenient for you.

An escalation request to Malwarebytes' staffers has been made and I realize it's very late your time...

Thank you again.

Edited by 1PW
Escalation Request.
Link to post
Share on other sites

FRST reveals many instances of this issue::

Description: Code Integrity determined that a process (\Device\HarddiskVolume2\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\MicrosoftEdgeCP.exe) attempted to load \Device\HarddiskVolume2\Program Files\Malwarebytes\Anti-Malware\mbae.dll that did not meet the Store signing level requirements.

I can PM FRST files to devs if requested

Link to post
Share on other sites
  • Staff

This is caused by anti-exploit.  Due to the way our exploit protection works, by hooking/loading into processes that it protects it can create instability if opening/closing those applications while simultaneously enabling/disabling exploit protection.  Unfortunately it's pretty much just the nature of the beast with such things (this is liable to happen with any DLL that hooks other processes if you try terminating the hooking application while at the same time closing/re-launching the process it hooks into).  It's no different than rapidly starting/stopping a driver.  It just creates instability in the processes in memory, but especially due to the way that exploit protection functions, where it monitors closely a protected process's memory/threads etc., it's pretty much bound to create instability if you switch it on and off while opening/closing processes it protects.

It is of course possible that there could be some sort of fix for it, but my best guess based on how it works is that it's probably doomed to be unstable in circumstances like this.

Link to post
Share on other sites

That makes sense.  I wouldn't normally do that, but when testing I tend push programs around in illogical ways to try to break them. 

Also, this is quite a slow computer I am testing with, with only 2GB ram.

Having said that, it is very easy to bring these failures up.  I would have thought that MB could detect if apps being injected were starting up, and not allow protection layers to be switched, (or not allow the user to quit MB), until those protected apps had launched.

 

Link to post
Share on other sites
  • Staff
1 hour ago, John A said:

That makes sense.  I wouldn't normally do that, but when testing I tend push programs around in illogical ways to try to break them. 

Nothing wrong with that; it's a legitimate QA method :) .

Also, this is quite a slow computer I am testing with, with only 2GB ram.

Having said that, it is very easy to bring these failures up.  I would have thought that MB could detect if apps being injected were starting up, and not allow protection layers to be switched, (or not allow the user to quit MB), until those protected apps had launched.

I think the problem is that as soon as you attempt to execute a protected process the anti-exploit DLL is already in the process of loading so it's essentially starting protection for that app.  So when terminating exploit protection at the same time it most likely creates a race condition where the DLL is in the process of loading but hasn't completed the loading/injection process yet and then gets interrupted by the termination command from the main anti-exploit driver/service so the partially loaded anti-exploit DLL is already attached to the new process(es) and then the plug gets pulled, resulting in corruption of the protected process(es)'s memory space, thus the application crashes.  The issue is that when a DLL is injected into a process it essentially becomes a part of that process in memory so removing the DLL from the memory space of that process can be tricky and very finicky so if things don't happen just right, the process's thread gets corrupted and *boom* crash city.

 

I placed my responses/comments in bold blue italics in the above quote of your post (the new forum software makes creating multiple quote boxes like we used to and replying inline quite difficult and I haven't figured out how to get it to format correctly yet).

Link to post
Share on other sites

Thanks for that detailed explanation.

So could these conflicts be significantly reduced if Malwarebytes liaised with the user in the following cases?

Scenario 1 (more important):
The user attempts to switch the exploit protection layer off, or tries to quit Malwarebytes when the exploit layer is on, and one or more of the protected apps are running
Action:
Warn the user to close the running apps (eg Edge, Word Firefox) before proceeding, with an override option allowing the user to continue anyway that warns about possible conflicts.

Scenario 2 (less important):
The user attempts to switch the exploit protection layer on, or tries to start Malwarebytes when the exploit layer is on, and one or more of the to-be-protected apps are running
Action:
Warn the user to close the running apps before proceeding, with an override option allowing the user to continue anyway that warns about possible conflicts.

Link to post
Share on other sites
  • Staff

Yes, those are definitely possible, however given the fact that *usually* it doesn't cause any crashes/problems I wouldn't want to pester all of our users with additional steps and/or messages that might alarm them.  Most of the time it doesn't create any issues, and hopefully there are still improvements to be made in the code to either eliminate these circumstances completely, or at least to make it more stable/less likely somehow, assuming that's possible.

That's just my opinion though, so the product team may see it differently and choose to implement something along the lines of your suggestions.

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.