Citrix and WPF, blue window

Question

We are building WPF applications which will be deployed on Citrix. Currently you simply see a blue window under Citrix, although the app runs fine on the server itself.

There do seem to be some issues detailed on the net.

Citrix forum discussion

Microsoft hot fix

We've applied the hot fix but this does not appear to fix the problem for us at least.

Also, found this identical question on this site, but it had been removed by the author, so no answers.

I'm running citrix 4.5 on a Windows 2003 server. I am trying to publish a WPF app (any WPF app has this problem) and all I get is a blue rectangle where the app is supposed to be. The rectangle is the exact size and shape of the window I expect, but it is just blue (looks like the color of the citrix desktop background). Any ideas?

Answer 1

This is a very old question, but I've had the same problem.

I don't know why, but when I have two monitors Citrix only shows a blue window for anything WPF. I solved it by unplugging one of the monitors, which for some reason made Citrix show WPF correctly.

My colleague runs the exact same setup as I do, except our second monitors are of different brands. His setup works fine with both monitors.

We're running .Net 4.0 on Citrix with XP.

Answer 2

I haven't encountered the problem myself, but we've experienced colour depth reduction on dual-screen clients, due to the increased memory usage for session graphics.

Maybe the blue screen is a weird artifact of the automatic degradation, that Citrix will kick in when you would've otherwise exceeded your session graphics limit?

I'm not sure about MetaFrame XP, but as far as I recall, the maximum you can configure the session graphics limit to through the GUI is 8.192 kb. What is your setting?

What we did

We have increased our limit to 16 MB through the registry value MaxLVBMem, to be able to run with 24 bit colour depth, even with dual 1920x1080 monitors.

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd\thin16
MaxLVBMem (REG_DWORD) = 0x1000000 (16777216 dec)

We also increased the SessionViewSize from 20 to 32:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
SessionViewSize (REG_DWORD) = 0x20 (32 dec)

Finally, we increased SessionPoolSize from the default of 32 MB (on systems with >2 GB RAM) to 48 MB:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
SessionPoolSize (REG_DWORD) = 0x30 (48 dec)

As stated in Microsoft KB840342:

MaxLVBMem should ideally consume no more than 35 to 40 percent of a system’s allocated SessionPoolSize. If more than 40 percent of SessionPoolSize would be consumed by the desired MaxLVBMem, adjust the SessionPoolSize parameter upward

And:

Microsoft recommends raising this setting by increments of 16 megabytes. Increasing the SessionPoolSize parameter above 80 megabytes is not recommended.

If MaxLVBMem (set to 16 MB) is to consume max 35-40% of SessionPoolSize, this has to be at least 46 MB. This is accomplished by raising value from the default of 32 MB to 48 MB.

Edit:

But, as stated in Microsoft's KB article, you will have to find the balance for your environment. A 16 MB increase from 32 MB to 48 MB may not be sufficient to solve your problem. However, increasing the value too much and you risk depleting your memory pools.

If you allocate more memory to increase the desktop heap, you may reduce the memory that allocated by the Terminal server to other resources, such as nonpaged pool, paged pool, and system cache. This will affect the performance of the Terminal server. Also, when more memory is allocated to the SessionViewSize and SessionPoolSize entries, the memory allocated to map the kernel virtual space will be reduced. This in turn may make the Terminal server to support only a limited number of users.

That being said, we currently see indications, that a SessionPoolSize of 48 MB might not be quite enough for our environment, so I'll probably test with 64 MB.

Be sure to monitor your memory pools and free sytem PTE's before and after the change :-)

References

• CTX114497: How to Allow More Memory for Session Graphics on Windows Server 2003)
• CTX112539: Sessions Using Large Amounts of Memory Become Unresponsive
• CTX113497: An Improper SessionPoolSize Setting Causes Sessions to Freeze
• KB840342: Applications may not run correctly in a Terminal Services environment

As I read through the referenced knowledge base articles again, Microsoft's KB840342 sounds like the first thing I would try in your case.