Jump to content
Malebox

MBAM keeps locking Visual Studio compiled executable preventing subsequent rebuild and debug

Recommended Posts

Although I've excluded both devenv.exe (Visual Studio 2017) and the executable of my program - every subsequent time I try to debug or recompile my VS project - after the first - it fails as MBAM Service has locked the files and won't release them so they can be replaced by the compiler. To unlock I need to force close the file handle to the executable opened by MBAM. This behavior is quite troubling especially with live debugging and rapid code changes.

Error		Unable to copy file "obj\x86\Debug\bin86.exe" to "bin\x86\Debug\bin86.exe". The process cannot access the file 'bin\x86\Debug\bin86.exe' because it is being used by another process.				
Error		Could not copy "obj\x86\Debug\bin86.exe" to "bin\x86\Debug\bin86.exe". Exceeded retry count of 10. Failed.		

Turns out I not only need to add the final path to the executable but the one in the obj\.. as well.
So this means 2 exclusions. If I use the vs hosting process while debugging I also need to add bin86.vshost.exe ... makes 3 exclusions ... and thats just for a SINGLE project.

Apply that to a hundred projects now... and let it sink in.

So from what I observed so far when Visual Studio (or any application in that matter) is added as an exception, then MBAM:

  • will ONLY forego scanning the executable but still scan all files it interacts with -- more secure but UNWANTED APPROACH

Instead I would have expected something like:

  • will NOT scan the executable and IGNORE all operations and child processes spawned by it as well as any file-system access initiated by it -- less secure DESIRED APPROACH (similar to how administrative privileges / elevation and firewall rules are inherited from the initial process)

If allowing that poses too much of a security risk in your opinion - we could have a sort of hardcoded SUPER-WHITELIST that would check for Microsoft digital signatures to verify e.g Visual Studio and stop scanning anything related or accessed by it. It has a ton of child processes too, so excluding every single one of them is also a pain.

Platform: Windows 10 x64 / Visual Studio 2017 / Only MBAM installed with all layers enabled and no other active security suites/AVs.

 

 

Edited by Malebox

Share this post


Link to post
Share on other sites

Hello @Malebox:

Thank you for reporting the system's issue.  The Malwarebytes' staffers/helpers must have good log data for a quality fault analysis to begin so please let them have some fine grain details about the issue.

  1. Please save your work and close all running user applications for your convenience. applications for your convenience.
  2. Please follow the steps within the locked/pinned topic at Having problems using Malwarebytes? Please follow these steps.

  3. In your next reply to your topic, please only attach the three (3) separate files that are developed above: mb-check-results.zip, FRST.txt, and Addition.txt.

Edited by 1PW

Share this post


Link to post
Share on other sites

If you exclude the root build folder (IE: %USERPROFILE%\Documents\Visual Studio 2017\Projects\<PROJECTNAME>) does that solve your issue at all?

Share this post


Link to post
Share on other sites

That would be sub-optimal. What if some malware targets those folders, or some imported project has infected binaries?

It's one thing not to scan stuff accessed by a trusted executable and another thing to ignore everything inside that path.

I see that action as a last resort.

Share this post


Link to post
Share on other sites

I agree, I'm not suggesting you do it permanently, just test if it solves the issue. Helps us narrow the process of what we're flagging (IE: are we flagging part of Visual Studio, or are we flagging the binary you're building)

Share this post


Link to post
Share on other sites

I re-enabled all protection layers again and restarted by request of the VS2017 updater which brought it to the most recent build.

So far I can't reproduce the lock yet but it might be related to prolonged system uptime which in my case can reach a couple of weeks even. I'll keep monitoring its behavior and let you know when it comes up again.

Share this post


Link to post
Share on other sites

Unfortunately it seems uptime is the key. Five days uptime and MBAMService started locking random files that are being written to.

This includes the re-compiled executables. I also noticed it locked external files being written from memory to disk occasionally.

This is something you can't really test in a lab environment and can only be triggered by prolonged heavy PC usage. Restarting is not a solution in the long run.

It's some sort of logic problem in MBAM since it doesn't release the file after it locks it (for scanning or whatever). The locked file is locked in MBAMService indefinitely until I force close the handle to it from Process Explorer.

Just to make it clear - In the past month I haven't used any AV product other than MBAM and it is MBAM's service that locks the files.

Share this post


Link to post
Share on other sites

Hi,

I'm suffering from the exact same issue. I have to use LockHunter to unlock my executable before I can continue. It does not happen all the time, but almost always after debugging and then terminating the application.

Maarten

Share this post


Link to post
Share on other sites

Today MBAM even managed to abort my visual studio update installation by locking the installer bootfiles.

5979efa76b58a_ClipboardImage.png.117e08469639adb213ce9ca132fe5d92.png

Had to unlock them. Delete the folder and run setup again just to proceed.

Only to get an "Update installation failed" after that. Looking at the locked files - no wonder:

5979f1557f382_ClipboardImage(1).thumb.png.b6f065f209703d81b8e317271459b803.png

Closed all handles and finally the update succeeded.

This really needs to be fixed ASAP. Scanning files should not lock them indefinitely like that - ever.

 

Edited by Malebox

Share this post


Link to post
Share on other sites

It seems to be getting worse every day. Every other build gets locked now. Very annoying. It does not matter what I exclude: the file, the folder or the process, the file gets locked anyway.

Maarten

Share this post


Link to post
Share on other sites

I had the very same problem, but I was using C++ Builder on my Windows 7 64-bit PC.  I put that program in my exceptions list and it went away for me.  I also found that if I stopped and restarted MBAMService.exe, that the locks would go away.

HOWEVER, I found out later that MB was locking a LOT of files.  I ran into the same problem tonight just trying to move some files around.  When I checked tonight using Process Explorer, I found that MBAMService.exe had 28,345 handles including 10,000 handles on one file alone!!!!  That is patently ridiculous.  

Malebox has been having his problem since June 20 and has complied with their onerous debugging process.  Others are also complaining.  It seem obvious MB is not going to be much help here, but I have a suggestion and will be trying this myself:   Add a scheduled job that runs at, say, 3AM that executes these two commands

net stop MBAMService

net start MBAMService

I just tried net stop MBAMService from a command line and then I was then immediately able to move my folder around.  The handle count is now 2034.

The MB people should be working harder on this.  Why can't they just run Process Explorer on their machines and when they see MBAMService.exe with 28,345 handles fix this thing themselves?

Share this post


Link to post
Share on other sites

Hi all! If possible, when this happens, can you please follow the directions below to grab a memory dump and either upload it here, or if it's too big, use wetransfer.com to send it to dcollins@malwarebytes.com

  1. Open Malwarebytes and go to Settings -> Protection
  2. Disable the Self Protection option
  3. Download the following Procdump.zip file: Procdump.zip
  4. Right click on procdump.zip and then choose properties
  5. In the window that pops up, click the unblock button near the bottom and then click ok
    This button may not be there, if so, just continue on to the next step
    post-48870-0-83208100-1483064095.png.dc91a336f777687bdc9b61084a827bab.png
  6. Extract procdump.zip
  7. Open the folder where the files were extracted
  8. Right click "5 - mbamservice_memory.bat" and select Run as administrator
    You should see a screen similar to this
    post-48870-0-93620400-1483064132.png.0ed892225769dbde2e6d5d3b42b14e15.png
  9. Wait 10-30 seconds and then the black window should go away
  10. There should be a new file in the folder that ends with .dmp
  11. Right click the DMP file and choose Send to -> Compressed (Zipped) folder
  12. Reply with the dump file or upload the file to wetransfer.com and send it to dcollins@malwarebytes.com

Thanks!

Share this post


Link to post
Share on other sites

I did the above and sent you the dump on 08/02/17.  Any progress?

UPDATE:  I ran into this problem on my wife's machine tonight.  Her machine is a Windows 10 Pro machine recently installed.  Mine is an old Windows 7 Ultimate machine.  I was grabbing some files from my machine using FreeFileSync running on her machine.  Several of the files got locked by MWB.  It was only after I stopped and started MBAMService that I was able to use those files.  

Share this post


Link to post
Share on other sites

No updates yet @brainwizardphd, but we're still researching this to see what we can come up with. If anyone else is experiencing this issue, the logs from the thread below would be a great help

 

Share this post


Link to post
Share on other sites

I have been having the same issue since the end of last month.  Have been using Malwarebytes Premium and Visual Studio 2010 for a number of years without issue.

By the way, this occurs even with the exclusions of "<project root>\bin\Debug\program.exe", "<project root>\obj\Debug\program.exe", and "<project root>" in place.

Thanks!

MBAMService.exe_170810_095911.zip

Edited by fecaleagle
formatting

Share this post


Link to post
Share on other sites
21 minutes ago, dcollins said:

Thanks @fecaleagle. If possible, can you also please grab the logs I mentioned in my post above?

Sure.  The mini-dump was captured during the period from a fresh mbam startup until I was able to reproduce the issue, and the log files were captured when the debug assembly was in a locked state.

Let me know once you've downloaded this, as I'm going to remove it from the post in short order.

<mb-check-results.zip redacted>

Edited by fecaleagle

Share this post


Link to post
Share on other sites
1 minute ago, dcollins said:

Both are downloaded, thank you

Good deal.  It's only an inconvenience at this point, as I basically just have to restart the mbam service every hour or so when doing active development, but it's obviously affecting productivity, and it took half an hour to pin down the culprit initially, so there's that.

Thanks for your prompt response to my first post and the follow-up.  Very much appreciated.

Share this post


Link to post
Share on other sites

Yeah, some of us have ran into this internally as well, but it's hard to reproduce reliably. Our engineers are looking into the multiple memory dumps and logs we've received, so hopefully we'll be able to figure out a solution quickly

Share this post


Link to post
Share on other sites

Although I first experienced this problem doing compilations, it is not a compiler issue.  I was using a Borland compiler.  People just notice it when compiling because they create so many files.  I saw MBAM keeping extraneous handles to files not related to compiling.  

You can see if your MBAM is getting handles by using the handle utility from SysInternals, docs.microsoft.com/en-us/sysinternals/downloads/handle.  Using that I found over 30,000 handles for one file alone.  As I stated above I now restart MBAMService by a scheduled job every day at 2:30 AM.  

I ran into the problem on both my W7 machine and my wife's W10 machine, so I suspect the problem could be very widespread.

Share this post


Link to post
Share on other sites
21 hours ago, brainwizardphd said:

Although I first experienced this problem doing compilations, it is not a compiler issue.  I was using a Borland compiler.  People just notice it when compiling because they create so many files.  I saw MBAM keeping extraneous handles to files not related to compiling.  

You can see if your MBAM is getting handles by using the handle utility from SysInternals, docs.microsoft.com/en-us/sysinternals/downloads/handle.  Using that I found over 30,000 handles for one file alone.  As I stated above I now restart MBAMService by a scheduled job every day at 2:30 AM.  

I ran into the problem on both my W7 machine and my wife's W10 machine, so I suspect the problem could be very widespread.

I don't feel like uptime is a significant factor for me.  I can reproduce this within 30 minutes to an hour after an mbam service restart.

I'm familiar with the handle utility, and it was actually procexp from SysInternals that identified the culprit initially for me.  I'll take a look at the handles just for kicks the next time it locks up today.

Edited by fecaleagle

Share this post


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.

×
×
  • 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.