32-bit application starting on Citrix Virtual Apps 1912 CU6 environment logs user off after 10 seconds

[J.R. van Doornik]

An older application which is required by our employees can be used from a published desktop. Using the application as a published app, we found the application does NOT start.

 

If we create a VDA for Notepad or Excel, the application is neatly launched and can be used as expected. So the VDA configuration is verified. 

 

When we however select the executable for the older 32 bit application (selected as %ProgramFiles(x86)%\folder\folder\file.exe (I browsed to the file in question), or even as C:\Program Files (x86)\folder\folder\file.exe) the application does seems to launch as expected. Login for the Citrix server is asked, we see the session being created, but the application itself doesn't appear. 

 

Instead the session is disconnected after about 10 to 15 seconds, where the server-side eventlogs show that as a logoff prompted by the user. The Citrix Connection Center also indicates that the application doesn't seem to be launched (we see WEM appearing briefly and then the session is torn down), and possibly as a result of that inability to launch the application the logoff is triggered. 

 

I did find some information on the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI (specifically the DWORD entries for ApplicationLaunchWaitTimeoutMS and LogoffCheckerStartupDelayInSeconds), but either of those doesn't seem to change the behavior. I hae not yet tried to have both of them present, but I'm not sure if that's even where our problem resides. 

 

My guess at this point is that the Citrix logon goes as expected. The session hands over control to the OS to start the application. The OS can't find or start the application (despite it being present), and Citrix finding that no further actions are being done in presenting the application initiates a logoff.

 

And yes, I'm well aware that the application is slow in starting. It shows a processing screen about 5 seconds in, and takes 15 seconds to fully start, but that 5 seconds but should be sufficient to allow Citrix to pick up that the application is actually being started. 

 

Does anyone have any idea what might cause the 32-bit application to run normally from a desktop session, but failing to start as a published application? Or possibly where I could find some logs that may hint at the root cause of this?  

[J.R. van Doornik]

I would like to note that while I did add the two mentioned registry keys, I did NOT reboot the server after adding or removing them. I'm assuming they should be active right off the bat. 

 

Also, as stated I did not add both keys at the same time. Not sure if that's a recommended action. 

 

Looking forward to any and all input. 

[J.R. van Doornik]

Went ahead and added both DWORD32 registry entries (in decimal) to the Citrix servers. From what I gather the max values for them are as follows:

 

LogoffCheckerStartupDelayInSeconds - 600
ApplicationLaunchWaitTimeoutMS - 30000

 

Tried this with 30 and 10000 respectively. No change in behavior.
Then tried this with 40 and 20000 respectively. Still no change.
Changed values to 60 and 30000. Still no dice.

 

So I'm unsure if those registry keys are actually doing something. Didn't restart the server (I figure that might not be needed for this change since it's not mentioned anywhere as required).

 

I expanded my test to three variations of the program (all run the same basic engine at their core).  Two of those exhibit the logoff behavior (grabbed that in an eventlog file), while one of the three does seem to start, but tosses a memory error on a hardlock.exe (which sounds suspiciously like a USB key or something that it needs to ascertain if it is allowed to start). So that does indicate that there is an attempt to run the programs, just that it's unsuccesful for unknown reasons. 

 

All three programs run an executable in the C:\Program Files (x86) folder, which has created three subdirectories for each program under it, each containing it's own executable. There are no spaces in use in the subdirectory folder names, nor in the executable files, which might account for some form of possible misconduct. 

 

Again, starting the programs from a desktop (both as an administrative and basic user) does work. Starting the application directly without going through the desktop fails to start said application. 

 

As to the Application eventlog that reflects my signon and signoff... 

 

13:36:20 - Citrix Desktop Service - EventID 1027 - The Citrix Desktop Service detected that a user session has started. User '' has started session <GUID>
13:36:20 - Citrix WEM User Logon Service - EventID 0 - Start logon processing for user DOMAIN\USER
13:36:20 - Citrix WEM User Logon Service - EventID 0 - Start processing policies for user DOMAIN\USER
13:36:21 - Citrix WEM User Logon Service - EventID 0 - Processed policies for user DOMAIN\USER
13:36:21 - Citrix WEM User Logon Service - EventID 0 - Finished logon processing for user DOMAIN\USER
13:36:26 - Citrix Profile Management - EventID 1000 - The session is ready for use. See the event data for the session ID.
13:36:40 - Citrix WEM User Logon Service - EventID 0 - Start logoff processing for user DOMAIN\USER
13:36:40 - Citrix WEM User Logon Service - EventID 0 - Start processing logoff for user DOMAIN\USER, sid: <GUID2>
13:36:42 - Citrix WEM User Logon Service - EventID 0 - Succeeded to process logoff script for user DOMAIN\USER.
13:36:42 - Citrix WEM User Logon Service - EventID 0 - Finished logoff processing for user DOMAIN\USER
13:36:44 - Citrix Desktop Service - EventID 1030 - The Citrix Desktop Service detected that a user session has ended. Session <GUID> for user '' has ended; reason code Logoff.

 

So that confirms the session logs on, and after a bit of time logs off again.

 

Nobody having any thoughts on this?

[J.R. van Doornik]

No-one having any thought here? ?

[J.R. van Doornik]

Sad to see nobody wants to hazard any guesses into what might be going on ?

As it is, the problem remains, and I'm at a loss as to what I can do further to troubleshoot and resolve this. 

[CarlStalhood]

Launch a published app that works. Then launch the problem app from the same VDA. Does it launch? This might be an app that requires explorer.exe (desktop) to be running in the background. Newer VDAs support ShellBridge that simulates a desktop session.

 

Procmon might reveal the issue.

[J.R. van Doornik]

Okay... That gives me something... Once I start notepad on the affected group of servers, the affected applications do start within the same session. So going from your comment , the (and yes, these are somewhat ancient applications) require explorer.exe to be active before they themselves actually start. 

So the question then becomes: How to sort this problem? 

[J.R. van Doornik]

Managed to squeeze in some searching yesterday and came up with these:

https://support.citrix.com/article/CTX236485/cant-start-a-specific-application-which-relies-on-explorerexe
https://support.citrix.com/article/CTX138069/published-explorerexe-and-other-applications-close-instantly-after-launch
https://support.citrix.com/article/CTX127874/published-application-fails-to-launch-outside-of-desktop-session

 

Basically two of those are going for a logon script using some form of alternative to Explorer. Which makes me unsure how the remaining desktops and apps running on that server will behave. I haven't yet been able to find out exactly what that alternative exactly does... 

 

Might need to propose to just try it and see what it does... 

[J.R. van Doornik]

Okay... Made the runonce /AlternateShellStartup change on one server through it's local group policy. Set the other three into maintenance mode to prevent the applications from trying to start on those. 

 

Note here: The three applications are from the same vendor, do the same thing, just have slightly different applications, and as such are pretty much similar in use (both to the user and the system). 

 

Started up application 1 of 3

 

Logs in, I see the WEM manager passing by, and then the application throws an error regarding a hardlock.exe application and memory that can't be 'read'. I'm fairly sure the application IS keyed to a USB key needing to be present somewhere. The application does NOT throw this error when starting from the desktop. 

 

When I hit okay, the application closes and the session is logged off from the server. 

 

Started application 2 of 3 

 

Does the exact same thing as the first one. Hardlock.exe with memory that can't be read, which doesn't show up when starting from the desktop. 

 

When I hit okay, the application closes and the session is logged off from the server. 

 

Started application 3 of 3

 

No issue or notification on that hardlock.exe and memory thing, but the application doesn't appear and the session is quietly logged off. 

 

Now... If I start application 1 of 3, and when the error is shown on screen I start application 2 of 3, that 2nd application launches as expected. 

 

Once open, and I then try to start application 1 of 3, it also starts as expected. Also, application 3 of 3 wants to start normally aswell. 

 

So that's pretty much the same behavior I spotted as when I started the notepad application, and then kicked off the applications. 

 

So the runonce /AlternateShellStartup doesn't seem to affect the way the applications start under Citrix. Any further suggestions to try? 

[J.R. van Doornik]

While we are still using the workaround (by pointing users at the desktop and THEN starting the application), it's not the desired endgoal. 

 

With the above I'm fairly certain it's connected to a session being started in limited (lets just call it neutered) mode, and the application determining it can't start from that point. 

 

While stating another application first and THEN starting the offending applications work, it's not an ideal means of providing the application to the users. So I would like to provide the application as such if at all possible. 

 

Does anyone have any other ideas on root causes or things I might try to resolve this? 

[J.R. van Doornik]

Seems no further ideas are present as to what might be causing this behavior. 

 

I agree that the apps are old and should be removed from service, but alas, it seems no suitable replacements are in existance, and the users are adamant they NEED those programs to do their jobs. 

 

I'm keeping an eye on this in case anyone has any further ideas, but as it stands it seems we're forced to work with the desktop-workaround rather than start the applications directly. 

[Jozef Jonas1709152693]

Hi,

 

I have exactly the same problem with application Epicor iScala. Main, application starts OK, few other parts of the application (separate exe) do not start as published app. They just close. Works fine when started from desktop, doesn't work as published app. No crash, no log, nothing. It starts and successfully closes and session is closed too.

 

Joe

[J.R. van Doornik]

By now we've kind of accepted the need for users to explicitly start a desktop, and then start their app. Atleast while we're investigating replacing the apps with something more modern (if that exists). 

 

I haven't managed to dig up anything that could explain the behavior despite sinking a lot of time into this... :(