在什么情况下系统进程（PID 4）保留打开的文件句柄？
我在 Windows 服务器上运行的应用程序使用 Jet/Access 数据库。由于某些原因，大约每两周数据库文件就会被系统进程锁定（PID 4，似乎已修复）
经过一番谷歌搜索后，我发现其他一些用户的文件被该特殊进程锁定，但文件不同（当然）。
- 系统进程保留打开文件句柄的一般原因是什么？
- 我的应用程序是造成这种锁定情况的原因吗？
- 所有句柄都是由系统进程隐式打开的吗？我可以想象，在进程崩溃后，句柄可能仍然打开，并且系统进程以某种方式取得该句柄的所有权。
- 我可以在我的应用程序中做一些事情来防止这种情况发生吗？
My application running on a Windows server makes use of a Jet/Access database. For some reasons around every two weeks that database file gets locked by the System process (PID 4, seems to be fixed)
After some googling I found some other users having their files locked by that special process, but different files (of course).
- What's the general reason for the System process to keep an open file handle?
- Is my application the cause for this locking situation?
- Are all handles implicitly opened by the System process? I could imagine that after a process has crashed, the handle may still be open and the System process somehow takes owernship of that handle.
- Can I do something in my application to prevent it from happening?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
通过共享访问的文件将被系统进程（PID 4）锁定。
尝试打开
compmgmt.msc-> 系统工具 -> 共享文件夹 -> 打开文件以查看锁定的文件是否列在其中另请参阅sysinternals 论坛以获取复制此内容的方法。
并非所有应用程序都会在打开文件时锁定文件，但 Excel 会锁定文件。不知道Access是否也有同样的功能...
Files accessed through a share will be locked by the system process (PID 4).
Try opening
compmgmt.msc-> System Tools -> Shared Folders -> Open Files to see if the locked file is listed thereSee also the sysinternals forum for a way to replicate this.
Not all applications lock files when they are opened, Excel however does. I don't know if Access does the same...
这是我发现的另一个可能的原因：
Windows 7 中存在错误，Windows Server 2008 中也可能存在错误（可能仅限 64 位版本）。当您禁用应用程序体验服务时，它会出现并导致与中所述相同的问题的问题。
重新启用此服务已经为我解决了这个问题。
更多信息此处 为什么会导致问题。
似乎相关的其他 SO 问题列表：
Here's another possible cause I've found:
There is a bug in Windows 7 and likely in Windows Server 2008 (possibly 64bit versions only). It surfaces when you disable Application Experience service and causes the same problems as described in the question.
Re-enabling this service has fixed this problem for me.
A bit more info here as to why it's causing a problem.
List of other SO questions which seem to be related:
在我看来，这听起来像是手柄泄漏的驱动程序级别问题。
如果您正在运行防病毒软件包，请尝试升级、禁用（暂时！）或切换到其他品牌。
This sounds to me like a driver-level issue with a leaky handle.
If you're running an anti-virus package try upgrading, disabling (temporarily!) or switching to a different brand.
这可能是从远程计算机到共享文件夹的延迟会话。如果是这种情况，可以从命令行解锁：
It may be a lingering session from a remote computer to a shared folder. If that's the case, it can be unlocked from the command line:
对我来说，它是“Windows Defender”（防病毒软件）。我将 Visual Studio 构建文件夹从 Windows Defender 检查的文件夹列表中排除，问题就消失了。 （Visual Studio 无法构建 EXE 文件，PID 4 正在锁定它以检查 virii）
For me, it was "Windows Defender" (anti-virus). I excluded my Visual Studio build folders from Windows Defender's list of folders it checks, and the problem went away. (Visual Studio wasn't able to build to the EXE file, PID 4 was locking it to check for virii)
您的服务器是否设置为执行定期文件备份？
如果是这样，备份是否作为系统运行，也许在发生冲突时提示锁定文件？
Is your server set up to perform periodic file backups?
If so, is the backup running as System, perhaps prompting the locked file when you get a conflict?
对我来说，我必须用大锤敲击它。在文件夹所在的驱动器上 Chkdsk /f 修复了该问题。谨慎使用。
For me I had to hit it with a sledgehammer. Chkdsk /f on the drive where the folder was located fixed it. Use with caution.
检查每个文件夹和子文件夹的安全设置。确保系统不会自动创建不允许任何人删除文件的特殊权限设置。显然，出于某种奇怪的原因，操作系统创建了一个奇怪的特殊权限设置来保护文件不被删除。
Check the security settings for each folder and subfolders. Make sure that the system did not just automatically create a special permissions setting which will not allow anyone to delete the file. Apparently for some odd reason the OS creates a weird special permission setting that protects the file from being deleted.