Receiver prevent logoff

Hello all,

On my XenApp6 environement, I publish seamless stream-to-server applications. When I close an application, The session does’nt end.
I first modify the SandboxStatusMonitorPeriod Key (see CTX123073). It helped to close RadeLauncher.exe after a defined period of time. But the other processes keep alive !
So, I tried to kill each process, one at a time, to test which one prevent the session to end. I found that Receiver.exe is the one preventing logoff.

I tried 2 workaround :

receiver.exe autorun

My first test was to disable the receiver.exe autorun on logon (I don’t need it as I don’t have published desktop).  Delete the “ConnectionCenter” value from “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run” regitry key.

When I ran the published applications, I saw that receiver is launched again ! I tried to go deep in the user session with procmon. I realized that Raderun starts receiver.exe with “-autoupdate -startupplugin” options during my streaming process !

As I didn’t understand why receiver.exe process is needed during streaming, I renamed the file receiver.exe in  OLDreceiver.exe, and tried to launch my published application from my client. And you know what ? It works like a charm ! One exception : When you launch a published apps which is streamed to server for the first time, you see the “streaming application…” progress bar. When receiver is renamed, this progress bar is in Windows Classic style instead of Receiver-like graphical view.

Ok, Renaming receiver.exe is not an option, but it helps me to go deeper in Citrix.

LogoffCheckSysModules

My second test is to set “receiver.exe” in the LogoffCheckSysModules Key (see CTX891671). It did the trick, but I’m not satisfied with that. Why it is not set by design ? And why nobody complain about it on the web ? I keep searching what’s wrong with my configuration…

I’ll edit this post as soon as I have more information about that.

23rd Apr. 2012 – Edit :

Thanks to Citrix, they answered my forum thread and the answer is packaged in a limited hotfix (myCitrix login required).