我有一个.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可以处理我的工作？
答案 0 :(得分：2)
您可能会找到this blog来整理WmiPrvSE正在做什么。
WmiPrvSE是WMI Provider主机。这意味着它托管WMI提供程序，它们是DLL。所以几乎可以肯定的是，WmiPrvSE无法处理您的工作，而是它所承载的提供商之一。为了找出哪个提供者是罪魁祸首，一种方法是遵循流程here，然后查看哪个独立流程持有句柄。
一旦确定哪个提供程序持有句柄，您可以尝试根据提供程序管理的系统组件推断出哪种查询可以处理您的作业。或者，如果您不关心失去对提供商提供的组件管理的访问权限，您可以禁用提供商。
如果您可以确定哪种查询将持有句柄，您可以推断出发出查询的程序。或者也许事件日志可以告诉你（上面的第一个链接）。
要获得更多帮助，请在OP中提供其他详细信息，例如WmiPrvSE中运行的提供程序，任何相关的事件日志事件以及您获得的任何其他诊断信息。
编辑1/27/16
找出导致WMIPrvSE获取作业句柄的事件的方法是使用Windbg的！htrace扩展。在加载.EXE之后但在Windbg中执行之前，需要运行!htrace -enable。然后，您可以稍后进入并执行!htrace <handle>以查看操作句柄时的堆栈跟踪。您可能希望从此article on handle implementation.