A Solution To Child Zombie Processes Keeping Sessions Open

There are several scenarios where a published application can cause a "session" to not terminate properly due to open child processes. The most common of these is a Citrix Published Application which then keeps the user session open on the server until the Disconnect/Terminate timers step in.

There are several scenarios where a published application can cause a "session" to not terminate properly due to open child processes.  

The most common of these is a Citrix Published Application which then keeps the user session open on the server until the Disconnect/Terminate timers step in.  The user launches a published application running on the server.  This creates a user session on the terminal server and the primary exe of the application is started.  If this exe starts a child process but does not directly manage it, when the primary exe terminates because the user is through with this application this child process will keep the session open.  This is what you might want if the child process has a visible GUI.  For example if the child process is a mshelp application - the user may have shut down the app as troubleshooting and wants this help page to remain up as (s)he restarts the application.  But many times the child has no GUI.  So the session remains open on the server until the termination timer hits (typically an hour).

With Windows 2008 and RDP published applications there will be the same problem (although with Windows 2008 and either rdp or ica sessions there will be a change that extends the life of the session for a short while anyway, hoping that the user will launch another app.  This will be more like 2 minutes.  I am hoping we can configure that time frame down in the final release).

We also see this problem in Virtualized Applicaitons, such as in SoftGrid and Citrix Streaming for sure, and I suspect Thinstall as well.  Instead of keeping a session open, it would keep the virtual environment open, which is bad enough on a desktop OS - but on a terminal server also manages to keep the user session open.  SoftGrid added a option that will terminate the child processes a couple of years after I wrote this utility to help out.  This is the unabashedly named TERMINATE_CHILDREN=TRUE tag in the OSD.  But we still have need for this app.

LaunchIt (available in the Tools section at www.tmurgent.com ) is a simple exe that takes as an argument the path/name of another exe to launch and monitor.  For example, to launch word the command line would be "LaunchIt.exe msword.exe".  In the case of the user starting a child mshelp process, when msword.exe terminates LaunchIt will terminate the child processes for you.  So you just include LaunchIt on your system (or in your virtual application package) and modify the published command line.

There is also a nice option of using "LaunchIt.exe /v msword.exe" which will detect msword ending and (if there are any child processes) prompt the user about these processes.  The dialog box lists the short name of the exes and process IDs and asks if the user wishes to terminate these as well.  Many times this is the desired approach.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I've always used a documented Citrix registry hack to make sure the background process is closed.... However, I can't seem to locate it now.
It's called LogoffCheckSysModules. Provision Networks has a similar mechanism that's configurable through their management console.
Here it is:

But sometimes even when I terminate the session from the server itself the user gets " u have an active session on the server and cannot open another ". most of the times I have been suggested to restart the server...I guess this is not a good option if only one user is affected..Please suggest
The Microsoft Terminal Services team recently published an article on their blog which explains Session Termination logic in Windows Server 2008:
If you read this article you will see that Windows Server 2008 will not suffer from the problem described in this post (zombie child processes). This is because WS08 tracks UI elements rather than processes. As a result, a UI-less child process will not cause a session to remain active.

Ericom PowerTerm WebConnect already uses an enhancement of this method (tracking UI elements rather than processes) so it also does not suffer from this shortcoming. You can read more about this functionality in my blog:

I didn't mention that out of simplicity. This will reduce the instances, but I suspect not eliminate all cases. UI element detection is not foolproof, and we all know developers are a bunch of fools!
Yes, we certainly are fools :-)
One of my favorite software development quotes is Dave Winer's: "We Make Shitty Software... With Bugs!" (http://www.scripting.com/davenet/1995/09/03/wemakeshittysoftware.html).
Any developer who doesn't acknowledge this is a bigger fool

The situation is especially hairy with regard to Server Based Computing because Windows itself was not designed as a multi-user OS, and most Windows applications where not designed for such an environment either. (For example, see this thread on the Joel on Software Discussion Group - a forum frequented by developers: http://discuss.joelonsoftware.com/default.asp?joel.3.501610.9 I loved the question: "What is this Citrix thing anyway?") Because of this we need to rely on all sorts of heuristics just to make things work properly.

However, when relying on heuristics, choosing the right heuristics becomes crucial. In this case I believe that UI element detection is a much better method for deciding when to end a seamless session than tracking processes, case in point the problem you described. This is why we use it in PowerTerm WebConnect and that is why Microsoft has chosen to use it in Windows Server 2008. Obviously, being a heuristic, it's not a foolproof solution, which is why a wrote a blog post about it.
Just because Microsoft chose this approach doesn't make it the best one. In most cases, you're dealing with one or two applications that exhibit this behavior. The approach of keeping track of running processes and Tim's approach of waiting for the parent process to terminate are both simpler and cover more use cases than keeping track of UI elements.
> waiting for the parent process to terminate are both simpler and cover more use cases than keeping track of UI elements

Simpler for Citrix to implement or for the customer to use? Can you give an example of a scenario that is better covered by this approach than keeping track of UI elements?
Sure. App launches a background service. The service is built with the capability for console GUI but isn't used. User can't see anything on the screen but there is a UI element registered so you probably don't terminate. Second case is anything that has a GUI but it's just a tray icon and you want it to go away.

Don't get me wrong, UI tracing is better than what we have today, it's just nice to have another kind of hammer for when you need it.
Tim you should read the Microsoft post and my blog :-)

1. Invisible UI elements - only visible UI items count. This means that a hidden window will not keep a session connected. Sure, there are always special cases, e.g. the only visible window is moved wholly out of the screen, but overall not too difficult to handle.

2. Tray icon - a distinction is made between the icons of applications launched automatically, i.e. during session startup, vs. those launched because of user interaction. The later keep a session connected, the former don't.

Almost by definition every heuristic has its limitations. Tracking UI elements appears to have fewer limitations then tracking processes, which is why we chose it for PowerTerm WebConnect.
Your blog is an advertisement for the company you represent.
it seems to keep the AIERUN window open.. Ive written to TMurgent about this.
Hey Guest, I wrote a post about you on my blog: