Jump to content

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
Link to post
Share on other sites

  • Replies 53
  • Created
  • Last Reply

Top Posters In This Topic

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

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.

Link to post
Share on other sites

  • 4 weeks later...

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.

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
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?

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!

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.  

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

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.

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
Link to post
Share on other sites

Guest
This topic is now closed to further replies.
  • 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.