Alexander Pope QuoteI was recently asked about a little-known workaround we sometimes use to overcome rare compatibility issues between our 3D driver and certain applications.

When we become aware of these issues we work as fast as possible with the 3rd party vendor to rectify the issue and ensure future versions or ours and theirs resolve the issue in whichever product (or both) the incompatibility has arisen. In the interim we sometimes use a workaround known as “blacklisting” to ensure a customer can carry on with zero downtime in production whilst we and/or the 3rd party vendor resolve the issue. As such this is a temporary measure as when the issue is resolved often in the next version of the application or XenDesktop the advice becomes redundant.

We have never published this workaround as it is intended solely as a fallback mechanism to allow a customer to continue unimpeded short-term. However, “a little knowledge” of the workaround has become semi-public and the public advice we found was limited, partial and misleading. As such we felt it was better, to give a full explanation to customers so, that they understood what they were doing and to explain some of the information available. Indeed, “A little learning is a dangerous thing”….

What does blacklisting an application do and mean?

Blacklisting an application means that when an application queries for 3D GPU support it is prevented from finding it and so will find none. Consequently the application will fall back to using and use that application’s fallback mechanism, where one exists and if no fallback mechanism exists will fail to run.

Every common Microsoft application has a fallback mechanism by virtue of them being developed for 2D technologies (GDI etc) and subsequently enhanced to be able to take advantage of 3D GPUs where available. Many other applications such as Google Chrome are similarly hardware opportunistic.  Other applications such as Google Earth will not run without 3D GPU support.

Symptoms of an interoperability issue that suggest investigating blacklisting an application may be useful

Typical symptoms of an interoperability issue may include:

  • Objects when switching between browser tabs do not repaint, or incorrect or partial repaint occurs (i.e. you observe stale data)
  • Application flickering
  • Objects fail to paint at all (missing labels on icons, blank tabs)
  • Slow application rendering and the application has a faster non-3D rendering fallback.

How to blacklist an individual application:

  1. Open task manager, applications tab, then right-click the app and select Go To Process. Note the process name, eg. “app.exe”
  2. Create a REG_DWORD registry key “app.exe” with value 0:
    • XD 7.1 and XD 7.5:
      • x86: reg add hklm\software\citrix\vd3d\compatibility /v app.exe /t REG_DWORD /f /d 0
      • x64: reg add hklm\software\Wow6432Node\citrix\vd3d\compatibility /v app.exe /t REG_DWORD /f /d 0
    • XD 7.6 both x86 and x64:
      • reg add hklm\software\citrix\vd3d\compatibility /v app.exe /t REG_DWORD /f /d 0

How to blacklist all apps at once:

  1. Open task manager, applications tab, then right-click the app and select Go To Process. Note the process name, eg. “app.exe”
  2. Create a REG_DWORD registry key “app.exe” with value 0:
    • XD 7.1 and XD 7.5:
      • x86: reg add hklm\software\citrix\vd3d\compatibility /v * /t REG_DWORD /f /d 0
      • x64: reg add hklm\software\Wow6432Node\citrix\vd3d\compatibility /v * /t REG_DWORD /f /d 0
    • XD 7.6 both x86 and x64:
      • reg add hklm\software\citrix\vd3d\compatibility /v * /t REG_DWORD /f /d 0

Wildcards are not supported. The asterisk * here has a special meaning “all apps” but is not a traditional wildcard. To blacklist multiple apps e.g. both appa.exe and appb.exe must be done by creating a registry key for each app individually.

The above commands involves setting the registry key to 0, this is a guaranteed value to blacklist the application that we sometimes advise users to use.

There are in fact other values of this key, which are reserved for internal use and development debug. These values actually can change from version to version and as such are not a workaround a customer is advised to use without advice from Citrix support and as a short term version specific workaround. However it appears that a few KB articles have been published using other values such as these:

Where the key = 8, this value and others offer our developers a fine grained control mechanism to turn off various driver mechanisms or change the hierarchy of behavior. They probably should not have been published without more background advice however now that they have been out-in-the-wild we felt it was better to explain so that any user who had applied them understood the implications, limitations and background. Any value other than 0 applies only to a particular XD release.

RemotePC – A current known issue where blacklisting may help

There is a current known interoperability issue with a few Microsoft 3D applications where blacklisting may help. When 3D applications are running and the session is then taken over from the console by a remote ica connection or vice-versa, a few of these applications can hang, owing to a failing recurrent call in the DWM trying to find a service. We are actively working on a solution to this jointly with Microsoft and as such this envisaged will be a short term issue. As such if you are reading this blog in the future, you should verify this issue even still exists.

There is in fact a workaround to un-hang the application where by a user can restart the DWM by going from the start menu to:

  • Computer->Properties->Advanced system settings

and then on the “Performance” item selecting “Settings” , then unchecking and rechecking  the checkbox item “Enable desktop composition” (see image). Between each toggle the user has to click “Apply”.

Win 7 and RDP 16bit color – A current known limitation

Our current WDDM driver has not as yet implemented 16bit color, in fact 16bit color support was deprecated by Microsoft in windows 8.x . In Windows 7 though DWM (aero) was optional and hence 16-bit color was still allowed via RDP, which means there is an interoperability gap at present. We may very well look to retrospectively introduce support for 16-bit RDP connections as we appreciate many users have long refresh and upgrade cycles. In this scenario blacklisting applications will circumvent the limitation.

Upgrading XenDesktop after blacklisting applications

As I have emphasised, this is very much a temporary workaround that we use whilst we work with 3rd party vendors to ensure interoperability via the primary driver mechanisms. As such if you have implemented this you should always review the blacklisting whenever you update the application or XenDesktop to a new version as it is very likely that the need for a workaround no longer exists. Installing a new version of XenDesktop will erase the registry key.

Known applications that may require blacklisting

If you have questions or have found applications that benefited from blacklisting please do ask questions or comment on this forum thread, here. Please do bear in mind that this is course of action that is may be appropriate to a specific issue in a specific version and patch level of a product and as such you should only investigate this if you have an issue and that information posted is community verified only rather than Citrix Support advice unless otherwise stated and should be verified in our own environment.

It is very important for us, that you do let us know if you find that this workaround is proving useful as we prioritising resolving these issues with the greatest priority. As this gives us the opportunity to investigate the need for a workaround and eliminate it. Our development, support and product teams will be keeping a close watch on this thread!

Thank you to my co-author, from HDX Engineering JulianP, for his invaluable contribution and input!