Keyboard works... but Mouseclicks aren't recognized

[Markus Frenzel]

Hello!

Some of my users got a strange problem from time to time... sometimes they can't click anymore in an published app (regardless of the app) but keyboard regular input and shortcuts still work (ALT+F4, TAB, ALT+TAB, etc.).

The mouse pointer can be moved... but clicks (left or right doesn't matter) aren't recognized.

My environment: XenApp 6.5 HRP1 with installed Hotfixes (002, 007, 011, 013, 028, 033, 053, 058), Windows Server 2008 R2 (latest Updates installed).

Any suggestions?

Thanks in advance.

Regards

Markus

[Martin Reis]

There has been found a nice workaround:

Customers PCs are equipped with a 5 Microsoft-5-button-mouse. If the application-window is frozen, users can do a leftklick and a rightclick and the issue is gone. It does not matter where you click, you can just work on without waiting or disconnceting/reconnecting.

 

It is very hard to get useful logs now, because do not report the issue any more.

 

EDIT: This only works in one special environment, sorry...

[ICT Support]

We have this exact problem too.

For now I have a feeling that this is caused by the Rollup Pack 3 because there were supposed to be some fixes which should fix the mouse problem but now instead are the cause of it?

Can't tell yet, I have deinstalled the Hotfix on the test environment and I'm waiting for the problem to occur, since it is randomly happening to random user at random times.

[Lorenzo Cavazzi]

Hello, we are experiencing this problem and we have RP2 installed

[Sakthi Ganesh]

Hello all,

 

We have had a few customer cases in the past month or so on different platforms/roll up pack levels of Xenapp. We engaged our developers and tracked down the issue to RDS mouse handling mechanism. The traces we got using private debug binaries indicate that the Citrix mouse handling mechanism sends the mouse clicks to the buffer like it was supposed to. But the RDS portion which is supposed to read from that buffer does not seem to work correctly. We have seen up to 1000+ mouse clicks queued in the buffer. At this stage we need help from Microsoft to figure out what is going on with their components. So we have asked our customers to open a case with Microsoft to investigate this further. We also have an internal communication open with Microsoft so that we can work together if they need any additional details from our side. Mouse issues are hard to track and this being a random issue made it much more harder. So it might take a while before we / Microsoft provides a fix for this issue. I will update this thread once we have a resolution. If you have a Microsoft support contract, please open a case with them. 

[Sakthi Ganesh]

Hello All,

 

Microsoft is still investigating this issue. One of the things they have asked is, when the mouse clicks stop functioning what is the overall experience of the session - does it show any performance issues? Also, if you leave the mouse for some time, does the problem go away on its own?

 

Regards,

Sakthi

[Tobias Hauswald]

Hi,

 

I can't find any performance issues. Also the User waiting 1,5 houre and the mouse problem still exist.

 

Regards

 

Tobias

[ICT Support]

The Downgrade to Rollup 2 didn't really help on my side either...

Does anybody have any news?

[Lorenzo Cavazzi]

I confirm what Tobias said, apparently no performance issues and the problem doesn't solve even after a long time

[Pavan nannapaneni1709152483]

can you confirm if UAC is disabled then you experience the same issue.

[Daniel Messer]

We experience this issue since January 2014 more and more (XA6.0, XA6.5, Win2008R2@XenServer). So we got in touch with Citrix and Microsoft. Microsoft finally provided this:

 

Change SNP features on client machine:

 

netsh int tcp set global chimney=disabled

netsh int tcp set global rss=disabled

netsh int ip set global taskoffload=disabled

netsh int tcp set global autotuninglevel=disabled

netsh int tcp set global congestionprovider=none

netsh int tcp set global ecncapability=disabled

netsh int tcp set global timestamps=disabled

 

Change CGP settings on client machine. (Usually there's no value in CGPAddress. We set 0.0.0.0 if the key was existing.)

 

HKLM\SOFTWARE\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Network\CGP\CGPAddress: "0.0.0.0"

HKLM\SOFTWARE\Wow6432Node\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Network\CGP\CGPAddress: "0.0.0.0"

 

Last but not least set this option on Terminal server:

 

netsh interface tcp set global autotuninglevel=highlyrestricted

 

On client and server, the network adapter must be rebooted after these changes. Or reboot the system;-)

 

Before I had that mousepointer problem as well (0-3 times a day). After applying these changes the issues were gone.

 

It would be great if you could share your experience with this workaround. For us it's not a real solution but at least users with heavy impact (5-8 times a day) can work again. We will get back to Microsoft for further debugging.

 

Greetings

Daniel

[ICT Support]

 

We experience this issue since January 2014 more and more (XA6.0, XA6.5, Win2008R2@XenServer). So we got in touch with Citrix and Microsoft. Microsoft finally provided this:

 

Change SNP features on client machine:

 

netsh int tcp set global chimney=disabled

netsh int tcp set global rss=disabled

netsh int ip set global taskoffload=disabled

netsh int tcp set global autotuninglevel=disabled

netsh int tcp set global congestionprovider=none

netsh int tcp set global ecncapability=disabled

netsh int tcp set global timestamps=disabled

 

Change CGP settings on client machine. (Usually there's no value in CGPAddress. We set 0.0.0.0 if the key was existing.)

 

HKLM\SOFTWARE\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Network\CGP\CGPAddress: "0.0.0.0"

HKLM\SOFTWARE\Wow6432Node\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Network\CGP\CGPAddress: "0.0.0.0"

 

Last but not least set this option on Terminal server:

 

netsh interface tcp set global autotuninglevel=highlyrestricted

 

On client and server, the network adapter must be rebooted after these changes. Or reboot the system;-)

 

Before I had that mousepointer problem as well (0-3 times a day). After applying these changes the issues were gone.

 

It would be great if you could share your experience with this workaround. For us it's not a real solution but at least users with heavy impact (5-8 times a day) can work again. We will get back to Microsoft for further debugging.

 

Greetings

Daniel

 

This sounds great, but for now we have opened a citrix ticket and they already confirmed that microsoft is working on a hotfix so I will first wait for this hotfix as it is an "official" approach and if it doesn't help I will try your workaround.

[Uday Bhanu1709153661]

Has anyone found hotfix from Microsoft or from Citrix? We too have this same issue :(

We have Xenapp 6.5 with HF3 on Windows 2008 R2 SP1 server.

Tested with latest Citrix reciver, but stil have the issue.

[Mbc-it Mbc-it]

Same issue here, but only one or two systems seem to get it.  One user seems to get this maybe once a day or every couple of days.  It does not seem to have anything that sets it off as far as I can tell.  I think I'll end up just getting the users a new PC or Win terminal!

[Andrew Dierks]

We are experiencing this same issue with behavior exactly as described by Daniel in post #15. Our environment is XenDesktop 7.5, published applications from server 2008R2 hosts.

[Dustin Ziesman]

Has there been any updates or official hotfixes to resolve this yet?

[Ced CR Fiemme]

Hi

We have a 3 server farm XENAPP 6.5 HRP04 in VmWare environement

 

Do some of you use Imprivata OneSign?

We have a similar problem affecting our farm but apps return responsive killing ISXAgent.exe in user session.

We are thinking about a focus lose in the app due to something... but no luck at the moment for possible solutions...

Bye

Mirco

[Fabian Wiemann]

Hi,

 

we have the same Problem.
Randomly the mouse Input are frozen.

But by remote assistance we could shadow the session and control remotely the mouse.

 

XenApp 6.5 HRP03 Windows 2008 R2

 

We use only ThinClient of the company IGEL

We installed the latest Firmware with Citrix Client 13.0.1 included.

 

Does anyone know if a Hotfix exist?

 

Many thanks for help.

 

Regards,

Fabian

[Martin Reis]

Hey Fabian,

 

the official hotfix is included now in the HRP5 for XenApp 6.5.

Unfortunately this does not help for every environment.

 

Regards

Martin

[Fabian Wiemann]

Unfortunately this does not help for every environment.

 

Oh, this isn't nice to here.

Did somebody installed HRP5 and it would be fixed or not?

[Martin Reis]

This did not work for my customers environments, but it could work in yours. The issue did not happen for some days after the patch, but some users were affected despite of the patch again.

 

The bug-ID should be LC0632. This fix has been included in hotfix XA650R04W2K8R2X64020,
This fix is included in Hotfix Rollup Pack 5 for XenApp 6.5 XA650W2K8R2X64R05 that superseeds the single patch.
 

Citrix recommends HRP5, so give it a try everybody. Open a case if it does not get better. You must install it in a test environment anyway.

[Martin Reis]

update: This combination was the solution on one customers site...

- HRP05 for XA 6.5

- https://support.microsoft.com/en-us/kb/3045171/ on XenApp-worker AND on Windows-Fatclient with latest Citrix Receiver

[Keith Snyder]

My site is running XA 6.5 with HF5 and we are starting to see this issue more and more. Does anyone have any updates on a fix for this issue? Anything I can try? Thanks.

[Jerome Poeze]

The same story here. We are starting to see this issue more and more. XA 6.5 and HFRP 5 are installed.

When this occurs the user is still able to move the mouse,but no mouseclicks are recognized.

 

When our SupportDesk takes over control of the session with TeamViewer, the mouse is responding to all inputs and everythings okay REMOTELY!

Even from then, it's still impossible for the user to click the mousebuttons.

 

The only option is to remotely logoff the user-session and let them login again.

It happens randomly and most of the time when they are working with MS Office products.

[Jerome Poeze]

The same story here. We are starting to see this issue more and more. XA 6.5 and HFRP 5 are installed.

When this occurs the user is still able to move the mouse,but no mouseclicks are recognized.

 

When our SupportDesk takes over control of the session with TeamViewer, the mouse is responding to all inputs and everythings okay REMOTELY!

Even from then, it's still impossible for the user to click the mousebuttons.

 

The only option is to remotely logoff the user-session and let them login again.

It happens randomly and most of the time when they are working with MS Office products.

 

I've found a workaround:

Disconnect the user through the Citrix AppCenter. Let the user reconnect to the session.

From then all is back to normal.

 

But this issue still needs to be fixed!

Edited November 4, 2015 by Jerome Poeze

[Preston Grant1709153401]

Our customer seems to be experiencing this problem as well, of course they are on Xenapp 6.0 with HRP2. But it seems from what ive read that even 6.5 with HRP5 is not a guaranteed solution. 

 

I will add that in our case, mouse clicks were completely unresponsive (keyboard could have been too but hadn't thought to try). Closing the users word.exe process (which they had a document open from an email attachment) allowed us to mouse click on the start menu and taskbar ONLY. It was then we realized that the keyboard input worked everywhere, but still no mouse input. We closed one program after another until finally closing outlook made the mouse jump back to life.(dont know if it was just the timing of it, but thats when it started working again)

 

Has anyone found a concrete solution to the problem? Or, a way to reproduce it on command so we can try the multiple workarounds in this thread?