Поиск и устранение проблем с приложениями в среде Citrix MetaFrame

Application Troubleshooting in a MetaFrame Environment
George Prado, Citrix Consulting Services, 14.09.2002

Введение

Любое приложение, сертифицированное или нет для запуска в среде MetaFrame, может потенциально вызвать проблемы при установке или использовании. Существует много причин появления таких проблем, но основные связаны со следующим:

• Неверная настройка сервера приложений
• Некорректное использование приложения
• Устаревшие приложения (DOS и 16-битные)
• Ошибки в приложениях
• Ограничения системы безопасности

Если одно из этих условий присутствует, можно будет наблюдать определенные симпотомы, обычно невозможность запуска, неожиданный крах программы, насыщение памяти, плохая производительность сеансов ICA и приложений. Некоторые из этих симптомов могут ввести в заблуждение и требуют тщательного анализа. Суть состоит в определении источника проблемы и его устранении.

Определение источника проблемы и разработка решения или обходного пути для вышеперечисленных аспектов является непростой задачей. В этом руководстве мы хотели бы предложить процесс поиска и устранения проблем как руководство для мониторинга, анализа и решения возникающих проблем. Цель этой статьи - предложить "научный метод" решения технических проблем. Этот метод широко используется учеными в попытке создать аккуратное представление о мире. В общих словах этот метод заключается в следующем:

1. Идентифицируйте проблему/вопрос. Ставьте вопрос так, чтобы на него можно было ответить. Пытаясь ответить на вопрос, соберите важную информацию
2. Сформулируйте гипотезу. Предложите решение проблемы или вопроса. Определите гипотезу так, чтобы ее можно было проверить.
3. Проверьте гипотезу. Это можно сделать двумя способами: провести эксперимент и/или провести дальнейшее расследование.
4. Соберите и проанализируйте данные. Если гипотеза не прошла проверку, ее следует отвергнуть и либо забыть, либо изменить. Измененную гипотезу следует снова проверить. Если гипотеза прошла проверку, она считается подтвержденной и ее можно принять.
5. Сделайте заключение. Это конечный шаг в построении, поддержке и подвергании сомнению теории. Научная теория - это унифицированное и самосогласующееся объяснение фундаментальных естественных процессов или феноменов, которая полностью состоит из подтвержденных гипотез.

При устранении проблем в среде MetaFrame применяются эти общие этапы научного метода. Необходим анализ поведения приложения и ассоциированных технических средств. На основе собранной информации можно сформулировать множество гипотез, а на этапе проверки отсеять неверные. Когда определены верные гипотезы, можно разрабатывать решения.

Модель процесса

Локализация неисправностей в среде MetaFrame требует системного подхода. Научный метод дает каркас для него. Очень важно решить проблему в кратчайшие сроки. Во многих случаях проблемы негативно влияют на клиентов, и чем дольше это продолжается, тем больше финансовое влияние это оказывает на клиента.

В этом разделе приведен детальный процесс, подчеркивающий важные задачи, которые помогут в эффективном устранении проблем с приложениями.

1. Установка отправной точки. Установите суть проблемы. Убедитесь, что она связана с MetaFrame. Восстановите последнее рабочее состояние и текущее состояние приложения и среды MetaFrame.
   
   
2. Понимание симптомов. Исследуйте симптомы по возможности со стороны пользователя. Исследуйте последовательность шагов, сделанных пользователем или последовательность событий, которые привели к проблеме.
   
   
3. Воспроизведение ошибки. Воспроизведите ошибку в тестовой среде.
   
   
4. Создание и проверка гипотез. Создайте списрок возможных причин, отсортируйте список по приоритету и проверьте. Здесь часто применимо "правило Оккама" - "самым правильным является самое простое объяснение".
   
   
5. Выбор подходящих средств. Найдите подходящие средства для проверки гипотез.
   
   
6. Реализация решения или обходных путей. При разработке решения или обходных путей всегда необходимо учитывать конечного пользователя и требования бизнеса. Проверьте решение на пилотной установке.
   

Каждый этап необходимо документировать и вносить в записи корректировки по мере поступления новых сведений.

Теперь рассмотрим каждый этап подробно.

1. Установка отправной точки.

Понимание контекста проблемы очень важно для избежания пустой траты ресурсов (времени, денег, технических ресурсов) при разработке решения. Четкое понимание проблемы покажет правильное направление. Очень важно восстановить последнее рабочее состояние приложения и среды MetaFrame, т.е. работало ли приложение до инсталляции некоторой версии или конфигурации MetaFrame, или некоторой версии самого приложения. Это можно установить, если в среде MetaFrame делались какие-то изменения. Кроме того, может выясниться, что проблема не связана с MetaFrame, а ее надо адресовать приложению.

Вам следует ответить на ряд вопросов:

• Возникает ли ошибка в локальной системе без MetaFrame? Если oшибка возникает при запуске приложения локально в Windows NT 4.0 Workstation или Windows 2000 Professional, это не связано с MetaFrame.
  
  
• Возникает ли эта ошибка в среде Terminal Services? Если ошибка возникает в Windows NT 4.0 TSE или Window 2000 Terminal Services без MetaFrame и с использованием клиента RDP, она не связана с MetaFrame.
  
  
• Возникает ли ошибка при базовой инсталляции операционной системы и MetaFrame? Изменения, сделанные в конфигурации сервера, могут не давать приложению нормально работать. Например, применение политик безопасности, изменение переназначения клиентских драйвов и т.п.
  
  
• В каких режимах возникает ошибка - при запуске с рабочего столя, в фиксированном окне или в цельном (seamless) окне? Режим запуска приложения может вляиять на его поведение. Например, старые приложения GUI могут испытывать проблемы при запуске в seamless, поскольку способ управления такими окнами отличается от обычного. С другой стороны, эта проблема не должна возникать при запуске с рабочего стола или в фиксированном окне.
  
  
• Какова история изменений, сделанных в среде MetaFrame? Возможно, какое-то изменение или кумулятивные изменения вызвало появление ошибки. Сюда входят модернизация аппаратного обеспечения, изменения сетевой конфигурации, пакеты обновлений, заплаты, изменения кода приложения и т.п.
  

Не идите дальше, не ответив на эти вопросы. Когда основная информация собрана, становится ясен контекст среды MetaFrame, где возникает проблема. Следующим шагом является попытка детально понять симптомы проблемы.

2. Понимание симпотомов

Определение значимых симптомов и правильная их оценка чрезвычайно важны для решения проблемы. Оцените симптомы со стороны пользователя. Определите последовательность шагов, сделанных пользователем или последовательность событий, которые привели к возникновению проблемы. Наблюдайте в прцессе за поведением приложения. Решите, нужны ли дополнительные исследования, которые могут потребовать средств мониторинга и отладки.

Приложение может давать один или несколько симптомов. Одни могут вести к корню проблемы, другие - мнимые и требуют дополнительного исследования, а третьи вообще не связаны с проблемой.

Вам следует ответить на следующие вопросы:

• Что делал пользователь перед возникновением проблемы?
  
  
• Наблюдал ли пользователь при использовании приложения что-то необычное? Например, вяло работающее или зависшее приложение.
  
  
• Получил ли пользователь какое-нибудь сообщение об ошибке?
  
  
• Может ли пользователь воспроизвести ошибку?

3. Воспроизведение ошибки

Важно попробовать повторить появление ошибки. Это гарантирует, что будущие исследования не окажут негативного влияния на промышленную среду. В некоторых случаях нельзя создать тестовую среду, способную воспроизвести проблему из-за разницы между рабочей и тестовой средой, разницы в настройках и пр.. В такой ситуации создайте изолированную тестовую среду внутри рабочей, например, выделенный сервер MetaFrame в рабочей среде.

4. Создание и проверка гипотез

Гипотеза предлагает вариант ответа на вопрос. Может быть несколько гипотез, объясняющих проблему. Разрабатывая гипотезы, располагайте их с порядке наибольшей вероятности. Вот примеры гипотез:

• Утечка памяти или ресурсов
• Проблема, связанная с настройкой системы или приложения
• Проблема с сетью
• Проблема с DLL
• Проблема с правами доступа
• Проблема с реестром.

На основе составленного списка гипотез сформулируйте тесты, необходимые для проверки их верности, выберите подходящие средства мониторинга и отладки, и выполните необходимые тесты. В процессе проверки может выявиться источник проблемы. Тогда следующим шагом станет разработка решения. В некоторых случаях корень проблем определить сложно, и можно предпринять обходные пути.

5. Выбор подходящих средств

Поиск и выбор подходящих средств важно для быстрого устранения проблемы. Хороший инструмент даст не только информацию, необходимую для дальнейшего движения вперед, но и может служить средством для воспроизведения проблемы. Например, проблема может возникать только при превышении определенного уроавня нагрузки на сервер MetaFrame. Тогда для имитации нагрузки можно использовать Citrix Server Test Kit.

При определении подходящего средства используйте следующий набор критериев.

• Простота. Простые средства, как правило, более аккуратные и легкие в использовании. Избегайте средства, дающие большой объем ненужной информации или привносящие нежелательные компоненты в системную конфигурацию.
  
  
• Функциональность. В зависимости от исследуемой проблемы или доказанной гипотезы, выберите средство, способное выдать нужную вам информацию. Например, хотя утилиты мониторинга файлов помогут выявить проблемы с базами данных, трассировка ODBC может дать более лучшую информацию.
  
  
• Скорость. Вам необходимо в кратчайшие сроки устранить неисправность. Выбирайте средство, которое можно быстро установить, легко собрать/разобрать.
  
  
• При прочих равных условиях более знакомое средство даст вам результаты быстрее, чем незнакомое. Средства, основанные на схожих технологиях, платформах, языках программирования также улучшают продуктивность работы.
  
  
• Стоимость. По возможности используйте бесплатно распространяемые средства. Например, вы можете использовать бесплатный Citrix Server Test Kit для определения пользовательской нагрузки. Однако, другие средства могут требовать лицензирования. Рассмотрите все средства, лицензированные вашей компанией, на предмет возможности использования для тестирования (SMS, Visual Studio, HP OpenView)

6. Реализация решений или обходных путей

Выбор правильного решения не всегда очевиден и должен быть предварительно тщательно проверен на основе требований клиента. Попытайтесь получить технические требования до предложения рекомендаций и разработки списка рекомендованных решений или обходных путей. Привлеките лиц, ответственных за принятие решений, в процесс выбора решения, чтобы это решение вписывалось в существующую среду. Если прямого решения не найдено, могут быть применены обходные пути. Например, проблема связана с изменением кода приложения, а исходные тексты недоступны. Кроме того, кратковременные решения или обходные пути необходимы в случае если долговременные решения невозможно немедленно реализовать. Иногда приемлимым обходным маршрутом является ничего не делать.

Решение должно быть проверено в тестовой среде, в том числе на предмет отсутствия нежелательных побочных эффектов. Избегайте внедрения решения в рабочую среду без тщательного его тестирования. Убедитесь, что у вас есь план отката в случае возникновения нежелательных эффектов от реализации решения.

Ниже приведены некоторые пожелания при выставлении рекомендаций

• Время. Решение нужно внедрить как можно быстрее
  
  
• Бюджет. Время на внедрение стоит денег.
  
  
• Администрирование. Частью рекомендаций может быть требования ответственности за поддержание системы.
  
  
• Производительность. Решение может негативно повлиять на производительность приложения или системы.
  
  
• Масштабируемость. Решение может не масштабироваться для удовлетворения потребности клиента.
  
  
• Надежность. Решение не может быть достаточно надежным, пока поступают жалобы от клиента.

Наиболее общие проблемы с приложениями

В приложених, сертифицированных или нет для MetaFrame, иногда возникают проблемы вследствие способа их разработки и способа установки и настройки в среде MetaFrame. При возникновении проблем обычно возникают следующие симптомы:

• Приложение не запускается или не инициализируется
• Приложение ненормально себя ведет
• Приложение или сервер неожиданно завершает свою работу
• Низкая производительность приложения или сервера
• Отключаются сеансы ICA
• Сеансы ICA работают медленно
• И еще

Эти симптомы требуют дальнейшего исследования для выяснения источника проблемы. Сначала нужно определиться, с чего начать. Есть пять технических областей, требующих исследования: ресурсы, настройки, безопасность, сеть, seamless-окна MetaFrame.

Ресурсы

Любое чрезмерное или некорректное использование системных ресурсов может вызвать падение производительности приложений и серверов, и в некоторых случаях даже к их краху. С ресурсами ассоциированы следующие компоненты: процессор, память, диск, сетевой интерфейс, файл подкачки, файлы и пр. Наиболее часто встречаются следующие проблемы:

• Утечка памяти. Это частая ошибка программ, написанных на C/C++, когда занимаемая динамическая память не освобождается после ее использования. Эта же проблема может возникать с программами, написанными на других языках, например Java или Visual Basic, поскольку они используют DLL, обычно написанные на C/C++. Со временем программе становится не хватать памяти, что приводит к сбоям в ее работе. Иногда программа продолжает работать, но очень медленно.
  
  
• Нехватка памяти. Это общая проблема в многопользовательской среде типа Windows 2000 Terminal Services, когда не хватает объема физической памяти и размера файла подкачки, или когда одновременно запущено слишком много приложений. Эта проблема возникает также при запуске интенсивных приложений, монопольно использующие ресурсы памяти сервера. В большинстве случаев это приводит к медленной работе приложений из-за интенсивной подкачки. В худшем случае приложение может не запуститься.
  
  
• Ограничение ресурсов. Операционная система и разнообразные приложения обычно имеют педконфигурированные ограничения ресурсов, такие как число открытых файлов, число открытых сетевых соединений, размер кучи GDI и т.п. Эти ограничения относятся как серверу, так и к отдельным процессам. В обоих случаях, при достижении лимита приложение может не запуститься.
  
  
• Конфликт ресурсов. Приложения борются друг с другом за общие ресурсы. Процессоры, диски, память, реестр являются ресурсами общего доступа для приложений. В многопользовательской среде файлы, память, сетевые соединения совместно используются несколькими копиями одного и того же приложения. При конкурентном использовании ресурсов одно или несколько приложений работает медленно и часто испытывают тайм-аут при доступе к целевому ресурсу.

Для выявления причин прежде всего определите, какой именно ресурс используется чрезмерно или некорректно. Часто это бывает сложно сделать, поскольку активно используется несколько ресурсов, но часть из них - всего лишь побочные эффекты. Например, если наблюдается активное использование файла подкачки и высокое использование CPU, причина может заключаться в нехватке физической памяти в системе или приложение имеет серьезную утечку памяти. Для мониторинга ресурсов в Windows 2000 есть два средства: Task Manager (taskmgr.exe) и Performance (perfmon.msc). Эти средства легко использовать и, как правило, они являются первым, что следует использовать для выяснения причин.

Следующий шаг заключается в более пристальном исследовании приложения путем анализа логов, трассировки и/или отладки. Некоторые приложения позволяют включить журнализацию/отладку. Подсистемы, интегрированные в некоторые приложения, имеют собственные средства отладки, например, для отладки приложений ODBC можно использовать ODBCTrace.

Также полезны такие инструменты, как профилировщики производительности и индикаторы утечки памяти. Они позволяют выявить специфическую функцию в прикладной программе, вызывающую утечку памяти. Кроме того, профилировщики выдают отчет о производительности каждой функции прикладной программы. Например, Rational PurifyPlus (www.rational.com) позволяет анализировать производительность и утечки памяти в исполняемой программе.

Иногда единственным способом определить источник проблемы является пошаговый прогон программы в отладчике с исходным текстом.

Проблемы с конфигурацией

Сюда относятся пролемы, связанные с тем, каким образом инсталлированы и настроены приложения и сервер MetaFrame. Они включают:

• Некорректная инсталляция. Все приложения, инсталлируемые на сервере MetaFrame, должны пройти специальную процедуру инсталляции. Перед установкой сервер должен быть переведен в режим инсталляции приложений. Это делается командой change user /install. После инсталляции сервер должен быть переведен в рабочий режим командой “change user /execute”. Это очень важно для приложений, хранящих свои данные в реестре. Подробнее см. статью CTX436352. В некоторых случаях приложению требуется дополнительная настройка для работы его в многопользовательской среде. Это достигается созданием скриптов совместимости для этого приложения. Это важно для старых приложений, изначально не расчитанных на многопользовательскую среду. В библиотеке MSDN есть статья "Developing Application Compatibility Scripts with Windows NT 4.0". Также в документации к Citrix Installation Manager есть документ "Application Compatibility Guide for MetaFrame XP Feature Release 2", в котром перечислены приложения, проверенные Citrix. Для проверки инсталляции воспользуйтесь regedit и regedt32 для проверки ключей реестра, ассоциированных с приложением. В некоторых случаях утилиты filemon и regmon (www.sysinternals.com)помогут отследить обращение приложения к файлам и реестру.
  
  
• Пакеты обновлений и заплаты. Приложения могут требовать определенной версии каждого из используемых компонентов, включая операционную систему и ее компоненты. Если не применить соответствующие пакеты обнослений или заплаты, приложение может работать некорректно. Всегда проверяйте требования приложения.
  
  
• Зависимые подсистемы. Некоторые приложения могут требовать определенные версии следующих компонентов, иначе не будут работать: Oracle Client, Novell Client, MDAC, COM+ Client и т.д. В других случаях эти подсистемы могут не быть специально настроены для приложения. Несколько приложений, установленных на одном сервере MetaFrame, могут требовать разных версий этих подсистем, что в некоторых случаях невозможно реализовать. Разделение таких приложений по разным серверам MetaFrame позволяет каждому приложению использовать соответствующую версию нужной подсистемы.

Аспекты безопасности

Аспекты безопасности не связаны с приложениями, это нежелательные побочные эффекты от настройки безопасности. Наиболее общим подходом в этом случае является ослабление чрезмерной настройки безпасности. Наиболее часто всречающиеся проблемы:

• Доступ к файловой системе и реестру. Запретительные ограничения NTFS могут мешать приложеням манипулировать нужными файлами и ключами реестра, что приводит к сбоям в работе. Многие приложения генерируют понятные сообщения об ошибке, когда сталкиваются с такой ситуацией. Однако, другие приложения не сообщают ничего, требуя исследования своего поведения утилитами regmon и filemon.
  
  
• Групповые политики. Групповые политики определяют, как программы, сетевые ресурсы и операционная система должны себя вести для пользователей и компьютеров организации. Политики конфигурируются как Объекты групповых политиков в Active Directory и затрагивают компьютеры и пользователей путем добавления, удаления и изменения отдельных значений реестра Windows 2000. Подробнее об этом читайте в MSDN.
  • Учетная запись (Account). Содержит политику пароля и блокировки пользователя
  • Локальный компьютер (Local Computer). Содержит политики управления правами, назначенными учетным данным пользователей и их группам, включая время принудительной разрегистрации.
  • Системные службы (Systems Services). Содержит политики, управляющие режимом запуска служб Windows 2000 и предоставления прав этим службам.
  • Реестр (Registry). Содержит политики, предоставляющие администраторам полный контроль над ключами реестра.
  • Файловая система (File System). Содержит политики настройки безопасности для файлов и папок, аудит файлов и папок.
    
    Подробнее см. в статье Microsoft Q250842 - Troubleshooting Group Policy Application Problems
    
    
• Групповые привилегии. Учетные записи пользователей связаны с групповыми привилегиями. При входе пользователя в систему его действия ограничены групповыми привилегиями. Поэтому когда пользователь запускает приложение, и пользователь, и приложение должны удовлетворять ограничениям.

Проблемы с сетью

Сетевые приложения, например, веб-приложения, клиент-серверные, распределенные базы данных могут испытывать проблемы с сетевыми соединениями, например, невозможность установить соединение с удаленным компонентом, или нестабильное соединение. Наиболее частые проблемы:

• Запуск приложения. Приложение не может соединиться с удаленным компонентом и завершает свою работу на этапе запуска или плохо работает. Это может быть вызвано неверными адресами IP или именами хостов, номерами портов. Используйте средства администрирования приложений и проверьте файлы настройки. Используйте утилиты ping, tracert и netstat из комплекта Windows 2000 Server.
  
  
• Роутер и защитный экран. Приложения не смогут подключаться к удаленным компонентам, если неверно настроены роутер и защитный экран. Неоторые приложения требуют открытия на защитном экране определенных портов. В некоторых случаях роутер может не иметь информации о пути доставки запроса на соединение к удаленному компоненту. Общие средства локализации проблемы - утилиты ping, tracert, netstat и telnet из комплекта Windows 2000.

Проблемы с Seamless-окнами

Многие старые приложения GUI (DOS и 16-битные приложения) сталкиваются с проблемами при запуске в seamless-режиме, но нормально раболтают в обычном окне или в полноэкранном режиме. В seamless-режиме окна управляются другим способом; каждое верхнее видимое окно на сервере представляется как отдельное верхнее видимое окно на клиенте. Клиент ICA должен управлять несколькими окнами сеанса ICA, прикладывая всякие фишки типа заголовка, кнопок сжать/растянуть, кнопки выхода... Обычно проблемы с GUI в seamless-окнах возникают при использовании недокументированных режимов окон в программах.

Инструменты

Как уже говорилось, выбор подходящего средства является ключом к быстрому и эффективному решению проблемы. Ниже содержится таблица наиболее распространенных средств диагностики и анализа приложений.

Инструмент	Назначение	Источник
Computer Management – System Information	Генерирует детальное описание конфигурации системы	В составе Windows 2000 Server
DDE Spy/Spy++	Графическое представление потоков, процессов, окон, сообщений	Microsoft Visual Studio
Dependency Walker (depends.exe)	Перечисляет все DLL, используемые процессом, включая версию и размещение	Microsoft Visual Studio
Dr. Watson	Трассировка стека и необработанных исключений	В составе Windows 2000 Server
Event Viewer	Журнал событий Windows	В составе Windows 2000 Server
GDI Explorer	Мониторинг использования GDI каждым процессом	Внутренняя утилита Microsoft. Обратитесь за ее получением к ним.
GPO Tool	Проверка доступности контроллера домена с клиента	Windows 2000 Resource Kit
Gpresult	Выводит информацию о том, какое влияние оказывает примененная политика на компьютер и пользователя	Windows 2000 Resource Kit
Handle	Выводит список файлов, открытых каждым процессом в системе	http://www.sysinternals.com/
Listdlls	Выводит список DLL, используемых каждым проессом, включая версию и размещение	http://www.sysinternals.com/
Microsoft Visual Studio 6.0	Интегрированная среда разработки Microsoft, предназначенная для разработки программ на C/C++, Java, VB и пр. Содержит необходимые средства отладки.	http://www.microsoft.com
Netstat	Выводит статистику протокола tcp/ip и текущие соединения	В составе Windows 2000 Server
ODBC Trace	Пишет в журнал последовательность вызовов функций ODBC	В составе Windows 2000 Server
Performance Monitor	Мониторинг производительности	В составе Windows 2000 Server
Ping	Проверяет доступность связи через сеть удаленных устройств	В составе Windows 2000 Server
Rational PurifyPlus	Профилировщик производительности и утилита определения утечки памяти	http://www.rational.com/
Regmon/Filemon	Выводит информацию о попытках доступа к файлу/реестру	http://www.sysinternals.com/
Secedit	Используется для анализа безопасности	В составе Windows 2000 Server
Task Manager	Счетчик использования CPU, памяти, дисков и т.п. в реальном времени. Также выдает список всех процессов.	В составе Windows 2000 Server
Telnet	Виртуальный терминал, который можно использовать для проверки открытости порта tcp/ip	В составе Windows 2000 Server
Tracert	Утилита трассировки маршрута TCP/IP	В составе Windows 2000 Server
WMI	Запрос и установка информации о настольных системах, приложениях, сетях и пр. компонентах через программный интерфейс	В составе Windows 2000 Server
Wngdbg	Отладчик	Windows Debugging Tools

Пример

В нашем примере CCS, Microsoft Consulting и Acme работали над проблемой с одним приложением. Компания Acme включала в себя разнообразные ресурсы из сетей, приложений, Windows 2000 и MetaFrame.

Суть проблемы

Acme столкнулась с ошибкой при использовании их приложения Winbroker в MetaFrame, что вызывало сообщение об ошибке "Not enough System Resources to create window." ("Недостаточно системных ресурсов для создания окна"). За ошибкой следовал крах программы. Также наблюдалась другая проблема, при которой в Winbroker постоянно создавались ресурсы GDIObject при генерации отчета.

Отправная точка.

Acme установила последнюю версию своего клиент-серверного приложения под названием WinBroker. WinBroker разработан с использованием Centura TeamDeveloper и Gupta SQLWindow, и далее подогнана с использованием языка SQLWindows. Версии TeamDeveloper и SQLWindows были не сертифицированы для работы под Windows 2000 Terminal Services или MetaFrame, а продавец не поддерживает приложения на этих платформах. В Acme есть несколько версий приложения WinBroker, лишь в последнем замечена такая проблема.

Среда MetaFrame состоит из Windows 2000 Server SP2 и MetaFrame XP Feature Release 1. Приложение опубликовано через NFuse 1.61 с Project Columbia. Кроме того, для связи с удаленным офисом через интернет используется Citrix Secure Gateway.

На рабочем столе Windows 2000 эта проблема не возникает. Она также не возникает в среде Terminal Services при использовании клиента RDP и при запуске с рабочего стола или в фиксированном окне MetaFrame. Acme не может последовательно воспроизвести ошибку.

Понимание симптомов.

После исследований стало понятным, что фактически существуют две разные проблемы. Постоянное выделение ресурсов GDIObject происходит при открытии в приложении диалогового окна. GDIObjects продолжает выделяться, когда эти окна (т.е. окна Report Progress Bar и Winbroker login) остаются открытыми, и объект не удаляется при закрытии окон. Количество объектов GDIObjects могло лекго подскочить до 9000 за короткий промежуток времени. Когда их количество достигало порогового значения, приложение генерировало ошибку “Not enough System Resources to create window”.

Во время исследований Microsoft предоставил утилиту GDI Explorer для детального анализа ресурса GDI. Это позволило выяснить, что однажды при открытии в WinBroker окна диалог стал постоянно генерировать картинки, что вызвало потоянное предоставление ресурсов GDI. Разрабочик был извещен о таком поведении. К настоящему времени причина этого неизвестна.

Воспроизведение ошибки

До визита в CCS, Acme была проинструктирована попробовать повторить ошибку. Все задачи выполнялись при использовании Task Manager для мониторинга потребления ресурсов GDI в WinBroker и ассоциированным сеансом. Использовался тестовый сервер.

WinBroker проверен в Terminal Services через сеанс RDP и ошибка не возникала. Также WinBroker был проверен в рабочем столе MetaFrame и в фиксированном окне, и ошибка тоже не возникала. В обоих случаях потребление GDI оставалось стабильным. Но как только WinBroker был опробован в “seamless”-окне, как ошибка появилась.

Создание гипотез

CCS и Acme обсудили результаты и разработали следующие шаги:

1. Проверить - нет ли в коде утечки памяти; если оно предоставляет память для картинок. Разработчик просмотрел код и не нашел логики, постоянно генерирующей картинки. На основании имеющихся симптомов он воспользовался происком в интернет и нашел решение - передавать опцию WM_QUERYDRAGICON при создании диалоговых окон в WinBroker. Была применена предложенная заплата, которая, кажется, решила проблему.
2. Проверить - нет ли заплат для seamless-окон. Консультанты CCS были знакомы с проблемой seamless-окон и обратились к своим внутренним ресурсам за заплатами. В одной из статей они нашли, как добавить обработку исключений в реестр.
3. Проверить - не вызвана ли эта ошибка каким-нибудь пакетом обновлений или заплатой от Citrix или Micrososoft. Но ничего не ставилось.
4. Проверить - правильные ли используются версии DLL. CCS вместе с Acme проверили версии DLL и убедились, что они правильных версий.
5. Проверить - влияет ли настройка ICA (глубина цвета, разрешение, размер графического буфера). Положительных результатов получено не было.

В результате выяснилось, что фикс #1 вылечил проблему.

Выбор инструментов

Сначала использовался Task Manager для наблюдения за использованием GDI; perfmon не использовался поскольку он не может отследживать GDI. Однако, далее потребовалась более подробная информация о потреблении GDI. Microsoft предоставил более продвинутую утилиту GDI explorer.

Внедрение решения

Вначале решение было внедрено на пилотной установке и проверено настоящими пользователями. Это потребовало пару дней. Затем необходимые изменения были сделаны в оставшемся коде приложения.

Возврат