Мы создаем приложения WPF, которые будут развернуты на Citrix. В настоящее время вы просто видите синее окно под Citrix, хотя приложение работает нормально на самом сервере.
Похоже, что в сети есть некоторые проблемы.
Мы применили оперативное исправление, но, похоже, это, по крайней мере, не решает проблему для нас.
Также был обнаружен этот идентичный вопрос на этом сайте, но он был удален автором, поэтому ответов нет.
Я запускаю Citrix 4.5 на сервере Windows 2003. Я пытаюсь опубликовать приложение WPF (у любого приложения WPF есть эта проблема), и все, что я получаю, - это синий прямоугольник, на котором должно быть приложение. Прямоугольник - это точный размер и форма окна, как я ожидал, но он просто синий (похож на цвет фона рабочего стола Citrix). Любые идеи?
Это очень старый вопрос, но у меня была такая же проблема.
Я не знаю почему, но когда у меня два монитора, Citrix показывает только синее окно для всего WPF. Я решил это, отключив один из мониторов, что по какой-то причине заставило Citrix правильно отображать WPF.
Мой коллега использует ту же настройку, что и я, за исключением того, что у нас вторые мониторы разных производителей. Его настройка отлично работает с обоими мониторами.
Мы запускаем .Net 4.0 на Citrix с XP.
Я сам не сталкивался с этой проблемой, но мы испытали уменьшение глубины цвета на двухэкранных клиентах из-за увеличения использования памяти для графики сеанса.
Может быть, синий экран - это странный артефакт автоматической деградации, который Citrix включит, когда вы в противном случае превысили бы лимит графики для сеанса?
Я не уверен насчет MetaFrame XP, но насколько я помню, максимум, на который вы можете настроить ограничение графики сеанса через графический интерфейс, составляет 8,192 кб. Какая у вас настройка?
Мы увеличили наш лимит до 16 МБ через значение реестра. MaxLVBMem, чтобы иметь возможность работать с глубиной цвета 24 бита даже с двумя мониторами с разрешением 1920x1080.
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd\thin16
MaxLVBMem (REG_DWORD) = 0x1000000 (16777216 dec)
Мы также увеличили SessionViewSize от 20 до 32:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
SessionViewSize (REG_DWORD) = 0x20 (32 dec)
Наконец, мы увеличили SessionPoolSize от 32 МБ по умолчанию (в системах с> 2 ГБ ОЗУ) до 48 МБ:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
SessionPoolSize (REG_DWORD) = 0x30 (48 dec)
Как сказано в Microsoft KB840342:
MaxLVBMem в идеале должен потреблять не более 35–40 процентов выделенного системой SessionPoolSize. Если желаемый MaxLVBMem будет использовать более 40 процентов SessionPoolSize, увеличьте значение параметра SessionPoolSize.
И:
Microsoft рекомендует увеличивать этот параметр с шагом 16 мегабайт. Не рекомендуется увеличивать параметр SessionPoolSize выше 80 мегабайт.
Если MaxLVBMem (установленный на 16 МБ) должен потреблять максимум 35-40% от SessionPoolSize, это должно быть не менее 46 МБ. Это достигается путем увеличения значения по умолчанию 32 МБ до 48 МБ.
Редактировать:
Но, как указано в статье Microsoft KB, вам придется найти баланс для вашей среды. Увеличение на 16 МБ с 32 МБ до 48 МБ может оказаться недостаточным для решения вашей проблемы. Однако слишком большое увеличение значения может привести к исчерпанию пулов памяти.
Если вы выделяете больше памяти для увеличения кучи рабочего стола, вы можете уменьшить память, выделяемую сервером терминалов для других ресурсов, таких как невыгружаемый пул, выгружаемый пул и системный кеш. Это повлияет на производительность Терминального сервера. Кроме того, когда больше памяти выделяется для записей SessionViewSize и SessionPoolSize, память, выделяемая для сопоставления виртуального пространства ядра, будет уменьшена. Это, в свою очередь, может заставить Терминальный сервер поддерживать только ограниченное количество пользователей.
При этом в настоящее время мы видим признаки того, что размер SessionPoolSize 48 МБ может быть недостаточно для нашей среды, поэтому я, вероятно, протестирую с 64 МБ.
Обязательно следите за своими пулами памяти и свободными системными PTE до и после изменения :-)
Когда я снова перечитываю упомянутые статьи базы знаний, Microsoft KB840342 звучит как первое, что я бы попробовал в вашем случае.