我有一个 System.Diagnostics.Process
实例,它是通过 Process.GetProcessesByName
创建的。
成功打开进程后,我执行各种操作,例如读取其内存和窗口标题。
此操作基于计时器不断执行,我的意思是 Timer.Elapsed
事件处理程序是流程操作的源。
现在,我注意到我遇到了一个竞争条件,我无法使用我所知道的任何东西来解决它。事情是这样发生的:
timerElapsedEvent(...) {
if (!process.HasExited) {
process.Refresh(); // Update title.
var title = process.MainWindowTitle;
}
}
如果进程正在运行,并且我的代码进入 if
block ,则进程有可能在执行 process.MainWindowTitle
调用之前退出,这会导致异常。
我需要的是一种以某种方式捕获进程的退出事件并使其保持事件状态,直到可以安全地关闭它,而不会使正在监视它的应用程序崩溃,从而确保它将等待 process.MainWindowTitle
关闭之前(或任何其他可以解决此问题的解决方案)。
此外,同时,另一个方法可能正在运行 ReadProcessMemory
,这也会崩溃。
我该如何解决这个问题?
PS:Process.Exit 事件处理程序不起作用,因为它不会在 process.MainWindowTitle
之前触发,它只会在当前指令完成后触发。
我非常确定以某种方式控制退出事件是解决此问题的唯一方法,因为 HasExit 可能随时更改,并不关心在实际调用进程上的方法之前我进行了多少次检查。
PS2:我刚刚意识到这是一个 TOCTTOU 案例,除非我可以控制我打开的进程,否则这是无法解决的,所以我将其留在这里只是为了看看是否有人知道如何做到这一点。
最佳答案
简短版本:你不能。
这里存在一个基本的“检查时间到使用时间”问题,您没有足够的控制权来解决。在您检查 HasExited
属性和检查 >MainWindowTitle
属性。
Process
类并没有做太多的事情来强制获取异常,但它已经足够了。特别是,调用 Refresh()
会强制类“忘记”它所知道的有关进程的任何信息,以便当您再次请求时它将重新检索信息。这包括该进程的主窗口句柄。
Process
类使用 native 窗口枚举函数来搜索已知进程 ID 的窗口句柄。由于进程已退出,因此无法找到句柄,从而返回 NULL 值(托管术语中的 IntPtr.Zero )。当看到 null 返回值时,Process
类会强制调用 InvalidOperationException
。
唯一可靠的解决方案是始终准备好捕获异常。在检查状态和尝试执行依赖于该状态的操作之间,该状态总是有可能发生变化。
虽然是学术性的,但我发现有趣的是,如果您设置 EnableRaisingEvents
属性,Process
类可以(通常)更有效地检测退出的进程和抛出异常。
特别是,当设置 EnableRaisingEvents
属性时,Process
类会注册以由操作系统通知(通过线程池的 RegisterWaitForSingleObject()
) code> 方法)当进程句柄收到信号时。 IE。在这种情况下,Process
类甚至不需要搜索主窗口句柄,因为如果进程退出,它几乎会立即收到通知。
(当然,在非常小的机会窗口中仍然存在潜在的内部竞争条件,因为当 Process 类检查已退出状态时通知可能尚未到达,但在 Process
类枚举窗口之前进程可能仍已退出)。
无论如何,最后一点不会影响基本答案;这只是我在漫步the Process
source code时了解到并发现有趣的一些琐事。 。 :)
关于c# - Process.HasExited 竞争条件,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/33407477/