Jump to content
  • 0

Keyboard works... but Mouseclicks aren't recognized


Markus Frenzel

Question

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

Link to comment
  • Answers 86
  • Created
  • Last Reply

Top Posters For This Question

Recommended Posts

  • 0

Hello Stephanie,

 

thanks for reading this thread!

 

I've checked the settings for the pointer scheme on my 3 Servers which build my Serverfarm. The scheme shows "None" as active scheme and the option that the mouse pointer might be changed by designs isn't checked.

 

My clients are connecting from a small variety of OSs. There are Win XP, Win Vista, Win 7 Fat-Clients and Thin-Clients with Thinstation Linux on it. The error mostly appears on a small group of the Thinclient machines. Win 7 Clients (and the other OSs) got this problem only a very few times.

 

My Thinclients are based upon Wyse 3150SE Thinclients which got only a very small ammount of RAM. I've thought that it might be caused by low RAM... but it happens even if the machine is freshly booted and connected to XenApp.

 

The Fat-Clients are running Receiver 4.0.0.45893. The Thin-Clients are showing up as Clientbuildnummer 6458 in the Delivery Services Console.

 

Any suggestions?

 

-Markus

Link to comment
  • 0

Hi Markus, 

 

Thanks for the update, can you confirm if your fat clients are running our latest receiver for windows? If not what version are on those clients? Do you have any seamless flags entered in the registry? See the hyperlink on seamless flags in prior sentence. 

 

For those that are using web interface, has anyone enabled speedscreen latency and noticed a difference in the behavior?

 

Also on the end client can you check the settings for your mouse by going to the control panel and click on mouse (prior OS versions click on hardware and sound), then click on pointers. Is there a scheme set? If so what is it. Also check to make sure there is not a check next to the box on the bottom that says allow themes to change mouse pointers (not all end clients have this setting).

 

Thanks,

Stephanie

 

Link to comment
  • 0

Hi Stephanie,

 

thanks for your help!

 

My fat clients show up in the Citrix AppCenter with a Clientbuildnumber of 91 and a Clientproduct-ID of 1. On the Client I'm able to see in the Info of the receiver the following information: Citrix Receiver Version 4.0.0.45893.

 

So I think that we are not using the latest receiver version on our fat clients... but: the problem mainly occurs on thin clients with Thinstation Linux on it and the receiver version mentioned in my post above.

 

I've set seamless flags on all of my farmservers (3 in total): Registry Value: 0x289502 (DISABLE MODALITY CHECK, DISABLE LOAD CHECK, FORCE RAW MOUSE EVENTS TO SERVER, FORCE MENU WINDOW TO HAVE OWNER, DONT SEND DISABLE, DISABLE CLIENT INFO SYNC EXCEPT WORKAREA, ALLOW AA HOOK TO HANDLE HIDE EVENTS). Additionally I've activated MS OFFICE APPS SEAMLESS TASKBAR FUNCTIONALITY and a LOGOFF CHECKER STARTUP DELAY of 16 Seconds. All of this set via the tool "FARM TWI HELPER"

 

Prior to this I've tested the seamless flags values 0x48500 and 0xC88504 but the error occurs also with this values.

 

My thin clients point to the XenApp Services-Site (PNAgent) on my Webinterface Server. Speedscreen latency is not active in the default.ica file in the conf folder of the PNAgent.

 

On the thin clients I've got no possibility to check the mouse settings because they are based on Thinstation Linux.

 

Thanks,

 

Markus

Link to comment
  • 0

We are still having the same problem:

 

Clients:

 

HP T5720

Windows XPe SP2

Online Plugin 11.2.0.31560

No mouse scheme

 

HP T5730

Windows XPe SP3

Online Plugin 12.1.0.30

No mouse scheme

 

HP T5740

Windows Embedded Standard

Program Neighborhood 11.0.0.5357

No mouse scheme

 

HP T510

WIndows Embedded Standard 2009 SP3

Receiver 3.3.0.17207 Online Plugin 13.3.0.55

No mouse scheme

 

Clients coming in remotely get Receiver 3.3.0.17207 from our storefront server

 

Seamless flag on XenApp servers = 0x400000

 

Once again, if we have all 6 nodes active in our farm (30-35 users per server) it only happens once a week or less.  If we take 3 nodes out then we will have mouse issues within 3 hours of users signing in.  The lastest receiver is not an option for us because we use custom ica files to launch published desktops and this ability is no longer available in the latest version. 

Link to comment
  • 0

Add me to the list.

 

My user is running published apps, not a full desktop. We have a thousand or so users, but the majority aren't affected. I have been dealing with one user recently who has been reporting intermittent freezing, and it's only just now I've caught it and realised the session isn't freezing - it's just stopped responding to mouse clicks.

 

It's possible that more are experiencing this issue, but are also reporting it as a frozen session.

 

Interesting things I noted:

We have a mixed environment, with a 6.5 and 4.5 farm. The user runs most of her apps from the 6.5 farm, and one legacy application from the 4.5 farm. When this issue happens, it's only the applications on the 6.5 server that stop respondng to mouse clicks - the 4.5 server is never affected. (lesson learned, stick with the end of life stuff - Citrix quality control is not what it once was  :P )

 

I used Connection Centre and disconnected the user's session on the 6.5 server, then logged back into StoreFront and her session was reconnected. After reconnecting to the existing session, the mouse clicks responded correctly.

 

Online Plug-in version is 14.0.0.91

XenApp 6.5 server is patched up to Rollup Pack 2 (I have Rollup Pack 3 in UAT - will be interesting to see if that makes a difference)

 

I'll raise a support request over this issue, but wanted to add my name to the list here.

:)

Link to comment
  • 0

Hey Tony,

 

I have a case running too. SR61198572, you could give that hint to your engineer.

 

Today this problem occurred in another customers environment, which is similar to my first one: XA65, HRP02, PVS 5 or 6, Web Interface, published apps and desktops.

 

As far as I can see I think it has to do with the published explorer.exe, that is used as a file-manager. It works, but it is not advised by citrix. I am not really sure, if it is supported. http://support.citrix.com/article/CTX922603

 

We tried to narrow this issue down to SAP, Lotus Notes or MS Office, but in every case I saw the issue myself, a published explorer was involved.

 

Are there any similarites on all the other issues?

Link to comment
  • 0

Hey Martin,

 

Irgs... we've got the Explorer.exe published as described in the mentioned support article... copied as Explorer2.exe into another directory and published this to our users.

 

I have to read this article and try the described Procedures. Maybe this is the cause of this problem...

 

Thanks for your suggestion!

 

-Markus

Link to comment
  • 0

I am having this problem sporadically myself. XA 6.5 HRP3, Windows Server 2008 R2.  Published apps.  It just happened to me working in multiple instances of Microsoft Access.  Mouse clicks no longer work within applications but I can move seamless windows around.  It's a good thing I am pretty handy with keyboard shortcuts, as I was able to close my applications gracefully.  I would love to know the cause (and especially the fix).

Link to comment
  • 0

We tried to narrow this issue down to SAP, Lotus Notes or MS Office, but in every case I saw the issue myself, a published explorer was involved.

 

Are there any similarites on all the other issues?

 

We're also a Lotus Notes house, so it's interesting to see that similarity, because it is a notoriously troublesome application. We also publish Explorer - which I know is not recommended or supported - but this particular user who is regularly experiencing this problem does not seem to use the published Explorer. The apps she generally has open are Lotus Notes, Internet Explorer, Attachmate Reflection (terminal emulator) and maybe an Office app or Adobe Reader.

Link to comment
  • 0

We are also still experiencing this issue across multiple environments, a mixture of apps and client devices (just like everyone else in this thread). Some users manage to start two sessions by erratically clicking the published desktop icon, it seems to me that those users are affected more often.

 

Xenapp 6.5 HRP3 on W2K8-R2 on Hyper-V.

Link to comment
  • 0

We are having a Citrix SR, but this issue takes long as it is hard to catch and is not reproducable.

 

Can anyone please test and comment the following steps?:

- If the mouse seems to be frozen, is it possible to connect and work with remote assistance? In other words, does a "external" mouse work, but the user inputs are not being processed?

- And how is the behaviour after the session is released, does the "user mouse" work again without taking any other Actions afterwards?

 

Thank you in advance

Martin

Link to comment
  • 0

Good morning Martin,

 

this sounds really good! Tried to install this hotfix yesterday without success. The only message I've got is "This package could not be installed" without any further information. Event viewer logs show an Event ID 3 from Source Wusa. I'm on Windows Server 2008 R2 SP1 with latest Updates installed.

 

Google doesn't give me any useful information about that.

 

So I have to fix this problem first and after that I'm trying to test this.

 

-Markus

Link to comment
  • 0

Hi Markus,

 

maybe there are pending or unfinished updates. Try "DISM /Cleanup-Wim".

(taken from here, but the syntax in that article seems to be outdated: http://support.microsoft.com/kb/947821).

 

But afterwards the update seems not to be applicable for one of my test-systems.

All servers are fully patched and the Microsoft KB2579381 is from 2011. Possibly the files were already included in former MS-patches.

 

I'll give that info to Citrix support...

 

Keep on trying :(

Martin

Link to comment
  • 0

We are having the issue now with just 1 user so far. 

 

Environment:

Users: 100

Servers: 2008 R2 all patched

XenApp: 6.5 RU3

VmWare: 5.5

Thin Clients are Wyse Zenith Pro

 

So far only the one user that is having an issue. Seems to be random. We will confirm with him if he remembers the applications running and what he is doing just prior to being unable to click the mouse.

 

As everyone has said here, the session is live, user can move his mouse, user can use the keyboard, but the mouse doesn't respond to clicks.

Link to comment
  • 0

Nothing new yet, the MS patch did not help, too. We try to catch different traces and logs when the issue occurs. Those have to be checked by Citrix support.

 

Another question was: Can a "frozen" session be controlled by Microsoft Remote Assistance and are the mouseclicks from the remote supporter processed on the frozen client device?

Link to comment
  • 0

Just had another user with this issue. We started Teamviewer (7.0) inside the session on the remote system using the keyboard, and the external mouse works perfectly!

Closing the Teamviewer session did not resolve the issue. The session had to be disconnected to free up the session for the user.

Link to comment
  • 0

Hi Stephanie,

 

this is on hold only due to easter Holidays, and testing will be taken up by end of April.

It seems to be "an never ending story". (Michael Ende) :)

 

The customer has 5 testusers on an isolated XenApp-Server, but we have to wait until the issue occurs. CDF trace and some Microsoft logs shall be taken then and be analyzed by Citrix support. -> But this issue is not reproducable.

 

I wonder why there are just a few other "official" Citrix support cases. This seems to happen to many users and since a long time.

 

I will keep you (all) updated...

Martin

Link to comment
  • 0

Hello All,

 

I am bringing this up to our dev team for further investigation. Can you please test disabling the Visual Effects on the Server side as well as the client side and tell me if that makes any difference?

 

Computer Properties ->Advanced System Settings->Performance Options->Visual Effects

 

If you have a controlled test group similar to what Martin has mentioned above, it would be easier to collect logs/narrow it down.

 

Sakthi

Link to comment
  • 0

Hello All,
 
We had been experiencing this problem for over a year but as of recent the problem no longer exists in our environment.  During this same time frame that we were experiencing the mouse clicks not being recognized issue we also experienced random high CPU problems with MS Excel and Word when users weren't actively using either program.  We had made some system changes but also made a GPO change to "Disable" the "Show preview handlers in preview pane" located in User Configuration, Preferences, Control Panel Settings, Folder Options.  Today we are no longer experiencing both the mouse click not recognized issue and the random high CPU problem with MS Excel and Word.  Something to try in your environment.
 

 

Link to comment
  • 0

Sorry I've not come back to this thread for a while, but after opening my support ticket I had a number of things suggested, mainly revolving around session reliability.

 

Since I first came across this problem and have started looking out for it, we've found more and more of our users have experienced the same thing - but previously they'd just treated it as 'Citrix has froze'.

 

So, going back to the suggestions I received from Citrix, I tried this step on an affected users machine, to disable session reliability:

 

6. Disable session reliability for the single user experiencing the issue with one of the methods below and confirm if the issue reoccurs.

Custom ICA file - http://support.citrix.com/article/CTX135450

Or client registry key - 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"

 

Since I did this, the user has not experienced the issue, whereas previously she was experiencing it multiple times a day.

 

I'm now considering turning off session reliability globally.

 

 

UPDATE: Unfortunately this affected user has experienced the issue again, so it looks like the above change made no difference.

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...