无法对打开了用户映射部分的文件执行请求的操作

Posted 2023-02-15

【中文标题】无法对打开了用户映射部分的文件执行请求的操作

【英文标题】：The requested operation cannot be performed on a file with a user-mapped section open

【发布时间】：2011-06-07 04:46:53

【问题描述】：

每当我尝试将 4 个文件复制到我的 bin 文件夹中时，在停止主服务后，我都会收到一个文件 (TexteDll) 的错误。错误是：

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

这可能是由于某些系统锁定。或者也许另一个进程正在使用这个 DLL。 google了一下，发现重启系统可以解决这个问题。

任何人都可以为此提出原因或解决方案吗？我检查了 TexteDll 的属性（一般、版本、安全性等）。一切看起来都很正常。

【问题讨论】：

与***.com/questions/1302698/…重复

这个问题实际上有更多的“重复”（例如：***.com/questions/1818076/…） - 问题是每次根本原因都不同。

下次尝试使用微软网站的“进程浏览器”。它有一个称为“查找句柄”的功能。在那里搜索你的文件，它会告诉你哪个进程对该文件有句柄。然后您可以开始调查为什么该程序具有该访问权限。顺便说一句，停止服务并不一定意味着托管服务的可执行文件将结束。一个可执行文件可以承载多个服务。在最坏的情况下，许多使用大量内存的 .net 服务往往会在释放内存后终止，这有时会在服务停止事件后几分钟发生。

呵呵呵呵 Visual Studio 锁定了我的 DLL。关闭 Visual Studio 并尝试重新构建解决方案，它成功了。

这显然是内存冲突。对象的特定“实例”映射了一些分配的位内存，然后发现分配给它的内存（静态？）已经映射到其他地方，可能具有不同级别的系统访问。

【参考方案1】：

在我的情况下，我试图将 API 发布到我的本地 IIS，我通过简单地删除 IIS 目标文件夹中的导致文件并再次发布 API 来修复它，看起来它似乎已损坏或其他什么。

【参考方案2】：

就我而言，问题出在 Visual Studio 2019 上的 Visual micro 上。它抱怨 \_vm\compile.vmps.xml 文件。可能无法删除/修改它。我通过删除项目根目录中的_vm 文件夹并重建解决方案来解决此问题。

【参考方案3】：

这是不同的。似乎由于正在使用文件句柄而发生这种情况。我相信这就是this answer 起作用的原因。对我来说，我从命令行输入了more project.csproj，却忘记了我把它打开了。因此，手柄被锁定以供阅读。 如果您偏爱命令行，Sysinternals 有一个名为handle 的简洁命令行工具。你可以输入handle <partial name of whatever file or folder you want>，它会告诉你哪个程序（如果有的话）正在使用它。

Handle by Sysinternals

【参考方案4】：

在我将项目目标 CPU 从“Any CPU”更改为“X64”然后又改回“Any CPU”后发生在我身上。 删除Obj文件夹解决（初学者：不用担心删除obj文件夹，下次编译会重新创建）。

【参考方案5】：

Andrew Cuthbert 在 2016 年一直是 pointed out，git diff 也会锁定文件，直到您退出为止。

Git 2.23（2019 年第三季度）不会出现这种情况。

参见Johannes Schindelin (dscho)commit 3aef54e（2019 年 7 月 11 日）。^{（由 Junio C Hamano -- gitster -- 合并于 commit d9beb46，2019 年 7 月 25 日）}

diff: munmap() 运行外部差异之前的文件内容

当从diff tool 运行外部差异时，可以安全地 假设我们要编写有问题的文件。 在 Windows 上，这意味着不能有任何其他进程持有打开的句柄 说文件，甚至只是一个映射区域。

因此，让我们确保git diff 本身没有持有相关文件的任何打开句柄。

其实我们只是马上释放文件对，因为外部diff使用的是我们刚刚写的文件，所以我们不需要再将文件内容保存在内存中了。

这修复了git-for-windows#1315

---

运行“git diff”^(man)，同时允许外部差异处于用于段错误的未合并路径状态，这已在 Git 2.30（2021 年第一季度）中得到纠正。

参见commit d668518、commit 2469593（2020 年 11 月 6 日）Jinoh Kang (iamahuman)。^{（由 Junio C Hamano -- gitster -- 合并到 commit d5e3532，2020 年 11 月 21 日）}

diff：允许将NULL 传递给diff_free_filespec_data()

^{签字人：Jinoh Kang签字人：Junio C Hamano}

提交3aef54e8b8（“diff:munmap() 运行外部差异之前的文件内容”，Git v2.22.1）在run_external_diff, 中引入了对diff_free_filespec_data 的调用，这可能会传递NULL 指针。

通过将diff_free_filespec_data(NULL) 设为无操作来修复此问题并防止将来出现此类错误。

修复：3aef54e8b8（“diff: munmap() 运行外部差异之前的文件内容”）

【参考方案6】：

以上都没有解决这个问题。

我的解决方案中有一个项目在构建配置中使用 x64 CPU。将其更改为 Any CPU 会导致构建使用新文件夹。我仍然不知道是哪个进程锁定了该文件。

【参考方案7】：

我遇到了同样的问题。我的解决方法是：

打开“任务管理器” 结束任务“Explorer.exe” 点击“文件”-->新建任务--输入“explorer.exe”-->确定 清理我的项目，它可以工作了

【讨论】：

我还必须从任务管理器重新启动资源管理器进程。就我而言，我在资源管理器的“预览”区域中查看了“有问题的”文件。这似乎也会不时锁定文件而不会释放它们。关闭所有资源管理器窗口没有帮助。不得不重新开始这个过程。

【参考方案8】：

我的问题也通过筛选 Process Explorer 得到了解决。但是，我不得不杀死的进程是 mysql Notifier.exe，它在关闭所有 VS 和 SQL 应用程序后仍在运行。

【参考方案9】：

在我的情况下，删除了项目根目录中的 obj 文件夹并重建项目解决了我的问题！！！

【参考方案10】：

删除 obj 文件夹并重建对我有用

【参考方案11】：

此处发布的解决方案均不适合我。它是 devenv.exe (Visual Studio) 锁定文件，但如果我重新启动它，它会重新锁定它。

奇怪的是，Windows 不允许我删除文件（到回收站），但 Shift+Delete（永久删除）起作用了。

【参考方案12】：

我遇到了同样的问题。重新启动对我不起作用。在任务管理器中有一个名为 VBSCompiler 的进程正在运行。我不得不结束这个过程来修复这个错误。

【参考方案13】：

我的解决方案是关闭所有 VS 实例并终止所有挂起的 devenv.exe 进程。

【参考方案14】：

有时当您双击有关引用的警告时 您忘记的两个或多个项目之间的程序集版本不匹配 关闭装配视图窗口，它会停留在那里 选项卡......所以你最终会被VS锁定的程序集 本身，我花了很多时间才弄清楚:)

小心 VS 提供的功能 ;)

另一个虚拟场景。有时只是简单地删除整个 obj 文件夹或仅警告文件，因为锁定的文件有助于解决此问题 糟糕的错误。

【讨论】：

为我排序...我什至重新启动了系统，但 VS 重新打开了程序集视图窗口。关闭所有选项卡完成了这项工作。干杯

难以置信，谢谢。完全震惊，因为我在 VS 中将其中一个文件作为选项卡打开！

【参考方案15】：

如果您使用像 AQ Time 这样的分析器，它们也可能会锁定文件。在这种情况下，解决方案是重新启动分析器或简单地从分析器卸载/加载有问题的程序集。 对于 AQ Time，我注意到它会在一段时间后释放文件，但我一生都无法说出超时是什么。 好像是随机的

【参考方案16】：

其他人已经确定此错误是由于另一个应用程序锁定了该文件。只是想指出git diff 也会锁定文件，直到您退出它。这就是在我的情况下造成这种情况的原因。

【讨论】：

对我来说同样的问题。忘了我没有退出差异。不幸的是，直到我关闭了一堆其他窗口并看到它仍然存在差异时，我才看到这个答案。然后确保我没有发布欺骗答案，所以 +1 :)

@codeMagic Git 2.23（2019 年第三季度）将避免这个陷阱。见my answer below

【参考方案17】：

如果是 Web 应用程序，删除 Temporary ASP.NET Files 文件夹中的文件可能是一种解决方案。

【参考方案18】：

我是一名开发人员，不喜欢像 Unlocker 这样注入 Registery 的应用程序。 我使用 SysInternals Process Explorer 哪个进程锁定了我的 dll Find > Find Handle or Dll [Ctrl-F] 并杀死了该进程。

【讨论】：

发现它被一个VS关闭时没有死的VS进程锁定。

即使在 DevEnv 关闭并且任务管理器没有显示它之后，Process Explorer 仍然显示了几个 DevEnv Suspended 实例。杀死这些，它就奏效了。

这是最正确的答案，因为它显示了如何找到锁定文件的进程，而不是仅仅说“在我的情况下是由于 X”。 Windows 上的每个开发人员都将从将 procexp 和 procmon 添加到他们的工具带中受益！

【参考方案19】：

在我的情况下，我不得不杀死一个正在锁定文件的挂起的MSBuild.exe 进程（即使在我关闭 Visual Studio 之后它仍然存在）。

【讨论】：

你成功了。非常感谢！

【参考方案20】：

在我的情况下，是资源管理器锁定了在 Debug 文件夹中编译的 DLL……很奇怪，不是吗？

我发现使用了一个叫做 Unlocker 的工具。

必须使用 Unlocker 删除，即使它说文件没有锁定，并且我无法删除文件夹，直到我没有删除该单个文件...

然后编译。

编辑：

我发现了为什么会发生这种情况。我在 Visual Studio 中的文本编辑器中打开了 DLL...

【讨论】：

我在许多 Visual Studio 窗口之一中打开了 dlo。感谢您发布该更新。

同样的事情，不知何故，危险的 DLL 在编辑器的文本窗口中打开了。

完全披露：“Unlocker”的链接完全是间谍软件。它会安装各种工具栏和废话，即使您取消选中所有表示您不想要它们的框。

对我来说一样 DLL 在 VS 中打开。 +1

使用Process Explorer 进入解锁器。一旦 PE 运行，转到 Find -> Find Handle or Dll 并粘贴锁定文件的名称。它将显示哪个进程锁定了它。如果您确定可以这样做并且问题应该得到解决，请杀死它。

【参考方案21】：

我遇到了这个错误，结果发现问题是 FxCop 正在针对我的项目运行。我关闭了 FxCop，然后我可以再次编译。

【参考方案22】：

我在使用 Ant 构建 Dot Net 应用程序时看到了这些错误。

就我而言，它是我们的企业备份软件 Symantec DLO Agent。停止它并排除我的防病毒软件中的目录并关闭 Visual Studio 似乎可行。

【参考方案23】：

关闭 Visual Studio 并以管理员身份运行它。它解决了我的问题。

【讨论】：

我在 rstudio 中构建闪亮的应用程序时遇到此错误，因此其中许多答案对我没有帮助。但我看到了这一点，并尝试以管理员身份重新启动 rstudio，它成功了。然后当我重新以用户身份运行时，它又可以工作了。

【参考方案24】：

关闭visual studio，删除bin，debug release文件夹，重新启动visual studio项目。 解决了我的问题

【参考方案25】：

关闭 VS 上的所有文档并再次尝试重建。如果它不起作用，请重新启动 VS。此问题与 DLL 文件的锁定有关。

【讨论】：

相同，VS 有点奇怪。重新开始为我排序。

这对我有用。在我的特殊情况下很奇怪。我已经在 VS 环境之外独立执行了我的 exe。让它在一夜之间运行（内存测试 - 它通过了），早上将其关闭，进行了一些小的代码更改，因此突然无法完成我的构建。奇怪的是，这段记忆似乎是如何冲突的。

讨厌，谢谢，一个打开的文档导致了错误，什么BS！

“关闭所有文档”并重建实际上对我有用！ :o

【参考方案26】：

我遇到了同样的问题，在我的情况下，现有的输出文件似乎被其他应用程序锁定了。

您可以使用 OpenedFilesView 检查哪个应用程序正在锁定您的输出文件： http://www.nirsoft.net/utils/opened_files_view.html

【参考方案27】：

您是否正在运行任何防病毒软件。可能是 AV 软件（或其他一些软件）正在使用导致问题的文件映射 API 读取文件。