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

Application randomly "Not Responding"

Jay Stevens



Has anyone run into issues with applications freezing, “Not Responding” and greyed-out UI when running as seamless published application in XenApp 6.5.  We don’t see such issues when running the same application on the same server but as RemoteApp or in published desktop.  I see number of similar threads but related to Windows XP rather, all our workstations are Windows 7 running Receiver 3.4.   While troubleshooting I have done the following so far:

-          Installed all MS patches

-          Installed XenApp 6.5 Rollup Pack 3

-          Tried almost every combination of seamless flags

-          Excluded application executable from CTX hooks

-          Tried different published app appearance settings

-          Updated hardware drivers and firmware as all workers servers are physical machines with no page file.

Could it be Windows 2008 issue?  The two apps are .NET apps and we have never experienced this in old PS 4.5.  The symptoms are that while the app is busy talking to database the “Not Responding” will display in title bar and at times the application window will grey-out.  Usually after 5-20 seconds the app recovers.


Any help will be highly appreciated.






Link to comment

9 answers to this question

Recommended Posts

  • 0

Dear Jay stevens

i've exactly the same problem on Application requesting database (not responding) only on windows 2008...

the same application works fine on windows 2003 (applications is also compliant with W2K8...)


have you find root cause ? or workaround ?


Thnaks a lot for your help


Do you have the XA policy Memory Optimization enabled? Try disabling that and see if that makes a difference.

Link to comment
  • 0

I've just come across this issue as well and have some findings.


With my application, when I RDP into the system I can replicate the same issue, the application goes to 'Not Responding' when using a certain feature (in this case it opens and sets MSPaint as the upper most window and blocks access to the app until MSPaint is closed).  This is caused by Windows detecting that the UI thread is blocked.  This timeout will also 'Ghost or Frost' the window.




The users reported this didn't occur on their previous system (a Windows 2003 server now long retired).  I found that if I modify the value of 'HungAppTimeout' to 20000 (20 seconds) then the application does not go into the 'Not Responding'.  I spoke to the developer and they said that they check every ~5 seconds or so to see if MSPaint is open and if true 'lock the UI'.  This corresponds nearly exactly to the default 5 second timeout of HungAppTimeout and also explains why it was inconsistent for my users.  When the app did its check every 5 seconds sometimes it would refresh its UI preventing it from 'Ghosting'.  But it was really inconsistent..


Anyways, modifying the HungAppTimeout value to a larger timeout prevents 'Ghosting'/'Not Responding' and gives the application more time to recover itself before Windows locks its UI.


You can modify/create the value here:

Registry key: HKCU\Control Panel\Desktop
Data type: REG_SZ
Value name: HungAppTimeout
Data: Milliseconds (in decimal)



For it to take effect you need to logoff/logon so it needs to be in your NTUSER.DAT.  winlogon.exe processes this key for it to take effect.

  • Like 1
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...