Модернизация приложений
Часть 13. Платформа Windows Troubleshooting Platform
Windows Troubleshooting Platform
Графический и командный интерфейс
В предыдущей статье данного цикла мы начали знакомство с платформой Windows Troubleshooting Platform и рассмотрели ряд примеров работы системных модулей. Настоящая статья, завершающая данный цикл, посвящена архитектуре платформы Windows Troubleshooting Platform и модулей.
Архитектура платформы
Платформа Windows Troubleshooting Platform состоит из трех основных компонентов: Windows Troubleshooting Framework, приложения, выполняющегося в процессе 1, и модуля Troubleshooting Pack. Архитектура платформы показана на диаграмме, приведенной на рис. 1.
Рис. 1. Архитектура платформы Windows Troubleshooting Platform
На диаграмме обозначены границы процессов, где PowerShell выполняется в отдельном от платформы Windows Troubleshooting Platform процессе. Это сделано для обеспечения надежности и для изоляции сценариев от возможных эффектов выполнения команд и пользовательского интерфейса.
Windows Troubleshooting Platform
Как показано на диаграмме, Windows Troubleshooting Platform состоит из ядра времени выполнения (run-time engine), средства отображения результатов и отчетов, ряда специальных командлетов и ядра времени выполнения для Windows PowerShell. Когда пользователь или приложение запускает модуль, ядро времени выполнения считывает метаданные из модуля, проверяет цифровую подпись и отображает интерфейс пользователя. После этого запускается сценарий на PowerShell, который определяет наличие проблемы. Если сценарию необходимо взаимодействие с пользователем, запускаются соответствующие дополнительные командлеты.
Графический и командный интерфейс
Модули могут быть запущены как через графический интерфейс, так и из командной строки. Графический интерфейс предназначен для конечных пользователей, тогда как интерфейс командной строки чаще всего применяется администраторами.
Модуль
Модуль состоит из метаданных и набора сценариев на PowerShell, которые используются для обнаружения проблемы, ее исправления и проверки выполненных действий. Локализация осуществляется с помощью стандартных ресурсных файлов — Multiple-Language UI (MUI) resource file. Для их безопасного выполнения модули должны содержать цифровую подпись. Устройство модуля показано на диаграмме (рис. 2).
Рис. 2. Устройство модуля
Из следующего раздела мы узнаем, как создавать собственные модули с помощью специального средства, входящего в состав Windows 7 Software Development Kit (SDK).
Создание собственных модулей
Для создания собственных модулей, расширяющих возможности платформы Windows Troubleshooting Platform и позволяющих решать дополнительные задачи по настройке приложений, применяется специальный редактор, входящий в состав Windows 7 Software Development Kit. Он называется Troubleshooting Pack Builder и после установки Windows SDK обычно находится в папке %programfiles%\Microsoft SDKs\Windows\v7.0\ Bin\TSPBuilder. Обновленную версию дизайнера модулей можно загрузить с сайта Microsoft по адресу: https://connect.microsoft.com/site919.
В нашем примере мы создадим модуль, который будет решать довольно простую задачу — включение отображения строки состояния в утилите Notepad. Для того чтобы мы могли создать наш демонстрационный модуль, необходимо выполнить два подготовительных действия. Вопервых, нужно сконфигурировать PowerShell таким образом, чтобы мы могли выполнять неподписанные сценарии. Для этого следует запустить PowerShell от лица администратора (Run As Admin) и ввести следующую команду:
Set-ExecutionPolicy RemoteSigned
Вовторых, необходимо запустить сценарий TestModeSetup, который находится в том же каталоге, что и дизайнер модулей, — это позволит нам тестировать сценарии модулей в контексте PowerShell и использовать дополнительные командлеты, входящие в состав Windows Troubleshooting Platform. В PowerShell необходимо выполнить команду File → Open и перейти в каталог %programfiles%\Microsoft SDKs\Windows\v7.0\Bin\TSPBuilder, выбрать в нем сценарий TestModeSetup.ps1 и выполнить его в среде PowerShell, нажав клавишу F5.
Теперь мы готовы к созданию нашего первого модуля для платформы Windows Troubleshooting Pack. Запустим дизайнер Troubleshooting Pack Builder — TSPDesigner.exe. Выполним команду Project → New — это приведет к созданию нового проекта. На первом шаге нужно задать имя проекта — в нашем примере это будет NotepadFix. Обратите внимание на то, что по умолчанию создаваемые модули сохраняются в пользовательском профиле — в каталоге %userprofile%\documents\troubleshooting packs.
Проекты создаются в папках, соответствующих именам проекта, сохраняются в файлах с расширением *.diag и представляют собой XML-файлы с описанием свойств проекта и ссылки на сценарии PowerShell, выполняющие обнаружение проблемы, ее исправление и проверку внесенных изменений. Эти файлы используются для компиляции модуля на этапе его сборки.
В свойствах проекта мы указываем следующую информацию: название, описание и ссылку на информацию о сохранении данных. В нашем примере мы зададим следующие значения:
После этого следует выполнить команду Add New Root Cause в панели в левой части дизайнера (рис. 3). Это приведет к появлению панели, описывающей основную проблему (root cause), — здесь нам необходимо указать следующие значения:
Рис. 3. Свойства проекта
Идентификатор основной проблемы (Root Cause ID) будет применяться в сценариях на PowerShell и в тех случаях, когда модуль решает более одной проблемы, при этом он должен иметь уникальное в рамках данного модуля значение. Два других поля носят описательный характер, и их значения отображаются в соответствующих местах пользовательского интерфейса.
Элемент Root Cause имеет ряд дополнительных элементов: Troubleshooter, Resolver, Verifier и Scripts. Элемент Troubleshooter описывает характеристики процесса обнаружения проблемы, элемент Resolver — ее решение, элемент Verifier — шаги по проверке внесенных изменений, а элемент Scripts обеспечивает связь проекта со сценариями на PowerShell.
Для нашего примера для элемента Troubleshooter укажем, что повышение привилегий не требуется (Elevation = False) и что при обнаружении проблемы нет необходимости во взаимодействии с пользователем (Interactions = False). Для элемента Resolver укажем имя сценария на PowerShell — RS_EnableStatusBar и зададим значения False для опций Prompt the User, Elevation и Interactions; для элемента Verifier укажем, что проверка внесенных изменений возможна (Verifiable = True) и что для этой проверки мы будем использовать тот же сценарий, что и для обнаружения проблемы (Reuse Troubleshooter = True).
После этого можно переходить на страницу Root Cause Scripts, которая содержит ссылки на два сценария на PowerShell: Troubleshooter и Resolver. Поскольку проверка внесенных изменений аналогична определению наличия проблемы, отдельный сценарий для элемента Verifier не нужен.
В разделе Troubleshooter щелкнем по команде Edit Troubleshooter Script и в среде PowerShell введем следующий код:
$RootCauseID = “RC_StatusBarOff”
#---------------------------
# Код определения проблемы
#---------------------------
Write-DiagProgress -activity «Checking mode...»
$mode = Get-ItemProperty «Registry::HKEY_CURRENT_USER\Software\Microsoft\Notepad»
«Statusbar»
$RootCauseDetected = ($mode.Statusbar -ne 1)
Update-DiagRootCause -id $RootCauseID -detected $RootCauseDetected
Здесь мы применяем два дополнительных командлета, предоставляемых платформой Windows Troubleshooting Platform: Write-DiagProgress и Update-DiagRootCause. Командлет Write-DiagProgress используется для уведомления пользователей о выполняемых действиях и имеет два параметра: Activity, описывающий действия, и Status, описывающий состояние операции. Командлет Update-DiagRootCause служит для обновления статуса основной проблемы — обнаружена она на шаге идентификации или нет. Собственно проверка наличия проблемы сводится к обращению к записи Statusbar в соответствующей ветви реестра и определении ее текущего значения — если оно не равно 1, значит, строка состояния отключена и проблема существует.
Сохраним наш код, закроем PowerShell и вернемся в дизайнер модулей. В разделе Resolver щелкнем по команде Edit Troubleshooter Script и в среде PowerShell введем следующий код:
#--------------------------------------
# Внести необходимые изменения
#--------------------------------------
Write-DiagProgress -activity «Enabling status bar...»
$Mode = Set-ItemProperty
–path «Registry::HKEY_CURRENT_USER\Software\Microsoft\Notepad»
-name «StatusBar» -type DWORD -value 1
Здесь мы также применяем командлет Write-DiagProgress для уведомления пользователей о выполняемых действиях, а затем изменяем значение записи Statusbar в соответствующей ветви реестра. Сохраним наш код, закроем PowerShell и вернемся в дизайнер модулей. Мы успешно создали наш первый модуль для платформы Windows Troubleshooter Platform. Нам осталось выполнить команду Build → Build Pack для сборки модуля, а затем команду Build → Run для его запуска. В процессе сборки модуля будет сгенерирована тестовая цифровая подпись, которую можно использовать при создании и отладке модулей на локальном компьютере.
Запустим наш модуль и убедимся в том, что он определяет наличие проблемы (отключение отображения строки состояния в Notepad — рис. 4) и исправляет ее (рис. 5).
Рис. 4. Запуск модуля NotepadFix
Рис. 5. Результат работы модуля NotepadFix
После того как мы получили представление о том, как устроены, создаются и работают модули для платформы Windows Troubleshooting Platform, можно обратиться к стандартным модулям, поставляемым в составе операционной системы WIndows 7, и более детально ознакомиться с их работой. Напомним, что модули располагаются в каталоге %windir%\Diagnostics в соответствующих подкаталогах. Файлы сценариев PowerShell с префиксом TS_ содержат код для определения проблемы, с префиксом RS_ — код ее устранения. В некоторых каталогах также присутствуют файлы сценариев PowerShell с префиксом CL_ — в них содержится общий код, полезные функции, прототипы вызовов функций Windows API и т.п.
Заключение
В этой статье мы завершили знакомство с платформой Windows Troubleshooting Platform, которая впервые появилась в Windows 7 и служит универсальным средством для решения широкого спектра проблем, связанных с настройкой операционной системы, ее компонентов, сервисов и приложений. Напомним, что платформа Windows Troubleshooting Platform поддерживает расширяемость — разработчики могут создавать собственные модули для решения проблем, связанных с конфигурацией приложений, и распространять их по электронной почте или через соответствующие разделы вебсайтов.
 |
|
