App-V 5.0 and TerminateChildProcesses

You know, I think somebody on the product team at Microsoft must have looked at the old 4.6 setting ‘TERMINATECHILDREN’ and thought:

“You know what, I think we ought to rename that. It sounds a little evil, especially in all caps like that. How about TerminateChildProcesses? Oh, and while we’re at it, let’s do what we can to stop it working like it used to. Save the children!”

I’ve found three bugs with the new TerminateChildProcesses functionality in App-V 5.0, although the first one might arguably be a ‘feature’…

Detection Of Lingering Child Processes

In App-V 4.6, if you launch your applications for ‘streaming optimisation’ phase, the sequencer hangs around to make sure that all child processes are closed before continuing. If you close your app but this is still hanging around due to lingering child processes, you press the Stop button to force it to close:

4.6 sequencer

App-V 5.0 works slightly differently in that it will just tell you if any child processes are found when you hit next to finish the streaming phase:

5.0 sequencer

However I have found that I rarely see the above message, and often have to force it to pop up by leaving my specific application open when I press next if I know I want the TerminateChildProcesses setting applied to that app.

And I have just figured out why!

In 4.6, the ‘configure’ phase (which runs prior to the ‘streaming optimisation’ phase shown above) spins up a mini virtual environment, like a cut-down App-V client. When you press next to complete the phase, this virtual environment is disposed of along with any processes that were created within it, including task manager and any explorer windows that were opened.

In 5.0, the application is executed as a regular native application. This makes sequencing much faster, however when you go past this phase, any lingering child processes are left running. Then, when you get to the ‘streaming optimisation’ phase, these problematic background processes are not detected as new processes, hence the dialog above will not appear!

If Microsoft are listening, my preferred fix for this would be to move the detection of lingering child processes to the initial configuration launch phase. Additionally, terminate all processes triggered since the start of monitoring before entering this phase, in case any are left running by the installer, or if the user launched the app via the start menu. The other added benefit of moving the detection to this earlier phase, is that it adds child process detection for those of us that don’t perform streaming optimisation (which will be more commonplace now that fault streaming has been said to be more efficient!).

For everyone else, there are a couple of things you can do to avoid this if it is important to you:

  1. Before the streaming optimisation phase, open the task manager, and kill any processes that look like they are related to your application. This is my recommendation for now, although it’s not idiot proof as you might close an unrelated process by mistake. I have an idea to write a script to do the job though, if I get around to it I will add it to this post.
  2. Alternatively, don’t launch your app from the installer, start menu, or configuration phase. Instead, configure your app in the streaming optimisation phase. I don’t really recommend this, as sometimes apps can create new  file associations or register other new entries in various subsystems on first launch, and these will be missed if you skip the configuration phase.

Internal Manifest vs DeploymentConfig.xml

The 5.0 sequencer correctly adds the required <TerminateChildProcess> tags to both the manifest file inside the .appv package, and the external DeploymentConfig.xml. In fact it will add multiple identical entries for the same app if you launch it and accept the dialog more than once (bug #2!).

The main problem however, is that (in my testing at least) the App-V client totally ignores the setting in the internal manifest file and will only listen to it if DeploymentConfig.xml is imported.  I think these config files are only imported automatically if using SCCM 2012 integration, so for any other deployment method there will be an extra step required to import the config. If you are using the MSI package to deploy, help is at hand with this transform I created earlier.


Leave a Reply