[visual-studio] Error: Cannot access file bin/Debug/... because it is being used by another process

When I debug my project, I get following error:

"Unable to copy file "obj\Debug\My Dream.exe" to "bin\Debug\My Dream.exe". The process cannot access the file 'bin\Debug\My Dream.exe' because it is being used by another process."

Using Process Explorer, I see that MyApplication.exe was out but System process still uses it although I stopped debug before. Whenever I change my code and start debug it is going to happen. If I copy project to USB and debug, it runs OK.

Why? How can I fix this error?

I use Window 7 Professional. With Xp I have never got this error.

The answer is


Worked for me. Task Manager -> Name of project -> End task. (i had 3 same processes with my project name);

VS 2013; Win 8;


See my answer here if you're having this problem while running unit tests. Answer copied below:

Building upon Sébastien's answer, I added a pre-build step to my test project to automatically kill any vstest.* executables still running. The following pre-build command worked for me:

taskkill /f /im vstest.*
exit 0

The exit 0 command is at the end to prevent build failure when there are no vstest.* executables running.


I have run to this same issue, and what I found is there are actually running mulitple Windows form application in the background. It happens when your application has two forms and you close the 2nd form which is not your main form so the application will not totally exited.

I usually run my application

  • through its exe or
  • run without debugging

Solution is close the other instance of Windows form application. This is one way to always close your application instance.


I solved this problem..

near the debug you see drop down menu with some configuration. Default there was Any CPU. Select x86 and run the program it will work. If x86 not there go to configuration manager and add the x86


Close VisualStudio, ctrl-alt-delete, select Task Manager, find and end all MSBuild processes - VisualStudio basically has a pretty severe bug where it loses control of its debugger and the debugger maintains a lock on the .pdb file in the debug/bin folder. After you end all the MSBuild (debugger) processes, delete the /debug/bin folder and reopen your solution in Visual Studio. You're good to go now. Microsoft needs to fix this crap.


I understand this is an old question. Unfortunately I was facing the same issue with my .net core 2.0 application in visual studio 2017. So, I thought of sharing the solution which worked for me. Before this solution I had tried the below steps.

  1. Restarted visual studio
  2. Closed all the application
  3. Clean my solution and rebuild

None of the above steps didn't fix the issue.

And then I opened my Task Manager and selected dotnet process and then clicked End task button. Later I opened my Visual Studio and everything was working fine.

enter image description here


I've had this error crop up on me before, even in Visual Studio 2008. It came back and more prevalent in Visual Studio 2012.

Here is what I do.

Paste this in the troublesome project's pre-build event:

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

Run taskmanager.
Locate netcore and delete it.
You can then delete the file manually or by running Clean.


Make sure that any previous run of the application (for example, start without debugging option) is actually stopped. I was working on a WPF application, started without debugging and had it minimized when I kept getting the error. After closing the application VS behavior got back to normal.


At least in my case I've noticed that visual studio 2012 was creating at least two msbuild.exe ghost processes, which did not perish after build. These zombies apparently are causing file locks to appear.

Killing msbuild.exe's is one time solution, it needs to be done per build basis.

But then I've figure out that I could disable parallel build once and for all - went into Tools > Options > Projects and Solutions > Build and Run > "maximum numbers of parallel project builds" - by default it has value of 8, I've switched to 1. Works like charm.

Of course builds are bit slower now, but better safe than sorry. At least for this particular small project I did not need more than one build thread.


[Solved] Error: Cannot access file bin/Debug/… because it is being used by another process:

I am approaching that you get this error while you was trying to run two windows form one after another such as first loading a form then after sometimes it will automatically disappear and the second form loaded onto the screen.

Basically, you need to close your first form which is running in the background and the main reason behind this error.

To close the first form you have to add these two lines of code in the second form load event handler.

    Form1 form = new Form1();
    form.Close();

This will solve the error perfectly.


I've found the quickest way without closing forms or restarting VisualStudio is go to the project's compile page and click "Advanced Compile Options..." button. Then make any change to one of the options (say, changing Generate Debug Info from Full to pdb-only), then click OK. It works every time and will have to do until MS fixes this bug (I've never had this problem until I switched from VS2012 to VS2013)

Another note, if you can't clean the project or solution, it won't build. The files are definitely locked by VS (not a antivirus problem, at least not in my case)


My problem was dotnet got hung up and whenever VS would try to make a new dll, or access an old one, the dotnet process would latch onto the dll and stop visual studio from cloning the dll. Solution is just to end all dotnet tasks in task manager(it will only actually remove the dead one, if you are trying to end one and it won't shut down, that means it's working).


I tried all these suggestions as well as other suggestions found elsewhere and the only thing that worked for me was restarting my computer. Then I did a clean solution followed by rebuilding. I am using Visual Studio 2013 for reference.


In my case was that I have enable "Show All Files". Visual Studio 2017


Pre build command

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)

Helped


i found Cody Gray 's answer partially helpful, in that it did direct me to the real source of my problem which some of you may also be experiencing: visual studio's test execution stays open by default and maintains a lock on the files.

To stop that predominantly useless behaviour, follow the instructions from https://connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0-50727-1-rtmrel

Uncheck Test menu -> Test Settings -> "Keep Test Execution Engine Running"


I had the same issue in Visual Studio 2013. I'm not sure what caused this for my project, but I was able to fix it by cleaning the solution and rebuilding it.

  1. Build > Clean Solution
  2. Build > Rebuild Solution

I have been plagued by this issue in Visual Studio 2017. It started about two or three weeks ago, and has severely eaten into my productivity. Clean and Rebulid haven't worked; even restarting my machine doesn't do the job.

One way to deal with the issue is to clean the offending assembly, and to build (as opposed to rebuild) the project you want to run immediately afterwards. This works about 30% of the time.

However, probably the most reliable solution I've found is to open a Developer Command Prompt, and use msbuild directly. I've been doing this for the last three days, and so far the problem hasn't happened once.


Computer (right-click) -> manage -> Service & Application -> service -> Enable Application experience

Worked For me!


One simple solution is you go to bin\Debug folder, delete all the files in that folder, then rebuild. If it doesn't work, close Visual Studio then go to bin\Debug folder using file explorer, on the left coner, click on File> Open Command Prompt> Open Command Prompt as Administrator > Enter this command "DEL /F /Q /A *" > then rebuild


This is pure speculation, and not an answer.

However, I have been having this problem for a while.

I came after a time to suspect an interaction between VS and my AV precautions.

After some playing, it seems that it may have gone away when I modified my antivirus so that everything under the

C:\Users[username]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies

folder was not included in the real-time protection.

It looks as if the build actually writes the DLL here first, then copies it to the final build location.


It could be too late. But, I encountered similar problem and in my case the project had self reference. Hence, deleting it from the References worked like a charm!!!


Recently I've been in a trouble with Visual Studio 2012 with same error description: "The process cannot access the file because it is being used by another process..."

To fix this first of all you need to understand the application which still use it. I've shutdown all processes like "MSBuild" and "MSBuild host". But this is not enough. If you have installed "Code Contracts" and turned on then it sometimes takes your DLLs for checking and hanging up on this operation.

So, you need to stop all processes of "CCCheck.exe" and that's all.

Finally, to understand that process is using your DLL you always may try to just Delete "obj" folder in your File Manager and this operation will fail, you may see the "Message Window" with description of the hanging operation. Also, as a variant, you can try to use "Sys Internals Suite" application.


I have faced the same issue, but none of the answers above helped me! I just simply closed my Visual Studio 2017 then re-run it, and It worked!


I have opened a separate question regarding VS 2017 that had a similar behavior after one update. The problem seemed to be generated by the antivirus program although.

I have added the bin folder to the antivirus exclude list, restarted the machine and now it seems to work.


Another kludge, ugh, but it's easy and works for me in VS 2013. Click on the project. In the properties panel should be an entry named Project File with a value

(your project name).vbproj

Change the project name - such as adding an -01 to the end. The original .zip file that was locked is still there, but no longer referenced ... so your work can continue. Next time the computer is rebooted, that lock disappears and you can delete the errant file.


Examples related to visual-studio

VS 2017 Git Local Commit DB.lock error on every commit How to remove an unpushed outgoing commit in Visual Studio? How to download Visual Studio Community Edition 2015 (not 2017) Cannot open include file: 'stdio.h' - Visual Studio Community 2017 - C++ Error How to fix the error "Windows SDK version 8.1" was not found? Visual Studio Code pylint: Unable to import 'protorpc' Open the terminal in visual studio? Is Visual Studio Community a 30 day trial? How can I run NUnit tests in Visual Studio 2017? Visual Studio 2017: Display method references

Examples related to debugging

How do I enable logging for Spring Security? How to run or debug php on Visual Studio Code (VSCode) How do you debug React Native? How do I debug "Error: spawn ENOENT" on node.js? How can I inspect the file system of a failed `docker build`? Swift: print() vs println() vs NSLog() JavaScript console.log causes error: "Synchronous XMLHttpRequest on the main thread is deprecated..." How to debug Spring Boot application with Eclipse? Unfortunately MyApp has stopped. How can I solve this? 500 internal server error, how to debug

Examples related to projects-and-solutions

Error: Cannot access file bin/Debug/... because it is being used by another process visual c++: #include files from other projects in the same solution ASP.NET Web Site or ASP.NET Web Application? How can I rename a project folder from within Visual Studio? What are the various "Build action" settings in Visual Studio project properties and what do they do?

Examples related to locked-files

Error: Cannot access file bin/Debug/... because it is being used by another process