我已经看到了一些关于使用 Handle 或 进程监视器,但我希望能够在我自己的代码中找到答案(C# )
哪个进程正在锁定文件。
我有一种不舒服的感觉,我将不得不在 win32 API 中进行探索,但如果有人已经做到了这一点并且可以让我走上正轨,我将非常感谢您的帮助。
更新
类似问题的链接
I've seen several of answers about using Handle or Process Monitor, but I would like to be able to find out in my own code (C#)
which process is locking a file.
I have a nasty feeling that I'm going to have to spelunk around in the win32 API, but if anyone has already done this and can put me on the right track, I'd really appreciate the help.
Update
Links to similar questions
发布评论
评论(18)
很久以前,不可能可靠地获取锁定文件的进程列表,因为 Windows 根本不跟踪该信息。支持重新启动管理器 API ,该信息现已被跟踪。
我将采用文件路径并返回锁定该文件的所有进程的
List
的代码放在一起。从有限权限(例如 IIS)使用
此调用访问注册表。如果该进程没有这样做的权限,您将收到 ERROR_WRITE_FAULT,含义
操作无法读取或写入注册表
。您可以有选择地向您的受限帐户授予对注册表必要部分的权限。不过,让您的受限访问进程设置一个标志(例如在数据库或文件系统中,或者通过使用进程间通信机制,如队列或命名管道)并让第二个进程调用重新启动管理器 API 会更安全。向 IIS 用户授予非最低权限是存在安全风险的。
Long ago it was impossible to reliably get the list of processes locking a file because Windows simply did not track that information. To support the Restart Manager API, that information is now tracked.
I put together code that takes the path of a file and returns a
List<Process>
of all processes that are locking that file.Using from Limited Permission (e.g. IIS)
This call accesses the registry. If the process does not have permission to do so, you will get ERROR_WRITE_FAULT, meaning
An operation was unable to read or write to the registry
. You could selectively grant permission to your restricted account to the necessary part of the registry. It is more secure though to have your limited access process set a flag (e.g. in the database or the file system, or by using an interprocess communication mechanism such as queue or named pipe) and have a second process call the Restart Manager API.Granting other-than-minimal permissions to the IIS user is a security risk.
这个问题有一个原始答案,距今已有 7 年多了。该代码保存在 https://gist.github.com/ieb/2290426
如果您出于某种原因需要使用 Windows XP,则此旧版本可能适合您。
更好的答案是如何检查文件锁定?
我在下面复制了 Eric J 的答案(添加了
using
语句,以及类和方法名称以匹配此处的旧代码)请注意,对此答案的注释可能不正确-日期。用户“Walkman”正在进行研究以改进旧代码,因为在某些情况下重新启动管理器不会列出所有锁定。请参阅 Github 存储库: https://github.com/Walkman100/FileLocks
使用如下:
代码:
This question had an original answer that is now over 7 years old. That code is preserved at https://gist.github.com/i-e-b/2290426
This old version might work for you if you need to use Windows XP for some reason.
A much better answer is at How to check for file lock?
I've replicated Eric J's answer below (with
using
statements added, and class & method names to match the old code that was here) Please note that the comments to this answer may be out-of-date.Research by user 'Walkman' is ongoing to improve the older code, as there are some conditions where the Restart Manager does not list all locks. See Github repo: https://github.com/Walkman100/FileLocks
Use like:
Code:
从 C# 调用 Win32 非常复杂。
您应该使用工具Handle.exe。
之后,您的 C# 代码必须如下所示:
It is very complex to invoke Win32 from C#.
You should use the tool Handle.exe.
After that your C# code have to be the following:
handle.exe
的好处之一是您可以将其作为子进程运行并解析输出。我们在部署脚本中执行此操作 - 就像魅力一样。
One of the good things about
handle.exe
is that you can run it as a subprocess and parse the output.We do this in our deployment script - works like a charm.
我在这里找到的代码,
https://vmccontroller.svn.codeplex.com/svn/VmcController/VmcServices/DetectOpenFiles.cs< /a>
对我来说比 Iain 提供的代码好得多。伊恩的代码似乎正在获取自己的锁。这是我对上面代码稍加修改的版本,修改为返回锁定文件的字符串路径而不是 FileSystemInfo 对象,
The code I found here,
https://vmccontroller.svn.codeplex.com/svn/VmcController/VmcServices/DetectOpenFiles.cs
Works for me much better than the code provided by Iain. Iain's code seemed to be acquiring a lock of its own. Here is my slightly modified version of the code above modified to return the string path of the files locked instead of the FileSystemInfo object,
不是很简单,但在 Windows Vista 及更高版本上,您可以使用 重新启动 Manager API 以查看谁在使用文件。 Internet Explorer 缓存设置 包含有关使用它来检测哪个进程打开了
iexplore.exe
的详细信息。省略很多细节:
Not very straightforward, but on Windows Vista and above you can use the Restart Manager APIs to see who is using a file. Internet Explorer caches settings includes details on using this to detect which process has
iexplore.exe
open.Omitting a lot of detail:
我对 stefan 的解决方案有疑问。下面是一个修改后的版本,看起来效果很好。
更新
如果您只想知道哪个进程正在锁定特定的 DLL,您可以执行并解析
tasklist /m YourDllName.dll
的输出。适用于 Windows XP 及更高版本。请参阅这是做什么的?任务列表 /m "mscor*"
I had issues with stefan's solution. Below is a modified version which seems to work well.
UPDATE
If you just want to know which process(es) are locking a particular DLL, you can execute and parse the output of
tasklist /m YourDllName.dll
. Works on Windows XP and later. SeeWhat does this do? tasklist /m "mscor*"
句柄,来自 Windows Sysinternals。这是 Microsoft 提供的免费命令行实用程序。
您可以运行它并解析结果。
Handle, from Windows Sysinternals. This is a free command-line utility provided by Microsoft.
You could run it, and parse the result.
这适用于被其他进程锁定的 DLL。例如,此例程不会发现文本文件被文字处理锁定。
C#:
VB.Net:
This works for DLLs locked by other processes. This routine will not find out for example that a text file is locked by a word process.
C#:
VB.Net:
以下内容是根据 Iain Ballard 的代码转储生成的。它损坏:当您检索句柄名称时,它偶尔会锁定。此代码不包含该问题的任何解决方法,并且 .NET 留下了几个选项:Thread.Abort 无法再中止当前位于本机方法中的线程。
因此,根据该免责声明,以下是检索句柄的代码,该代码已适应在 32 位和 64 位模式下工作(除了偶尔的锁定):
The following was produced based on Iain Ballard's code dump. It is broken: it will occasionally lock up when you retrieve the handle name. This code doesn't contain any work-arounds for that issue, and .NET leaves few options:
Thread.Abort
can no longer abort a thread that's currently in a native method.So, with that disclaimer, here is the code to retrieve handles which has been adapted to work (apart from the occasional lock-up) both in 32 and 64 bit modes:
这可能是无关紧要的,如果是的话,请有人发表评论,但我之前在资源管理器中使用过一种解决方法来绕过文件锁。
如果一个文件被一个已经死亡的进程锁定,Windows通常不会让你删除它,但如果你在其他地方创建了一个同名的新文件,将其移动到该文件夹就会成功。然后您可以删除新文件,一切顺利。
要将其用于您的应用程序,您必须能够读取该文件并将其保存在内存中,然后再删除旧文件后将其写回。
也许会有帮助,也许不会,但值得尝试。
This is probably irrelevant and if it is please someone comment but there was a work-around I've used in explorer before to get around file locks.
If a file was locked by a process that had died Windows often wouldn't let you delete it but if you created a new file of the same name somewhere else, moved it to the folder it would succeed. You could then delete the new file and all was well.
To use this for your app you'd have to be able to read the file and hold it in memory before you did this then you write it back out after you'd got rid of the old one.
Maybe it will help, maybe not but it's worth trying.
尝试Unlocker。如果您尝试删除被另一个进程锁定的文件,它将列出锁定该文件的进程。然后,您可以通过关闭这些进程来解锁该文件。
Try Unlocker. If you try and delete the file that is locked by another process, it will list the process(es) that have the file locked. You can then unlock the file by shutting down those processes.
或者
or
我相信您需要在内核模式下运行的代码才能完全回答这个问题(但我还没有查看重新启动管理器 API)。
您可以枚举所有进程及其模块 - 因此,如果您要查找的文件是一个模块(DLL、EXE、OCX...),那么您就可以开始了。但如果它是一个文本文件,则您必须查看内核句柄表,而您在用户模式下无法看到该表。 Handle.exe 有一个内核驱动程序来执行此操作。
I believe that you need code running in kernel mode to completely answer the question (but I haven't looked at the restart manager API).
You can enumerate all processes and their modules - so if the file you're looking for is a module (DLL, EXE, OCX...), you're good to go. But if it's a text file for example, you have to look at the kernel handle table which you cannot see from user mode. Handle.exe has a kernel driver in order to do that.
使用 dotnet core (net6) 我通过使用 win32重启管理器(正如其他人也提到的)。然而,一些链接的文章包含导入 DLL 并调用它们的详细代码。
找到由 用于终止锁定文件的进程的应用程序后github.com/meziantou" rel="nofollow noreferrer">meziantou。我发现他发布了 win32 dll 的 .Net 包装器(包括重新启动管理器)。
利用他的工作,我能够使用以下代码解决这个问题:
Using dotnet core (net6) I solved this problem by using the win32 restart manager (as others have also mentioned). However some of the linked articles have elaborate code importing DLLs and calling those.
After finding an app to kill processes that lock a file written by meziantou. I found out that he publishes .Net wrappers for win32 dlls (including the restart manager).
Leveraging his work, I was able to fix this problem with the following code:
你绝对不需要在内核模式下运行(!!!)
这是自 Windows 95 以来的 Win32 常见问题解答(!)(在 C、Google 组、Win32 中):当然是从用户模式读取句柄表,并从文件句柄获取 PID ...
You absolutely don't need to run in Kernel mode (!!!)
It's a Win32 FAQ since Windows 95 (!) (in C, Google groups, Win32) : read the handle table, from User mode of course, and get the PID from the File handle ...
我重写了解决方案中的
GetProcessesLockingFile()
方法。该代码不起作用。例如,您有一个文件夹
“C:\folder1\folder2”
和folder2 中的一个进程(process1)。如果进程正在运行,GetProcessesLockingFile()
将返回"C:\folder1\folder2"
。所以条件if (files.Contains(filePath))
=>if ("C:\folder1\folder2".contains("C:\folder1\folder2\process1"))
从来都不是真的。所以这是我的解决方案:
或者使用字符串参数:
I rewrote the
GetProcessesLockingFile()
method in the solution. The code was not working.For example, you have a folder
"C:\folder1\folder2"
and a process in folder2 (process1). If the process was running,GetProcessesLockingFile()
was returning"C:\folder1\folder2"
. So the conditionif (files.Contains(filePath))
=>if ("C:\folder1\folder2".contains("C:\folder1\folder2\process1"))
was never true.So this is my solution:
Or with a string parameter:
使用 linq 更简单:
simpler with linq: