The requested operation cannot be performed on a file with a user-mapped section open

235
votes

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.

27
windowsdll
duplicate of stackoverflow.com/questions/1302698/… – Sam
there are actually many more 'duplicates' of the question (for example: stackoverflow.com/questions/1818076/…) - problem is that every time the root cause is something different. – Maciek Talaska
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
Hehehe Visual Studio was locking my DLL. Closed Visual Studio and tried to rebuild the Solution and it worked. – Leniel Maccaferri
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

27 Answers

188
votes

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

74
votes

  • 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.
38
votes

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.

13
votes

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

12
votes

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
11
votes

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.

10
votes

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

9
votes

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.

6
votes

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.

6
votes

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

5
votes

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

That won't be the case with Git 2.23 (Q3 2019).

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")

4
votes

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.

4
votes

Deleting the obj folder and rebuilding worked for me

3
votes

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.

2
votes

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

2
votes

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

1
votes

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.

1
votes

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

0
votes

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.

0
votes

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

0
votes

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

0
votes

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.

0
votes

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

0
votes

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

0
votes

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.

0
votes

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.

-1
votes

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.