Jump to content
Welcome to our new Citrix community!
  • 0

Published App shows "Launching Application" then nothing else.

Chris Hide1709158712


A client of ours is having issues launching an application through Citrix StoreFront/Receiver/Workspace.


The application works fine when running the executable from within a published desktop and via RDP.


All other published applications work without issues, however just this one shows "launching application" in the Citrix Receiver progress bar and then nothing else. No error message.


There's nothing in the Session host logs, and the Delivery Controller events show the user log on and log off events.


I've enabled Citrix Receiver verbose logging and the logs don't really contain anything of interest. It's as if the application is launching correctly.


If I monitor task manager on the session host as an admin whilst I launch the published application as an end user, I can see the user session and all the processes starting up and then start closing off and the user session is logged off.


Interestingly, I've created a .bat file in exactly the same directory as the executable, which literally just says "start <processname.exe>" and that works without issues as a published application. This is what we're currently doing as a workaround. However, I'm interested to see what the reason behind this is.




XenApp 7.13

PVS 7.13

Server 2016 Session Hosts running 7.13 (but also tried upgrading to 1811)


Things that I've tried so far are:




  • Ensuring the process name isn't listed in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI\LogoffCheckSysModules, which it isn't.
    • The same for HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Sysprocs
  • Setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI\LogoffCheckerStartupDelayInSeconds  as high as 10 minutes
  • Setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI\ApplicationLaunchWaitTimeoutMS as high as 30 seconds (30000 milliseconds




  • Added the process name to ExcludedImageNames in the below registry keys
    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook
  • Added the process name to UviProcessExcludes  in the below registry keys
    • HKLM\SYSTEM\CurrentControlSet\services\CtxUvi


  • Published command prompt, cd'ing to the application directory in Program Files (X86) and launching the application - this doesn't work, although opening other applications (i.e. Notepad) works fine.


I've ran procmon and launched the executable as well as the bat file as a side by side comparison, and can't really see any differences when filtering for the process ID.


Any ideas are welcome.

Link to comment

5 answers to this question

Recommended Posts



Are you sure that not the working directory is the issue here? When launching either app directly (most likely it will) or via cd'ing it will be the folder containing the executable. When just using start it will most likely be %windir%\syswow64 or system32. Depending where it launches it might load an assembly (dll) of a different version which causes it to crash.

Enable only the Process and Thread Activity View in Process Monitor and compare which assemblies are loaded in both cases (count, names, order and exact path).



Link to comment



It's exactly like I predicted. Your program is terminating with 0xC0000135 = STATUS_DLL_NOT_FOUND in LogFile1. The DLL in question is PBVM126.dll.


In LogFile1 this .dll can't be found and the program terminates. In LogFile2 it's found in "C:\Program Files (x86)\Common Files\Thermo Shared\Nautilus\PBVM126.DLL"


This again because the %PATH% (Path=) environment variable inherited from wfshell.exe doesn't contain "C:\Program Files (x86)\Common Files\Thermo Shared\Nautilus" whereas the environment inherited from cmd.exe does. This prevents nautlius.exe from finding the assembly.



Link to comment

Yes that should work (5.), unless it causes other issues (some applications require the working directory to be user specific and writeable). You could also add it to the system %PATH% environment variable.


Standard Search Order for Desktop Applications (https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order)

  1. The directory from which the application loaded.
  2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
  3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
  4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
  5. The current directory.
  6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
Link to comment


This topic is now archived and is closed to further replies.

  • Create New...