262

Whenever I tried to copy 4 files into my bin folder, after stopping the main service, I am getting an error with one file (TexteDll). The error is:

Cannot copy TexteDll: The requested operation cannot be performed on a file 
with a user-mapped section open

It may be due to some system locking. Or perhaps another process is using this DLL. When I googled, I found that rebooting the system may resolve this.

Can anybody suggest a cause or solution for this? I inspected the properties of TexteDll (general, version, security, etc). Everything appears normal.

Steve Chambers
  • 37,270
  • 24
  • 156
  • 208
peter
  • 8,158
  • 21
  • 66
  • 119
  • 2
    duplicate of http://stackoverflow.com/questions/1302698/system-io-exception-error-the-requested-operation-cannot-be-performed-on-a-file – Sam Jul 01 '11 at 06:45
  • 14
    there are actually many more 'duplicates' of the question (for example: http://stackoverflow.com/questions/1818076/why-do-i-get-file-is-used-by-another-process-errors-when-i-debug-within-visual) - problem is that every time the root cause is something different. – Maciek Talaska Aug 08 '12 at 14:29
  • 9
    next time try to use "process explorer" from microsoft's site. It has a feature called "find handle". search your file in there and it will show you which process has a handle on that file. Then you can start investigating why that program has that access. BTW, stopping a service does not necessarily mean the executable that hosts service will end. An executable may host multiple services. In a worst case, many .net services that use huge amounts of memory tends to terminate after releasing that memory which happens sometimes minutes after service's stop event. – Erdogan Kurtur Aug 16 '12 at 18:27
  • 3
    Hehehe Visual Studio was locking my DLL. Closed Visual Studio and tried to rebuild the Solution and it worked. – Leniel Maccaferri Jul 03 '13 at 00:39
  • This is obviously a memory conflict. A particular 'instance' of the object has some allocated bit memory mapped, then later finds that the memory (statically?) allocated to it, has already been mapped elsewhere, likely with a different level of system access. – ouflak Jul 17 '14 at 07:53
  • Thanks, Leniel. I had the problem running Unity with a Visual Studio open. I closed Unity since that locks all C#/C dll's. Still one DLL failing to be replaced. I had left the VS solution open, which caused the lock. – Ruud van Gaal Oct 26 '17 at 12:34
  • rebooting solved the issue – user7023213 Oct 24 '18 at 12:34
  • Possible duplicate of [System.IO.Exception error: "The requested operation cannot be performed on a file with a user-mapped section open."](https://stackoverflow.com/questions/1302698/system-io-exception-error-the-requested-operation-cannot-be-performed-on-a-fil) – Facundo Colombier Dec 05 '18 at 03:38
  • If the error is caused by a git diff locking files, that won't be the case with Git 2.23+ (Q3 2019). See [my answer below](https://stackoverflow.com/a/57229750/6309) – VonC Jul 27 '19 at 06:31
  • In my case Oxygen XML may have left a process hanging around accessing the file and the only way I could resolved the problem was rebooting my PC to make sure all processes accessing the file were off. – Guasqueño Aug 24 '21 at 15:04

31 Answers31

194

In my case it was the Explorer that was locking the DLL that was been compiled in the Debug folder... Strange, isn't it?

I found out using a tool called Unlocker.

Had to delete with Unlocker, even when it was saying that there was no lock over the file, and I couldn't delete the folder until I didn't delete that single file...

After that it compiled.

EDIT:

I found out why in my case this was happening. I had the DLL opened in a text editor inside Visual Studio...

Tim
  • 1,814
  • 8
  • 29
  • 41
Daniel Lobo
  • 2,144
  • 1
  • 13
  • 6
  • 35
    I had the dlo open in one of my many visual studio windows open also. Thanks for posting that update. – ptfaulkner Mar 25 '13 at 14:19
  • 3
    Same thing, somehow the danged DLL was open in a text window in the editor. – Harv Apr 10 '13 at 19:07
  • 6
    Full disclosure: the link to "Unlocker" is total spyware. It installs all sorts of toolbars and crap, even if you uncheck all the boxes saying you don't want them. – Tim Aug 20 '15 at 16:10
  • same for me DLL was open in VS. +1 – S Nash Jan 25 '16 at 14:40
  • 11
    Use [Process Explorer](https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx) instread of Unlocker. Once PE is running, go to Find -> Find Handle or Dll and paste the name of the locked file. It will show which process locked it. Kill it if you are sure it's ok to do it and the problem should be solved. – Nikita R. Feb 25 '16 at 20:16
  • In my case, the .dll was being held onto by FxCop. I closed FxCop and it was able to compile. – Tim Nov 09 '16 at 23:21
  • For me, the Services window was the culprit. – xinux Feb 13 '17 at 09:54
  • I unchecked 'read only' on the folder - recursively - and rebooted - that released the file lock and fixed it. – niico Nov 06 '17 at 13:53
  • It was a git diff for me. – Great Scott Aug 06 '18 at 19:20
  • I oppened the dll in vs by mistake and forgot it .. you saved my day. thanks – Mahmoud S. Marwad Dec 06 '20 at 08:34
  • I unloaded my project and reloaded it. Typical jank in VS. – tnk479 Mar 16 '21 at 16:33
  • !!!!!!!!!!!WARNING!!!!!!!!!!!!!!! Please do be careful to download the Unlocker from file hippo, it contains adware and could be dangerous to use. – Reinhard Behrens Apr 20 '21 at 12:16
78

  • Sometimes when you double click on a warning about the referenced assembly version mismatch between two or more projects you forget to close the assembly view window and it stays there among other tabs... so you end up with the assembly being locked by VS itself and it took me quite a lot of time to figure that out :)

    Be careful with the power VS provides ;)

  • Another dummy scenario. Sometimes simply deleting the whole obj folder or just the file warned as the locked one helps out with this crappy error.
Arman
  • 5,136
  • 3
  • 34
  • 36
  • 2
    sorted it for me... I even did a system restart but VS reopened the assembly view window. Closing all tabs did the job. Cheers – Dave Lawrence Feb 26 '14 at 11:45
  • Incredible, thanks for this. Totally shocked it was because I had one of the files open as a tab in VS! – Arbiter Feb 28 '21 at 23:09
42

close all documents on VS and try to rebuild again. If it doesn't work restart VS. This problem is related to lock of DLL files.

cihadakt
  • 3,054
  • 11
  • 37
  • 59
  • 3
    same, some weirdness with VS. restart sorted it for me. – PJUK Dec 31 '13 at 16:09
  • 1
    This worked for me. Strange thing in my particular circumstance. I had executed my exe standalone, outside of the VS environment. Left it running overnight (memory test - it passed), shut it down in the morning, a couple of small code changes, and suddenly couldn't finish my build because of this. Weird how this memory seemed to conflict like this. – ouflak Jul 17 '14 at 07:45
  • Nasty, thanks, an open document was causing the error, what BS! – Brian Ogden Oct 28 '14 at 05:24
  • "Close all Documents" and rebuild actually worked for me ! :o – Antoine Meltzheim Aug 24 '16 at 14:31
21

I had the same issue. How I resolved it was:

  1. Open "Task Manager"
  2. End task "Explorer.exe"
  3. Click "File" --> Create new task -- Type in "explorer.exe" --> OK
  4. Clean my project and it works
Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
user10991945
  • 211
  • 2
  • 2
  • I also had to restart the Explorer process from Task Manager. In my case, I had viewed the "problematic" file in the "Preview" area of the Explorer. This also seems to lock files from time to time without ever releasing them. Closing all Explorer windows did not help. Had to restart the process. – gehho Feb 14 '19 at 16:53
  • Closing "Explorer.exe" was my solution as well. Though in my case I have enabled the option to "Launch folder windows in a separate process" so there is no requirement to relaunch the Explorer shell. – Rock Oct 19 '22 at 18:55
15

Close visual studio, delete bin , debug release folder, and start visual studio project again. that fixed my problem

user2038221
  • 151
  • 1
  • 2
15

I am a developer and do not like apps injected to Registery like Unlocker. I used SysInternals Process Explorer which process locked my dll Find > Find Handle or Dll [Ctrl-F] and killed the process.

guneysus
  • 6,203
  • 2
  • 45
  • 47
  • 2
    Found it was locked by a VS process that did not die when VS was closed. – Yoztastic Feb 22 '17 at 14:03
  • 3
    Even after DevEnv was closed and Task Manager did not show it, Process Explorer showed several instances of DevEnv Suspended. Kill these and it worked. – DeclanMcD Mar 23 '17 at 16:55
  • 2
    This is the most correct answer, since it shows _how_ to find which process is locking the file, rather than just saying "in my case it was due to X". Every developer on Windows would benefit from adding procexp and procmon to their toolbelt! – Matt Wanchap Feb 21 '20 at 05:29
  • This is the right answer! devenv.exe was holding even after exiting, just used `taskkill /pid 1234 /f` – Babu James Aug 07 '23 at 16:49
11

I had same problem and in my case it appeared that existing output file was locked by other application.

You can check which application is locking your output file with OpenedFilesView: http://www.nirsoft.net/utils/opened_files_view.html

bozydar.sz
  • 359
  • 2
  • 12
10

Others have already established that this error is due to another application having a lock on the file. Just wanted to point out that git diff locks files as well until you quit out of it. That's what caused this in my case.

drew.cuthbert
  • 1,005
  • 1
  • 9
  • 21
  • Same issue for me. Forgot I hadn't quit the diff. Unfortunately, I didn't see this answer until I closed a bunch of other windows and saw it was still in a diff. Then was making sure I didn't post a dupe answer so +1 :) – codeMagic Sep 26 '18 at 16:30
  • 1
    @codeMagic Git 2.23 (Q3 2019) will avoid that trap. See [my answer below](https://stackoverflow.com/a/57229750/6309) – VonC Jul 27 '19 at 06:30
8

In my case I had to kill a hanging MSBuild.exe process that was locking the file (it was there even after I closed Visual Studio).

t3chb0t
  • 16,340
  • 13
  • 78
  • 118
8

It has been pointed out in 2016 by Andrew Cuthbert that git diff locks files as well until you quit out of it.

That is still the case for git diff, but it won't be the case with Git 2.23 (Q3 2019), for external diff tools (as reported by Burkart in the comments).

See commit 3aef54e (11 Jul 2019) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit d9beb46, 25 Jul 2019)

diff: munmap() file contents before running external diff

When running an external diff from, say, a diff tool, it is safe to assume that we want to write the files in question.
On Windows, that means that there cannot be any other process holding an open handle to said files, or even just a mapped region.

So let's make sure that git diff itself is not holding any open handle to the files in question.

In fact, we will just release the file pair right away, as the external diff uses the files we just wrote, so we do not need to hold the file contents in memory anymore.

This fixes git-for-windows#1315

Running "git diff"(man) while allowing external diff in a state with unmerged paths used to segfault, which has been corrected with Git 2.30 (Q1 2021).

See commit d668518, commit 2469593 (06 Nov 2020) by Jinoh Kang (iamahuman).
(Merged by Junio C Hamano -- gitster -- in commit d5e3532, 21 Nov 2020)

diff: allow passing NULL to diff_free_filespec_data()

Signed-off-by: Jinoh Kang
Signed-off-by: Junio C Hamano

Commit 3aef54e8b8 ("diff: munmap() file contents before running external diff", Git v2.22.1) introduced calls to diff_free_filespec_data in run_external_diff, which may pass NULL pointers.

Fix this and prevent any such bugs in the future by making diff_free_filespec_data(NULL) a no-op.

Fixes: 3aef54e8b8 ("diff: munmap() file contents before running external diff")

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • As I understand it, these fixes apply to _external_ diff tools only whereas the "integrated" diff on the command line still locks the diffed files. Observed in Git 2.35.1. – Burkart Feb 23 '22 at 09:07
  • @Burkart Thank you for this feedback. I have included your comment in the answer for more visibility. – VonC Feb 23 '22 at 09:14
6

Are you running any Anti-virus software. It's possible that the AV software (or some other piece of software) was reading the file using the file mapping APIs which caused the problem.

Eoin Campbell
  • 43,500
  • 17
  • 101
  • 157
4

None of the solutions posted here worked for me. It was devenv.exe (Visual Studio) locking the file, but if I restarted it, it would re-lock it.

Bizarrely, Windows wouldn't let me Delete the files (to Recycle Bin), but Shift+Delete (permanent delete) worked.

makhdumi
  • 1,308
  • 11
  • 35
3

I had the same problem. Restart did not work for me. There was a process called VBSCompiler was running in task manager. I had to end the process to fix this error.

Nirjhar Vermani
  • 1,215
  • 8
  • 17
3

Deleting the obj folder and rebuilding worked for me

komodosp
  • 3,316
  • 2
  • 30
  • 59
2

Close the Visual Studio and Run it as administrator. It's fixed my problem.

Sanjay Ghinaiya
  • 146
  • 1
  • 5
  • I was getting this error while building a shiny app in rstudio, so many of these answers weren't helpful to me. But I saw this and tried restarting rstudio as administrator, and it worked. Then when I went back to running as user it worked again. – Paul Apr 19 '17 at 18:00
2

The solution for me was to close out of all instances of VS and to kill any hanging devenv.exe processes.

user2338408
  • 182
  • 1
  • 11
1

I was seeing these errors when building Dot Net applications with Ant.

In my case it was our corporate backup software, the Symantec DLO Agent. Stopping it and excluding the directory in my antivirus software and closing Visual Studio seems to work.

Robert Bratton
  • 435
  • 1
  • 5
  • 12
1

in my case deleted the obj folder in project root and rebuild project solved my problem!!!

Ali Rasouli
  • 1,705
  • 18
  • 25
1

Happened to me after I have changed the project target CPU from 'Any CPU' to 'X64' and then back to 'Any CPU'.
Solved it by deleting the Obj folder (for beginners: don`t worry about deleting the obj folder, it will be recreated again in the next compile).

Jonathan Applebaum
  • 5,738
  • 4
  • 33
  • 52
  • Tried many other suggestions, the file was not locked but VS kept saying it was. This was the only one which worked to me. – Cesar Dec 26 '21 at 22:45
1

This is a different one. Seems like it can happen due to a file handle being in use. This is why this answer works, I believe. For me, I had type more project.csproj from the command line, and forgotten I had left it open. So the handle was locked for reading.
Sysinternals has a neat command line tool called handle if you are partial to the command line. You can type handle <partial name of whatever file or folder you want> and it will tell you what program (if any) is using it.

Handle by Sysinternals

dgo
  • 3,877
  • 5
  • 34
  • 47
1

Somehow a simple restart solved the issue for me.

Abdullah Khilji
  • 370
  • 2
  • 8
1

I tried the above solutions but they did not work for me. Few steps that I followed:

  • Closing all VS instances and opening again.
  • Killing build.exe and explorer.exe processes.
  • Deleting bin folder in projects.

What worked for me is - Restarting My Machine.

Another solution:

  • go to the solution folder.
  • check the properties, and remove read-only property if there.
  • click and apply to all the subfolders.
  • open VS again, clean + build solutions.
Rishu Ranjan
  • 494
  • 4
  • 7
0

I encountered this error and it turned out the issue was FxCop was running against my project. I closed FxCop and then I could compile again.

Tim
  • 1,814
  • 8
  • 29
  • 41
0

If it is a web application deleting files in Temporary ASP.NET Files folder could be a solution.

suphero
  • 497
  • 2
  • 8
  • 18
0

If you're using profilers like AQ Time, these may also be locking the file. The solution in this case would be to restart the profiler or simply unload/load the assembly in question from the profiler. For AQ Time I noticed that it's releasing the file after some time, but I can't for the life of me tell what that timeout is. Seems to be random

memory of a dream
  • 1,207
  • 3
  • 23
  • 32
0

None of the above solved this issue.

Someone had one project in my solution set to use x64 CPU in the build configuration. Changing it to Any CPU caused the build to use a new folder. I still don't know what process had (has) a lock on that file.

C.M.
  • 1,474
  • 13
  • 16
0

In my case, the issue was with visual micro on Visual Studio 2019. It was complaining about the \_vm\compile.vmps.xml file. Unable to delete/modify it perhaps. I fixed this issue by deleting the _vm folder in the root directory of the project and rebuilding the solution.

DrMaxB
  • 540
  • 1
  • 3
  • 13
0

In my case, I was trying to publish API to my local IIS, I fixed it by simply deleting the causing file in the IIS target folder and publish the API again, it seemed like it corrupted or something.

Ahmed Elmasry
  • 1
  • 1
0

Happens to me on Window 10, Visual Studio 2022, Visual Basic project. Process Explorer "Find Handle/DLL" shows me 4 lines of devenv.exe locking the file.

Besides killing devenv.exe, I can also fix the issue by simply deleting the folder that contains the locked file (in this case it's bin\Debug). It's strange because I'm not allowed to deleted the locked file, but I can delete the whole folder.

bobt
  • 1
0

In my case there was still an "invisible" instance of VS2022 (devenv.exe) running. It was listed in Task Manager with Status=Suspended but no corresponding window was visible on the taskbar or anywhere else. After killing that process the problem was solved.

user17983115
  • 55
  • 5
-1

My issue was also solved by sifting through the Process Explorer. However, the process I had to kill was the MySQL Notifier.exe that was still running after closing all VS and SQL applications.

JN88
  • 11
  • 1
  • 6