Продолжение          -             Перейти вначало статьи >>

Функция ReadyDrive

ReadyDrive – это функция ОС Windows Vista, использующая возможности новых гибридных жестких дисков (дисков H-HDD). Гибридный жесткий диск представляет собой жесткий диск со встроенной энергонезависимой флэш-памятью (известной также под названием NVRAM). Как правило, гибридные жесткие диски содержат от 50 МБ до 512 МБ кэш-памяти, но ОС Windows Vista поддерживает кэши размером до 2 ТБ.

Чтобы определить, какие данные следует поместить во флэш-память, ОС Windows Vista использует команды ATA-8. Например, при завершении работы система сохраняет в этом кэше данные для загрузки, что позволяет ускорить следующий запуск системы. При переходе в режим гибернации в кэше сохраняются некоторые части файла гибернации, что ускоряет возобновление работы. Поскольку кэш активен даже когда диск остановлен, система может использовать флэш-память для кэширования записи на диск, что позволяет не раскручивать диск, если компьютер питается от аккумулятора. Остановка диска позволяет существенно снизить энергопотребление по сравнению с обычным режимом работы.

База данных конфигурации загрузки

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

Одним из самых заметных изменений процесса загрузки системы является отсутствие файла Boot.ini в корневой папке системного тома. Это объясняется тем, что конфигурация загрузки, которая раньше хранилась в этом файле, теперь хранится в базе данных BCD. Одной из причин использования базы данных BCD в ОС Windows Vista является объединение двух поддерживаемых в ОС Windows архитектур загрузки: основной загрузочной записи (MBR) и расширяемого интерфейса микропрограмм (EFI). Загрузочная запись MBR обычно используется на компьютерах с архитектурами x86 и x64, а интерфейс EFI – в системах Itanium (хотя в ближайшем будущем, вероятно, будут поставляться и рабочие станции с поддержкой EFI). Использование базы данных BCD позволяет абстрагироваться от микропрограмм и обеспечивает ряд дополнительных преимуществ по сравнению с использованием файла Boot.ini, например поддержку строк в формате Юникод и поддержку исполнения альтернативных предзагрузочных программ.

Фактически база данных BCD хранится на диске в кусте реестра, загружаемом в реестр ОС Windows для доступа с помощью программных интерфейсов реестра. На платформах PC она хранится в файле \Boot\Bcd на системном томе. На системах EFI база данных хранится в системном разделе EFI. После загрузки куста он появляется в разделе реестра HKLM\Bcd00000000. Внутренний формат этой базы данных не документируется, поэтому для ее редактирования используются специальные инструменты, например программа %SystemRoot%\System32\Bcdedit.exe. Для поддержки сценариев и специализированных редакторов доступны интерфейсы для управления базой данных BCD с помощью инструментария WMI. Изменять и добавлять основные параметры, такие как команды отладки ядра, можно также с помощью программы настройки системы (%SystemRoot%\System32\Msconfig.exe).

Параметры загрузки, относящиеся ко всей платформе, например выбор ОС по умолчанию и время задержки меню загрузки, отделены в базе данных BCD от параметров, относящихся к конкретным операционным системам, таких как параметры загрузки ОС и путь к системному загрузчику. Если запустить программу Bcdedit без параметров командной строки, сперва в разделе «Windows Boot Manager» будут выведены параметры, относящиеся к платформе, а затем в разделе «Windows Boot Loader» – параметры для конкретной ОС, как показано на рис. 3.

Во время загрузки установленной ОС Windows Vista новая схема загрузки разделяет задачи, выполнявшиеся в более ранних версиях ОС Windows одним системным загрузчиком Ntldr, между двумя программами – \BootMgr и %SystemRoot%\System32\Winload.exe. Программа BootMgr считывает базу данных BCD и отображает меню загрузки операционной системы, а программа Winload.exe осуществляет загрузку операционной системы. При «чистой» загрузке системы программа Winload.exe загружает драйверы устройств, необходимые для запуска системы, и основные файлы операционной системы, включая ядро Ntoskrnl.exe, а затем передает управление операционной системе. В случае возобновления работы из режима гибернации программа Winload.exe запускает программу %SystemRoot%\System32\Winresume.exe для загрузки данных из файла гибернации в оперативную память и возобновления работы ОС.

Загрузчик Bootmgr также поддерживает исполнение дополнительных предзагрузочных программ. В составе ОС Windows Vista поставляется программа диагностики оперативной памяти (\Boot\Memtest.exe), которая уже включена в меню загрузки. Сторонние разработчики могут добавлять собственные предзагрузочные программы, которые будут отображаться в меню загрузки Bootmgr.

Процесс загрузки системы

В предыдущих версиях ОС Windows взаимосвязь между различными системными процессами не была очевидной. Например, в процессе загрузки системы диспетчер интерактивного входа в систему (%SystemRoot%\System32\Winlogon.exe) запускал службу подсистемы локального администратора безопасности (Lsass.exe) и диспетчер управления службами (Services.exe). Далее система использовала контейнер пространств имен (сеанс) для изоляции процессов, запущенных в различных сеансах входа в систему. Однако в операционных системах, предшествовавших ОС Windows Vista пользователь, вошедший в консоль, использовал сеанс 0, в котором работают и системные процессы. Это создавало потенциальную угрозу для безопасности. Примером такой угрозы стала одна плохо написанная служба Windows, работавшая в сеансе 0 и отображавшая пользовательский интерфейс в интерактивной консоли, позволяя вредоносным программам атаковать окно этой службы методом «подрывной атаки» (shatter attack), получая административные привилегии.

Для устранения подобных проблем в ОС Windows Vista было реструктурировано несколько системных процессов. Диспетчер сеансов (Smss.exe) – это первый процесс пользовательского режима, запускаемый во время загрузки, как и в предыдущих версиях ОС Windows. Однако в ОС Windows Vista диспетчер сеансов запускает еще одну свою копию для настройки сеанса 0, который выделен исключительно для системных процессов. Процесс диспетчера сеансов для сеанса 0 запускает приложение инициализации Windows (Wininit.exe), процесс подсистемы Windows (Csrss.exe) для сеанса 0, а затем завершает свою работу. Далее приложение инициализации Windows запускает диспетчер управления службами, подсистему локального администратора безопасности и новый процесс – диспетчер локальных сеансов (Lsm.exe), который управляет сеансами терминального сервера на этом компьютере.

Когда пользователь входит в систему, первоначально запущенный диспетчер сеансов запускает еще одну свою копию для настройки нового сеанса. Вновь запущенный процесс Smss.exe запускает процесс подсистемы Windows и процесс Winlogon для нового сеанса. На рабочей станции запуск диспетчером сеансов собственных копий для инициализации каждого нового сеанса не дает никаких преимуществ. Но в случае работы на сервере Windows Server «Longhorn», выступающем в роли терминального сервера, копии диспетчера будут работать одновременно, обеспечивая более быстрый вход в систему нескольких пользователей.

В новой архитектуре все системные процессы, включая службы Windows, изолированы в сеансе 0. Если служба Windows, запущенная в сеансе 0, отображает пользовательский интерфейс, служба обнаружения интерактивных служб (%SystemRoot%\System32\UI0Detect.exe) запускает собственную копию в контексте безопасности любого выполнившего вход администратора и выводит сообщение, показанное на рис. 4. Если администратор принимает предложение просмотреть сообщение, служба выполняет переключение рабочего стола на рабочий стол служб Windows, где администратор получает доступ к пользовательскому интерфейсу службы, а затем переключается назад на свой рабочий стол. На врезке «Просмотр отношений между процессами загрузки» можно более подробно ознакомиться с тем, что происходит во время загрузки системы.

Figure 4 Service has displayed a window

Просмотр отношений между процессами загрузки

Для просмотра дерева загрузки процессов ОС Windows Vista можно воспользоваться программой Process Explorer от компании Sysinternals (microsoft.com/technet/sysinternals).

На снимке экрана присутствует столбец Session (Сеанс), который можно добавить с помощью диалогового окна выбора столбцов в программе Process Explorer. Выделен первоначальный процесс Smss.exe. Ниже него в сеансе 0 находятся процессы Csrss.exe и Wininit.exe, выровненные по левому краю, потому что их родительский процесс, экземпляр процесса Smss.exe, выполнивший настройку сеанса 0, завершил свою работу. Три дочерних процесса, порожденные процессом Wininit.exe – Services.exe, Lsass.exe и Lsm.exe.

Также в программе Process Explorer виден ряд процессов, запущенных в сеансе 1. Это сеанс, вход в который выполнен пользователем с помощью подключения к удаленному рабочему столу. Процессы, запущенные в рамках одной учетной записи с программой Process Explorer, выделены синим цветом. Наконец, сеанс 2 был инициализирован для подготовки к консольному входу пользователя в систему и созданию нового сеанса входа. Именно в этом сеансе запущен процесс Winlogon, использующий процесс LogonUI, чтобы предложить пользователю нажать сочетание клавиш Ctrl+Alt+Delete для входа в систему, и в которой процесс Logonui.exe затем попросит пользователя ввести свои учетные данные.

Поставщики учетных данных

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

Вместо модели GINA в ОС Windows Vista используется архитектура поставщиков учетных данных. Процесс Winlogon запускает отдельный процесс – сервер пользовательского интерфейса входа в систему (Logonui.exe), который выполняет загрузку поставщиков учетных данных, настроенных в разделе реестра HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers. Процесс Logonui может работать с несколькими поставщиками учетных данных одновременно. ОС Windows Vista поставляется с двумя поставщиками учетных данных: интерактивным поставщиком (Authui.dll) и поставщиком смарт-карт (Smart-cardcredentialprovider.dll). Для унификации взаимодействия с пользователем процесс LogonUI управляет пользовательским интерфейсом, который видят конечные пользователи. Он также позволяет поставщикам учетных данных добавлять собственные отображаемые элементы, такие как текст, значки и поля ввода.

Службы с отложенным автозапуском

Пользователь, выполнивший вход в систему сразу после ее запуска, как правило, сталкивается с некоторой задержкой, прежде чем завершится настройка рабочего стола и можно будет свободно взаимодействовать с оболочкой системы и запускаемыми приложениями. Это происходит из-за того, что во время входа пользователя в систему диспетчер управления службами запускает множество служб Windows, настроенных как службы с автоматическим запуском и активируемые в процессе загрузки системы. Многие службы при инициализации выполняют операции, интенсивно потребляющие вычислительные и дисковые ресурсы, что приводит к замедлению процессу входа пользователя в систему. Для борьбы с этой проблемой в ОС Windows Vista введен новый тип запуска служб – отложенный автоматический запуск. Этот режим могут использовать службы, которые не обязаны быть активными сразу после загрузки системы.

Диспетчер управления службами запускает службы, настроенные на отложенный автоматический запуск, только после завершения запуска всех служб, настроенных на автоматический запуск. Диспетчер устанавливает первоначальному потоку таких служб приоритет THREAD_PRIORITY_LOWEST (наинизший приоритет потока). Установка такого приоритета приводит к тому, что все операции ввода-вывода, выполняемые потоком, выполняются с приоритетом «Very Low» (очень низкий). Когда служба завершает инициализацию, диспетчер управления службами устанавливает ей приоритет «Normal» (обычный). Сочетание отложенного запуска, низкого приоритета использования ЦП и памяти, а также фонового приоритета дисковых операций приводит к существенному снижению воздействия запуска таких служб на процесс входа пользователя в систему. Многие службы Windows, включая фоновую интеллектуальную службу передачи (BITS), клиент Windows Update и службу Windows Media® Center, используют этот метод запуска для увеличения производительности процесса входа в систему сразу после загрузки.

Завершение работы

Одна из проблем, с которыми сталкивались разработчики служб Windows, состоит в том, что по умолчанию у службы есть не более 20 секунд на завершение работы. В операционных системах Windows, предшествовавших ОС Windows Vista, не поддерживалось «чистое» завершение работы, при котором система дожидалась бы полного завершения работы всех служб, потому что в этом случае ошибка в службе могла бы полностью воспрепятствовать завершению работы системы. Некоторым службам, которым при завершении работы необходимо выполнить определенные сетевые операции или сохранить большой объем данных на диск, может потребоваться более продолжительное время для завершения работы, поэтому ОС Windows Vista позволяет службам запросить у системы уведомление о завершении работы.

Когда ОС Windows Vista завершает работу, диспетчер управления службами сперва уведомляет о завершении работы все службы, запросившие такое уведомление. Диспетчер будет ждать завершения работы таких служб бесконечно долго, но если в службе есть ошибка и она не отвечает на запросы в течение трех минут, диспетчер перестает ждать завершения работы этой службы. После того, как все службы, запросившие уведомление, завершили работу или истекло время ожидания, диспетчер управления службами выполняет завершение работы остальных служб так, как это было реализовано в предыдущих версиях. Служба управления групповыми политиками и служба Windows Update регистрируют запрос уведомления о завершении работы при установке ОС Windows Vista.

Служба управления групповыми политиками и служба Windows Update используют еще одну возможность управления службами в ОС Windows Vista – упорядочение завершения работы. В предыдущих версиях ОС Windows можно было указать зависимости служб при запуске, и диспетчер управления службами придерживался указанного порядка запуска служб, но только в ОС Windows Vista появилась возможность указать зависимость служб при завершении работы. В ОС Windows Vista службы, которые регистрируют запрос уведомления о завершении работы, могут также включить себя в список, хранящийся в разделе реестра HKLM\System\CurrentControlSet\Control\PreshutdownOrder, и при завершении работы служб диспетчер управления службами будет завершать их работу в указанном порядке. Подробнее об этих возможностях см. врезку «Определение службы с отложенным автозапуском и службы с уведомлением о завершении работы».

Управление электропитанием

Режимы сна и гибернации также являются способами завершения работы, и ошибки в управлении электропитанием в драйверах и приложениях часто становились причиной серьезных проблем для работающих в дороге людей с тех пор, как в ОС Windows 2000 впервые в линейке ОС на базе Windows NT® появилось управление электропитанием. Закрывая крышку ноутбука перед поездкой, пользователи ожидают, что система перейдет в ждущий режим или в режим гибернации. Однако, прибыв на место, многие из них обнаруживали вместо этого горячий чемодан, севший аккумулятор и потерянные данные. Это происходило потому, что ОС Windows всегда запрашивала у приложений и драйверов устройств согласие на переход в другой режим энергопотребления, и одного драйвера или приложения, не отвечающего на запросы, было достаточно, чтобы воспрепятствовать этому переходу.

В ОС Windows Vista диспетчер управления электропитанием, входящий в ядро системы, по прежнему уведомляет драйверы и приложения о смене режима энергопотребления, позволяя им подготовиться к переходу в другой режим. Однако теперь ядро не спрашивает у них разрешения. Более того, диспетчер управления электропитанием ждет ответа приложений не более 20 секунд, а не 2 минуты, как это было в предыдущих версиях ОС Windows. В результате пользователи ОС Windows Vista могут быть уверены в том, что система действительно перейдет в ждущий режим или режим гибернации.

Что дальше

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

Обновленная встроенная команда SC в ОС Windows Vista показывает службы, настроенные для отложенного автозапуска:

К сожалению, команда SC не выводит список служб, запросивших уведомление о завершении работы. Чтобы узнать, запросила ли служба уведомление о завершении работы, можно воспользоваться программой PsService от компании Sysinternals: