Why is WmiPrvSE.exe holding onto a handle to my Process' Job Object?

Question

I have a .NET application which spawns multiple child 'worker processes'. I am using the Windows Job Object API and the JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE setting to ensure the child processes always get killed if the parent process is terminated.

However, I have observed a number of orphaned processes still running on the machine after the parent has been closed. Using Process Explorer, I can see they are correctly still assigned to the Job, and that the Job has the correct 'Kill on Job Close' setting configured.

The documentation for JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE states: "Causes all processes associated with the job to terminate when the last handle to the job is closed."

This would seem to imply that a handle to the Job was still open somewhere... I did a search for handles to my Job object, and found instances of WmiPrvSE.exe in the results. If I kill the relevant WmiPrvSE.exe process, the outstanding handle to Job is apparently closed, and all the orphaned application processes get terminated as expected.

How come WmiPrvSE.exe has a handle to my Job?

Handbag

Answer 1

You may find this blog in sorting out what WmiPrvSE is doing.

WmiPrvSE is the WMI Provider host. That means it hosts WMI providers, which are DLLs. So it's almost surely the case that WmiPrvSE doesn't have a handle to your job, but one of the providers it hosts does. In order to figure out which provider is the culprit, one way is to follow the process here and then see which of the separate processes holds the handle.

Once you have determined which provider is holding the handle you can either try to deduce, based on what system components the provider manages, what kind of query would have a handle to your Job. Or you can just disable the provider, if you don't care about losing access to the management of the components the provider provides.

If you can determine what kind of query would be holding a handle, you may be able to deduce what program is issuing the query. Or maybe the eventlog can tell you that (first link above).

To get more help please provide additional details in the OP, such as which providers are running in WmiPrvSE, any relevant eventlog events, and any other diagnostics info you obtain.

---

EDIT 1/27/16

An approach to find out what happened that caused WMIPrvSE to obtain your job's handle is to use Windbg's !htrace extension. You need to run !htrace -enable after you load you .EXE but before you execute it in Windbg. Then you can break in later and execute !htrace <handle> to see stack traces when the handle was manipulated. You may want to start with this article on handle implementation.

Ironmaster

Thanks for the help - it's definitely the WmiPrvSE process which owns the handle to the job (rather than another process which is querying WMI). I've enabled the diagnostic logging as per the blog above, but as I have no means to tell when the handle was opened, it's difficult to correlate the root cause to one of the numerous WMI events. Thanks though - I'll keep persevering. – Handbag

Another process querying WMI could cause WMIPrvSE to open a handle. WMIPrvSE, in my understanding, WMIPrvSE doesn't act of its own accord, but due to WMI queries. So even if another process is doing the query and doesn't directly own the handle, that other process could be the culprit. Also see my edit to this answer. – Furness