为什么 WmiPrvSE.exe 持有我的进程的作业对象的句柄？答案

【问题标题】：Why is WmiPrvSE.exe holding onto a handle to my Process' Job Object?为什么 WmiPrvSE.exe 持有我的进程的作业对象的句柄？
【发布时间】：2016-01-25 11:26:39
【问题描述】：

我有一个生成多个子“工作进程”的 .NET 应用程序。我正在使用 Windows 作业对象 API 和 JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE 设置来确保在父进程终止时子进程总是被杀死。

但是，我观察到在父进程关闭后，机器上仍有许多孤立进程在运行。使用 Process Explorer，我可以看到它们仍被正确分配给 Job，并且 Job 配置了正确的“Kill on Job Close”设置。

JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE 的文档指出： “当作业的最后一个句柄关闭时，导致与作业关联的所有进程终止。”

这似乎意味着 Job 的句柄仍在某处打开...我搜索了 Job 对象的句柄，并在结果中找到了 WmiPrvSE.exe 的实例。如果我杀死相关的 WmiPrvSE.exe 进程，则 Job 的未完成句柄显然已关闭，并且所有孤立的应用程序进程都会按预期终止。

为什么 WmiPrvSE.exe 有我的 Job 的句柄？

【问题讨论】：

标签： windows winapi process wmi win32-process

【解决方案1】：

您可以在整理 WmiPrvSE 正在做什么时找到this blog。

WmiPrvSE 是 WMI 提供程序主机。这意味着它托管 WMI 提供程序，即 DLL。因此，几乎可以肯定的是，WmiPrvSE 无法处理您的工作，但它托管的提供商之一却可以。为了找出哪个提供者是罪魁祸首，一种方法是跟踪进程here，然后查看哪个单独的进程拥有句柄。

一旦您确定了哪个提供者持有句柄，您就可以尝试根据该提供者管理的系统组件推断出什么样的查询可以处理您的作业。或者，如果您不关心失去对提供程序提供的组件管理的访问权限，您可以禁用提供程序。

如果您可以确定什么样的查询将持有句柄，您就可以推断出哪个程序正在发出查询。或者也许事件日志可以告诉你（上面的第一个链接）。

要获得更多帮助，请在 OP 中提供更多详细信息，例如在 WmiPrvSE 中运行哪些提供程序、任何相关的事件日志事件以及您获得的任何其他诊断信息。

编辑 2016 年 1 月 27 日

找出导致 WMIPrvSE 获取作业句柄的原因的一种方法是使用 Windbg 的 !htrace 扩展。您需要在加载 .EXE 之后但在 Windbg 中执行它之前运行 !htrace -enable。然后你可以稍后闯入并执行!htrace <handle> 以查看操作句柄时的堆栈跟踪。你可能想从这个article on handle implementation.开始

【讨论】：

感谢您的帮助 - 它绝对是拥有作业句柄的 WmiPrvSE 进程（而不是另一个正在查询 WMI 的进程）。我已经按照上面的博客启用了诊断日志记录，但由于我无法告诉何时句柄被打开，因此很难将根本原因与众多 WMI 事件之一关联起来。不过谢谢 - 我会坚持下去。
另一个查询 WMI 的进程可能会导致 WMIPrvSE 打开句柄。 WMIPrvSE，在我的理解中，WMIPrvSE 不是自己的行为，而是由于 WMI 查询。因此，即使另一个进程正在执行查询并且不直接拥有句柄，该其他进程也可能是罪魁祸首。另请参阅我对此答案的编辑。