The FilesInUse class uses a single array of PIDs to manage population of the dialog's listbox and termination of the processes locking javahome.

In early development of FilesInUse, it was discovered that java.exe from an out-of-proc plugin was making its way onto the listbox.  As a solution, the parent processes of all of the locked PIDs are checked for DLLs which are indicative of OOPP.  If the parent process (e.g. iexplorer.exe) is found to have an OOP java.exe, we ignore it and do not add it to the array of PIDs referenced above.

I just discovered a problem that arises when the FilesInUse checkbox is used to terminate the applications listed in the dialog.  The FilesInUse class uses a callback that sends a WM_CLOSE via the MSGQUEUE to all windows that have handles associated with the given PID.  After the Enum/Callback, the code waits for the PID to terminate, or force-terminates it and waits again if the timeout is exceeded.

This portion of the code should not be changed.  We shouldn't be waiting for each handle to terminate before moving along to the next WM_CLOSE.  However, a problem is presented when the OOP java.exe takes longer to terminate than the parent process ID.  The code will move ahead as the parent PID is terminated and make an attempt to re-populate the listbox.

Because the lagging OOP java.exe no longer has a parent, it's not detected as OOPP, and thus added to the array of PIDs that drives the dialog content.  This results in the dialog presenting the user with, "java.exe" in the listbox even though the process is terminating.

The simple solution to this problem is to keep the OOPP PID in the array, but ignore it in the portion of the code (::PushTitles()) that adds the exe/window title to the listbox.  This way we get the best of both worlds...the OOP java.exe is hidden from the user, but the FilesInUse class can more effectively terminate it.

Webrev to follow...