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

XenDesktop v7.15/Windows 10 build 1803 - Window positions not retained when reconnecting to an existing session.

Frank Mazzucco




I am seeing an issue where window Window locations within a XenDesktop v7.15 CU2 session are not being retained. The issue is occurring in our Windows 10 environment, but not our Windows 7 environment. I have seen this issue a few times in the Windows 7 environment over the years, but it was either related to a Display Adapter and/or the UxPersistence key(ended up being a bug and was fixed in a CU). Neither of these appear to be the cause for the Windows 10 issue. This is happening regardless of how many monitors are in use or the endpoint where the session is being reconnected from. So basically, if I (1)launch a session from an endpoint with one monitor, (2)open a Window, (3)disconnect, (4)reconnect from the same endpoint, the Window is moved to a different location.


My question is anyone else seeing this issue?


According to Citrix, this issue is affecting ALL versions of XenDesktop(not just v7.15). I am trying to get an answer as to whether there are specific versions of Windows 10 that have the issue. We are running build 1803. I am also trying to get clarification as to whether or not the last know location is KNOWN, and is just not getting passed to Citrix from Windows. I am assuming that is the case based on the response below indicating a timing issue.


Here is my latest response from Citrix:
I was able to identify the required message(WM_SETTINGCHANGE) only generates from WIN7 box, and we don't have that message seen from WIN10. I have been checking with product team, and they shared this design was made based on fact that "WM_SETTINGCHANGE is expected to be sent by windows, this was found through testing and debugging, we don’t have any guarantee that this will always occur". Since this assumption breaks with win10 and we don’t have an effective alternative to determine the timing for window restore to happen, so we have to admit this is a design limitation. 

This is happening over ICA sessions only, it didn’t happen for win 7 because the WM_SETTINGCHANGE is generated only in Win7 and we use this flag at the type we transport graphics to the terminal. RDP or console should present this issue at all since you are directly rendering over the PC.


So far there is no way that we can fix this issue and we marked as a limitation.
I will try to put an enhancement request separetly to this case, however since this is a change made from windows I don’t think it will be considered.





Link to comment

0 answers to this question

Recommended Posts

There have been no answers to this question yet

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