系统进程（PID 4）在什么情况下会保留打开的文件句柄？答案

【问题标题】：Under which circumstances does the System process (PID 4) retain an open file handle?系统进程（PID 4）在什么情况下会保留打开的文件句柄？
【发布时间】：2010-11-20 13:45:38
【问题描述】：

我在 Windows 服务器上运行的应用程序使用 Jet/Access 数据库。由于某些原因，数据库文件大约每两周被系统进程锁定一次（PID 4，似乎已修复）

经过一番谷歌搜索后，我发现其他一些用户的文件被该特殊进程锁定，但文件不同（当然）。

系统进程保持打开文件句柄的一般原因是什么？
我的应用程序是导致这种锁定情况的原因吗？
系统进程是否隐式打开了所有句柄？我可以想象，在进程崩溃后，句柄可能仍处于打开状态，并且系统进程以某种方式接管了该句柄。
我可以在我的应用程序中做一些事情来防止它发生吗？

【问题讨论】：

标签： winapi file locking handle

【解决方案1】：

通过共享访问的文件将被系统进程（PID 4）锁定。

尝试打开compmgmt.msc -> 系统工具 -> 共享文件夹 -> 打开文件查看锁定的文件是否列在那里

另请参阅the sysinternals forum 了解复制此内容的方法。
并非所有应用程序在打开文件时都会锁定文件，但 Excel 会。我不知道 Access 是否也这样做...

【讨论】：

这正是我的问题。用户正在通过 unc 路径向远程计算机运行可执行文件，即使在应用程序自行关闭后，远程计算机上的句柄仍保持打开状态。使用 sysinternals 中的 psfile 和 handle.exe 超级容易排除故障。
你是最好的，我尝试了许多其他解决方案，但都没有成功。谢谢
这行得通。使用 sysinternal 的 handle 或 procexp 无法关闭文件，尽管他们确实告诉我问题出在哪里，以便我能够找到这个答案。当我通过 Hyper-V 在 Windows 上运行 docker 时，发生了我的问题。在 docker 中运行的服务器创建了一个文件，该文件随后被system 进程锁定。谢谢你的回答。
天哪，非常感谢这个。它看起来非常简单和容易，直到它发生在 HA 生产环境中锁定事情。我现在需要“文件删除专家”徽章吗？

【解决方案2】：

这是我发现的另一个可能原因：

Windows 7 中存在错误，并且可能在 Windows Server 2008 中（可能仅限 64 位版本）。当您禁用 Application Experience 服务时，它会出现并导致与问题中描述的相同的问题。

重新启用此服务已为我解决了此问题。

更多信息 here 为何会导致问题。

似乎相关的其他 SO 问题列表：

【讨论】：

+1 这对我有用，而且我没有运行任何防病毒软件，所以这真的很奇怪。
我的天哪，怎么会发现 Application Experience 对此负责？一定是一个幸运的家伙。非常感谢，我终于可以再次在这台电脑上工作了！
@MahmoudAl-Qudsi 不确定 OP，但我个人发现很难：经过长时间的调整，我禁用了大量的 Windows 服务，Steam（游戏应用程序）无法更新。它抱怨正在使用的文件。如果我没记错的话，Process Explorer 显示了有问题的文件正在被 explorer.exe 或 System 使用，我觉得这很奇怪。我最终重置了服务配置，问题就消失了。从那以后，我再次禁用它们，一个接一个，直到找到罪犯：/.
我已经给自己写了一张便条，永远不要再禁用此服务。更好的是，我可能不应该为此接触任何 Microsoft / Windows 服务！我很高兴我偶然发现了您的答案，许多其他替代解决方案都没有导致任何结果，或者其他一些场景只是稍微偏离了特定错误/进程/服务占用文件的情况。

【解决方案3】：

在我看来，这听起来像是一个带有泄漏句柄的驱动程序级问题。

如果您正在运行防病毒包，请尝试升级、禁用（暂时！）或切换到其他品牌。

【讨论】：

【解决方案4】：

这可能是从远程计算机到共享文件夹的延迟会话。如果是这种情况，可以从命令行解锁：

net session /delete

【讨论】：

我有点担心运行这个命令，因为我害怕副作用。我首先运行net session，它报告了一个连接。然后我运行该命令，它会提示它杀死的每个会话。

【解决方案5】：

您的服务器是否设置为执行定期文件备份？

如果是，备份是否以系统方式运行，可能在发生冲突时提示锁定文件？

【讨论】：

任何进程如何作为系统进程运行？可以肯定的是，我说的不是 SYSTEM 用户，而是 PID=4 的 System 进程。
发布这篇文章时，这条规则还没有很好地确立。如果您进行了编辑，您可能会获得挖掘机徽章。 ;)

【解决方案6】：

对我来说，它是“Windows Defender”（防病毒）。我从它检查的 Windows Defender 的文件夹列表中排除了我的 Visual Studio 构建文件夹，问题就消失了。（Visual Studio 无法构建到 EXE 文件，PID 4 将其锁定以检查 virii）

【讨论】：

【解决方案7】：

对我来说，我不得不用大锤击打它。文件夹所在的驱动器上的 Chkdsk /f 修复了它。谨慎使用。

【讨论】：

【解决方案8】：

检查每个文件夹和子文件夹的安全设置。确保系统不只是自动创建一个不允许任何人删除文件的特殊权限设置。显然出于某种奇怪的原因，操作系统创建了一个奇怪的特殊权限设置来保护文件不被删除。

【讨论】：