Microsoft Windows Vista. Механизмы обеспечения надежности приложений

Часть 2. Restart Manager

Алексей Федоров

Механизм Restart Manager

Restart Manager и программы установки приложений

Примеры

Дополнительные механизмы обеспечения надежности

Заключение

В предыдущей части данной статьи (см. КомпьютерПресс № 1’2007) мы начали рассмотрение ряда механизмов обеспечения надежности приложений, реализованных в новой версии операционной системы Microsoft — Windows Vista. Мы обсудили механизм Windows Feedback Platform, позволяющий компаниям-разработчикам централизованно получать данные о сбоях в приложениях и на основе анализа этих данных выпускать обновления, которые будут распространяться среди пользователей с помощью средств, реализованных в Windows Vista. Еще один механизм обеспечения надежности приложений — это набор программных интерфейсов и компонентов ядра операционной системы, известный под названием Restart Manager. Данный механизм может использоваться как программами установки (инсталляторами) для снижения необходимости перезагрузок операционной системы за счет отслеживания занятых приложениями ресурсов и перезапуска приложений, так и непосредственно прикладными программами для обеспечения возможности восстановления после сбоев и восстановления данных.

Механизм Restart Manager

В основе механизма Restart Manager лежат две функции. Вызов функции RegisterApplicationRestart() позволяет вашему приложению перезапуститься после сбоя и отсылки отчета о произошедшем сбое (используя рассмотренные ранее механизмы Windows Feedback Platfrom), таким образом обеспечивая пользователю возможность продолжить работу. Вызов еще одной функции из состава Restart Manager — RegisterApplicationRecoveryCallback() — позволит вам указать ядру Windows Vista, какую функцию вашего приложения нужно вызывать перед непосредственным перезапуском приложения — следовательно, у вас появляется возможность сохранения данных с их последующим восстановлением после перезапуска приложения.

При вызове функции RegisterApplicationRestart() указывается командная строка, применяемая для повторного запуска приложения, — таким образом, используя опции командной строки, параметры или другие способы, вы можете указать приложению на то, что оно запускается после сбоя, и инициировать процесс восстановления данных.

Функция RegisterApplicationRecoveryCallback() задает точку входа в приложение, которая вызывается ядром операционной системы после сбора данных, необходимых для генерации отчета о произошедшем сбое. При получении управления приложение должно попытаться сохранить данные на диске. В процессе сохранения данных необходимо вызывать функцию RecoveryInProgress() приблизительно каждые 5 с для того, чтобы операционная система помнила о том, что приложение находится в процессе сохранения данных, — в противном случае ядро операционной системы сочтет приложение зависшим и принудительно завершит его выполнение. Это необходимо в тех случаях, когда попытка сохранения данных приводит к дополнительному сбою в приложении и появляется возможность «зацикливания» обработки сбоев. По завершении сохранения данных вызывается функция RecoveryFinished().

Сигналом для завершения работы Windows-приложения является получение сообщений WM_QUERYENDSESSION и WM_ENDSESSION со значением параметра LPARAM, равным ENDSESSION_CLOSEAPP (0x1).

Консольные приложения должны проверять нажатие комбинации клавиш Ctrl+C. Ниже показан пример обработчиков событий для Windows-приложения и консольного приложения.

//—————————————————————-

// Windows-приложение

//—————————————————————-

...

hr = RegisterApplicationRestart(CommandLineParameter, NULL);

...

switch(message)

{

 case WM_QUERYENDSESSION:

 {

 //

 // Принудительное завершение приложения

 //

  if(lParam & ENDSESSION_CLOSEAPP)

  {

    //Сохранение данных, состояния приложения

    hr = SaveData();

  }

  // Выход из обработчика событий

  return 1;

 }

case WM_ENDSESSION:

 ...

//—————————————————————-

// Консольное приложение

//—————————————————————-

BOOL ControlHandlerRoutine(DWORD ControlEvent)

{

switch(ControlEvent)

{

//

// Принудительное завершение приложения

//

case CTRL_C_EVENT:

{

TerminateRequest = TRUE;

return FALSE;

}

...

Соответственно код, сохраняющий данные, может выглядеть так:

HRESULT SaveData()

{

// Создать временный файл

uReturnValue = GetTempFileName(PathBuffer,”~rm”,0,RecoveryFile);

// Создать файл для сохранения данных

FileHandle = CreateFile((LPTSTR)RecoveryFile,...);

// Получить размер буфера редактора

TextBufferLength = GetWindowTextLength(EditControlHwnd);

// Скопировать текст из редактора во временную строку

GetWindowText(EditControlHwnd, TextBuffer, TextBufferLength+1);

// Сохранить содержимое строки в файле

Result = WriteFile(FileHandle, TextBuffer,

TextBufferLength+1, &NumberOfBytesWritten, NULL);

}

Restart Manager и программы установки приложений

Как мы уже отмечали, механизм Restart Manager должен использоваться программами установки приложений для предотвращения лишних перезагрузок операционной системы. Указанная функциональность базируется на нескольких функциях, реализованных в рамках механизма Restart Manager; (табл. 1).

Таблица 1. Функции, реализованные в рамках механизма Restart Manager

Работа с Restart Manager начинается с создания новой сессии через вызов функции RmStartSession() — все последующие операции выполняются в рамках этой сессии. Для одной учетной записи поддерживается до 64 одновременно открытых сессий Restart Manager.

При необходимости расширенные скрипты инсталляционного пакета (custom actions) могут подключиться к уже существующей сессии — для этого применяется функция RmJoinSession(). После того как сесссия создана, необходимо зарегистрировать ресурсы в рамках данной сессии с помощью функции RmRegisterResources(). К ресурсам относятся файлы, описываемые их полными именами, а также процессы, идентифицируемые через PID и время создания процесса, и сервисы, описываемые их именами. Кроме того, имеется возможность регистрации ресурсов, описанных структурой RM_UNIQUE_PROCESS.

Функция RmGetList()возвращает список приложений и сервисов, применяющих зарегистрированные ресурсы в виде массива структур RM_PROCESS_INFO. Она базируется на расширенной функциональности Windows Vista/Longhorn Server, позволяющей определить процессы, использующие те или иные файлы. Эта функциональность позволяет определить DLL, файлы данных и файлы, отображаемые в области памяти (memory mapped files). Также имеется возможность идентифицировать сервисы внутри службы svchost, применяющие необходимые нам файлы. Процессы подразделяются на «видимые» GUI-приложения, «невидимые» GUI-приложения, сервисы, консольные приложения, Windows Explorer, критичные процессы и процессы неизвестного типа. Типы процессов описаны структурой RM_APP_TYPE (табл. 2).

Таблица 2. Типы процессов, описанные структурой RM_APP_TYPE

Кроме того, функция RmGetList() позволяет автоматически определить необходимость в перезагрузке процесса.

Функция RmShutdown() использует те же нотификационные механизмы и протоколы, что и системная функция завершения процессов:

• Windows-приложения получают сообщение WM_QUERYENDSSION и сообщение WM_ENDSESSION с параметром LPARAM со значением ENDSESSION_CLOSEAPP;
• Windows-приложения, написанные для предыдущих версий операционной системы, получают сообщение WM_CLOSE;
• сервисы завершаются через команды Service Control Manager. При этом учитываются зависимости, которые могут существовать и между сервисами;
• консольные приложения получают сообщение CRTL_C_EVENT.

Приложения, идентифицированные как критичные для обеспечения работоспособности операционной системы, не могут быть завершены принудительно. Среди возможных опций отметим возможность принудительного завершения приложения и сервисов, которые завершились с ошибками, а также возможность завершения только приложений, зарегистрированных в Restart Manager.

Перезапуск приложений и сервисов выполняется с помощью функции RmRestart(), повторно запускающей приложения и сервисы, работа которых была завершена с помощью функции RmShutdown(). Windows-приложения и консольные приложения перезапускаются посредством командной строки, указанной при их регистрации с помощью функции RegisterApplicationRestart(). Сервисы перезапускаются с помощью Service Control Manager; все сервисы, которые зависели от перезапускаемого сервиса и были принудительно завершены вместе с ним, также перезапускаются. Приложения, которые поддерживают автоматическое сохранение своего состояния и данных (например, приложения, входящие в состав Microsoft Office 2007), автоматически восстанавливают свое состояние. Для перезапуска приложений после рестарта операционной системы используется функция InitiateShutdown() с флагом SHUTDOWN_RESTARTAPPS — ее действие распространяется только на приложения, зарегистрированные в Restart Manager.

Открытая сессия Restart Manager завершается вызовом функции RmEndSesion().

Программа установки приложений Microsoft Windows Installer (MSI) версии 4.0 поддерживает механизмы Restart Manager автоматически. Для программ установки, создаваемых собственными средствами, потребуется использование описанных ранее функций. Приведем пример такого применения функций:

// Начать новую сессию

RmStartSession(&dwSessionHandle, sessKey);

// Зарегистрировать элементы, которые должны быть

// установлены, заменены, обработаны и т.п.

RmRegisterResources(dwSessionHandle,

nFiles, rgsFiles,     // Файлы

nProcs, NULL,         // Процессы

nServices, rgsServices // Сервисы

);

// Получить список приложений и сервисов, которые используют

// ранее зарегистрированные файлы

RmGetList(dwSessionHandle, &nProcInfoNeeded,

&nAffectedApps, rgAffectedApps, &bRebootNeeded);

// Завершить работу приложений и сервисов, которые используют

// нужные нам файлы

RmShutdown(dwSessionHandle, 0, NULL);

// Выполнение операций над устанавливаемыми файлами

// Перезапуск приложений, которые мы принудительно завершили

RmRestart(dwSessionHandle, NULL);

Выше мы рассмотрели основные функции, относящиеся к механизмам Restart Manager. Помимо этого есть ряд дополнительных функций, которые приведены в табл. 3.

Таблица 3. Дополнительные функции, относящиеся к механизмам Restart Manager

Примеры

В состав Windows Vista SDK включен пример использования механизмов Windows Error Reporting, в котором показано, как зарегистрировать приложения для его последующего восстановления, приложение для его перезапуска, а также как зарегистрировать файл и блок памяти. Данный пример можно найти по адресу: c:\Program Files\Microsoft SDKs\Windows\v6.0\ Samples\winbase\WindowsErrorReporting\Registration\.

Второй пример, относящийся к теме данного обзора, иллюстрирует использование механизмов Restart Manager. Он находится по адресу: c:\Program Files\Microsoft SDKs\Windows\ v6.0\Samples\winbase\RestartManager\. В этом каталоге собрано пять демонстрационных приложений, которые иллюстрируют минимальную поддержку механизмов Restart Manager для консольных приложений (RmCuiApp), применение Restart Manager Filter API (RMFilterApp), сериализацию данных и их восстановление после перезагрузки в классическом Windows-приложении (RmGuiApp), аналогичную функциональность для приложений, разрабатываемых на .Net Framework с использованием Windows Forms (RmWinFormApp), и пример блокировки при попытке принудительного завершения приложения (ShutdownBlockReasonTestApp).

Дополнительные механизмы обеспечения надежности

В данном обзоре мы рассмотрели два механизма обеспечения надежности приложений, реализованных в операционной системе Microsoft Windows Vista, — Windows Feedback Platform и Restart Manager. К другим механизмам, обеспечивающим надежность как самой платформы, так и выполняемых под ее управлением приложений, можно отнести следующие:

• отмена выполнения операций ввода-вывода (Cancellable I/O Operations) — обеспечивает возможность завершения запросов на операции ввода-вывода, которые могут привести к повышенному использованию недоступных в данный момент ресурсов. Примерами новых функций являются CancelSynchronousIo() и CancelIoEx(). Отметим, что применение механизмов отмены операций ввода-вывода позволяет решить ряд проблем с такими операциями без принудительного завершения потоков и приложений;

• защита реестра — предотвращает возможность изменения ключевых настроек системы;

• определение утечек памяти — автоматически определяет утечки памяти и реагирует на это соответствующим образом;

• определение «зависаний» приложений — позволяет принудительно завершить и перезапустить приложения, которые перестали реагировать на действия пользователей, сообщений Windows Messages и т.п.;

• инфраструктура Windows Diagnostic Infrastructure (WDI) — служит для идентификации и выдачи сообщений об обнаруженых проблемах.

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

Заключение

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

КомпьютерПресс 2'2007