citrix blog
citrix,citrix solution,citrix software,citrix system

I have two Citrix Servers set up for development and testing purposes, one running MetaFrame PS 3.0 and the other using Presentation Server 4.5 (Enterprise).

I have a WPF-based application that I deploy through Citrix with which I have encountered a problem in the following circumstances:

If I log on to my server as an administrator, using a RDP-based connection, and run the software it will work fine.

If I then log in as a restricted (’normal’) user through an ICA client (either to a desktop or straight to the published application) and run the program, I am left with a flickering screen and the mouse pointer continually centralises itself. I can only kill this process off from the client; trying to do so through an admin seems not to kill it off!

Alternatively, if were to log in to an administration account using an ICA-based client I can successfully run the software. If I then go back to my normal user log-in on the ICA client, the software will run without any of the problems previously described.

I have done a fair bit of research in to this problem (debt of gratitude to the sysinternals guys) and have found that the program will always fail while trying to determine the level of Direct3D support the system has to offer.

While determining this, Direct3D will examine the file $(WINDIR)/system32/d3d9caps.dat. It seems if the information held in this file does not relate to the current system setting it will try to regenerate it. When running under RDP, the system will generate one version of this file and another when run under ICA. In the first scenario described above that exhibits the problem, the restricted user’s ICA session still tried to generate this file but it doesn’t have the necessary permissions to do so. It seems a d3d9caps.tmp file is created first before the original is deleted and the .tmp file renamed. It is while trying to do this final step that the program will hang, continually trying to perform this action. (Amusingly, it seems D3D will create the temp file in the users temp folder if it can’t write to sys32)

Obviously, I don’t want to allow any user to update what’s in $(WINDDIR)/System32 so changing permissions on this folder isn’t an option.

I can’t dictate either that everyone should only use ICA; WPF/DirectX is used by several programs, so this program isn’t the only one that may suffer from this problem.

Further to this, it seems if the $(WINDIR)/system32/d3d9caps.dat isn’t present, an ICA-based client will not try to regenerate it; it’s only if it is there and wrong that I see the problem. Unfortunately, routinely removing this file offers no guarantees of successfully running the software for the same reasons as above - WPF/DirectX shared by many programs, any one of which may cause it to be regenerated.

So, I’ve run out of options and would like to see if anyone has anything more to suggest as possible workarounds (or preferably fixes!) for this problem. Thanks, Nick.

Unfortunately this suggestion doesn’t appear fix the problem. Regardless of whether hardware acceleration is enabled or not for WPF, the d3d9caps.dat file still gets generated and it is this that is the real cause of the problem when using WPF applications from restricted accounts.

Thanks for getting in touch,

Nick.

• keep a copy of the file in a folder like c:\d3d9
• delete it from system32
• put the following batch file in the startup folder or in the login script:

if exist c:\d3d9\d3d9caps.dat copy c:\d3d9\d3d9caps.dat “%UserProfile%\Local Settings\Application Data\*.*”.
if exist c:\windows\system32\d3d9caps.dat del c:\windows\system32\d3d9caps.dat.

the second line is not mandetory, it’s just to insure that the file gets deleted from the system32 folder. It will return an error when run by a none admin user.

So far I haven’t seen any side effects of having all users using a copy of the same d3d9caps.dat file. A programmer with WPF experience maybe able to elaborate on that.

Edited by: atrion2 on 30-Sep-2008 6:05 PM