XenApp sessions not logging off when published applications closed

So you publish an application from your Citrix Presentation Server/XenApp server, a user fires up the app, everything works fine. User closes the app. Some time later the user opens the app again and none of their settings withing the application have been saved. But maybe sometimes they have. You suspect that this is because their roaming profile isn’t being unloaded. You look at the sessions on the server and see that there are people with sessions running but no application executable running.
This is caused because XenApp makes an educated guess as to which executables are part of a published application and which are part of either itself or the OS. Those exes that are running in a user session because they are part of XenApp or the OS can be killed when the main published application exe is closed. XenApp has a hard coded list of these, including things like proquota.exe, wfshell.exe, ssonsvr.exe.
Most of the time I’ve found that the built-in list works fine, but I now have two additional executables that I need to add. One is sftdcc.exe (Microsoft App-V client) and the other is PDAgentS1.exe (which is part of PerfectDisk defragmenter).
Luckily Citrix have a KB article about all this. There’s a reg value that you can put a comma separated list of executables into to add them to the “ignore these when trying to decide if the published app session still has any application executables running” list.
\wfshell\TWI\LogoffCheckSysModules (REG_SZ)

So my LogoffCheckSysModules now contains:
And we’re back to sessions ending correctly when published applications are closed, and roaming profiles loading and unloading correctly.

Update September 2015: Note that there is an equivalent way of doing this if you’re running Remote Desktop Services or Session Host in Server 2008 or 2012.

This entry was posted in XenApp. Bookmark the permalink.

11 Responses to XenApp sessions not logging off when published applications closed

  1. Ashwin says:

    Hi thank you for sharing this information. We had this problem also because we have installed the App-V client.
    The problem is solved.


  2. Anton Keller says:

    APPV 5.0 Problem solved.

  3. Chinna says:


  4. Dragon64 says:

    did not work for me. we published notepad.exe and the wfshell.exe *32 is still running and leaves the users state as active

    • rcmtech says:

      What other processes are still running in the session?

      • Dragon64 says:

        Process ran = notepad.exe

        Processes running under the user context of x635
        ssonsvr.exe *32
        ccSvcHst.exe *32
        wfshell.exe *32

        On the published application I select File | exit

        Process still running under the user context of x635
        ssonsvr.exe *32
        ccSvcHst.exe *32
        wfshell.exe *32

        The blue windows screen still shows until we kill the wfshell.exe *32 user process then it logs the user off properly.

      • rcmtech says:

        I think you should ask yourself what ccSvcHst.exe is doing in that list. If you look at CTX891671 (as per the main post above) it contains a list of executables that are part of either Windows or XenApp. ccSvcHst.exe is not on that list (it’s part of Norton Antivirus I believe), and so you need to add this to the LogoffCheckSysModules registry value.

      • Dragon64 says:

        I believe we tried that and we still had the same effect. However, I have taken another thick image server and have used XenConvert to move it into PVS. I am about to test that one as it works as expected from that server. Will let you know.

  5. Dragon64 says:

    Running from the newly converted one works so this looks like it is just the previous image that was having the issue. We do have a case open with citrix and uploaded our CDF traces to see if they can help us figure out what on the previous image was wrong. Will let you know.

  6. Steve Ballantyne says:

    Thanks for posting this. Old article, but still relevant for people like me who are running OLD code. :-) We have Citrix Xen App (5.0) and we experienced this problem only after installing a rollup hotfix package. For us, the two programs left running were SLAgent.exe (our logon script engine) and DAEMON.EXE (some sort of fax monitoring utility). Adding this registry key resolved the problem immediately.

  7. Pingback: SysProcs is RDS equivalent of Citrix LogOffCheckSysModules | Robin CM's IT Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s