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

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

3. Монитор состояния защиты инициализирует объект типа «маркер доступа» и использует его для создания и подготовки первого маркера по учетной записи локальной системы, назначаемого начальному процессу (об учетной записи локальной системы см. главу 8).

4. Диспетчер процессов производит большую часть своей инициализации в фазе 0, определяя типы объектов «процесс» и «поток» и создавая списки для отслеживания активных процессов и потоков. Он также создает объект «процесс» для начального процесса и присваивает ему имя Idle. Наконец, диспетчер процессов создает процесс System и системный поток для выполнения процедуры PhaselInitialization. Этот поток не запускается сразу после создания, поскольку прерывания пока запрещены.

5. Далее наступает фаза 0 в инициализации диспетчера Plug and Play, в ходе которой просто инициализируется ресурс исполнительной системы, используемый для синхронизации ресурсов шин.

Когда на каждом процессоре управление возвращается к функции KiInitializeKernel, она передает его циклу Idle. B результате системный поток, созданный, как было описано в п. 4 предыдущего списка, начинает фазу 1. Дополнительные процессоры ждут начала своей инициализации до п. 5 фазы 1 (см. список ниже). B фазе 1 выполняются следующие операции. (Ha экране заставке, выводимом при загрузке Windows 2000, отображается индикатор прогресса, поэтому в списке упоминаются операции, связанные с обновлением этого индикатора.)

1. Для подготовки системы к приему прерываний от устройств и для разрешения прерываний вызывается HalInitSystem.

2. Вызывается загрузочный видеодрайвер (E: \Windows\System32\Bootvid.dll) который выводит экран-заставку, показываемую в процессе запуска Windows. (B Windows XP и Windows Server 2003 этот драйвер отображает ту картинку, которую Ntldr ранее вывел на экран.)

3. Инициализируется диспетчер электропитания.

4. Инициализируются системные часы (вызовом HalQueryRealTimeClock), текущее значение которых сохраняется как время загрузки системы.

5. B многопроцессорной системе инициализируются остальные процессоры и начинается выполнение команд.

6. Индикатор прогресса загрузки устанавливается на отметку 5 %.

7. Диспетчер объектов создает корневой каталог пространства имен (\), каталог \ObjectTypes и каталог сопоставлений DOS-имен устройств (\?? в Windows 2000 или \Global?? в Windows XP и Windows Server 2003), а также символьную ссылку в каталоге сопоставлений DOS-имен устройств.

8. Вызывается исполнительная система для создания своих типов объектов, включая семафор, мьютекс, событие и таймер.

9. Ядро инициализирует структуры данных планировщика (диспетчера) и таблицу диспетчеризации системных сервисов.

10. Монитор состояния защиты создает в пространстве имен диспетчера объектов каталог \Security и инициализирует структуры данных аудита (если аудит системы разрешен).

11. Индикатор прогресса загрузки устанавливается на отметку 10 %.

12. Для создания объекта «раздел» и системных рабочих потоков вызывается диспетчер памяти (см. главу 7).

13. Ha системное адресное пространство проецируются таблицы NLS (National Language Support).

14. Ha системное адресное пространство проецируется Ntdll.dll.

15. Диспетчер кэша инициализирует структуры данных кэша файловой системы и создает свои рабочие потоки.

16. Диспетчер конфигурации создает в пространстве имен объект «раздел реестра» \Registry и копирует переданные Ntldr начальные данные в кусты реестра HARDWARE и SYSTEM.

17. Инициализируются структуры данных драйвера файловой системы.

18. Диспетчер Plug and Play вызывает PnP BIOS.

19. Индикатор прогресса загрузки устанавливается на отметку 20 %.

20. Подсистема LPC инициализирует объект типа «порт LPC».

21. Если система запущена с протоколированием загрузки (/BOOTLOG), инициализируется файл протокола загрузки.

22. Индикатор прогресса загрузки устанавливается на отметку 25 %.

23. Наступает момент инициализации диспетчера ввода-вывода. Согласно показаниям индикатора, эта стадия запуска системы занимает 50 % времени. После успешной загрузки каждого драйвера диспетчер ввода-вывода продвигает полоску на индикаторе на 2 % (если загружается более 25 драйверов, индикатор останавливается на отметке 75 %).

Диспетчер ввода-вывода прежде всего инициализирует различные внутренние структуры и создает типы объектов «устройство» и «драйвер». Затем он вызывает диспетчер Plug and Play, диспетчер электропитания и HAL, чтобы начать динамическое перечисление и инициализацию устройств. (Подробнее этот сложный процесс, специфичный для конкретной подсистемы ввода-вывода, рассматривается в главе 9.) Далее инициализируется подсистема WMI Windows Management Instrumentation), которая пpeдocтaвляeт WMI-пoддepжкy дpaйвepaм устройств. (Подробнее о WMI см. раздел «Windows Management Instrumentation" главы 4.) После этого вызываются все загрузочные драйверы, которые осуществляют свою инициализацию. Также загружаются и инициализируются драйверы, необходимые для запуска системы (см. главу 9). Наконец, в пространстве имен диспетчера объектов создаются имена устройств MS-DOS в виде символьных ссылок.

24. Индикатор прогресса загрузки устанавливается на отметку 75 %.

25. Если система загружается в безопасном режиме, этот факт отмечается в реестре.

26. Включается подкачка страниц для кода режима ядра (в Ntkrnl и драйверах), если она явно не запрещена в реестре.

27. Индикатор прогресса загрузки устанавливается на отметку 80 %.

28. Вызывается диспетчер электропитания для инициализации своих структур данных.

29. Индикатор прогресса загрузки устанавливается на отметку 85 %.

30. Вызывается монитор состояния защиты для создания потока Command Server, взаимодействующего с LSASS (см. раздел «Компоненты системы защиты» главы 8).

31. Индикатор прогресса загрузки устанавливается на отметку 90 %.

32. Ha завершающем этапе создается процесс Smss диспетчера сеансов (базовые сведения об Smss см. в главе 2). Smss отвечает за создание среды пользовательского режима, которая предоставляет визуальный интерфейс Windows. Об инициализации Smss см. следующий раздел.

33. Индикатор прогресса загрузки устанавливается на отметку 100 %.

Перед завершением инициализации компонентов исполнительной системы и ядра поток инициализации фазы 1 в течение пяти секунд ждет освобождения описателя процесса Smss. Если этот процесс завершается до истечения пяти секунд, происходит крах системы с кодом SESSION5_INITIALIZATION_FAILED.

По истечении пяти секунд запуск диспетчера сеансов считается успешным, и вызывается функция потока обнуления страниц диспетчера памяти (см. главу 7).

Smss, Csrss и Winlogon

Smss похож на любой другой процесс пользовательского режима, но имеет два существенных отличия. Во-первых, Windows считает его доверяемой (trusted) частью системы. Во-вторых, Smss является встроенным (native) приложением. Как доверяемый компонент Smss может выполнять операции, доступные лишь немногим процессам, например создавать маркеры защиты. A как встроенное приложение Smss использует не Windows API, а базовые API-функции исполнительной системы, в совокупности называемые Windows Native API. Smss не обращается к Windows API, поскольку при его запуске подсистема Windows еще не функционирует. Запуск подсистемы Windows и является одной из его первых задач.

Затем Smss вызывает диспетчер конфигурации, который завершает инициализацию реестра, заполняя все его разделы. Диспетчер конфигурации запрограммирован так, что ему известно местонахождение всех кустов реестра на диске, кроме содержащих пользовательские параметры. Пути ко всем загружаемым им кустам реестра записываются в раздел HKLM\SYSTEM\CurrentControlSet\Control\Hivelist.

Основной поток Smss выполняет следующие инициализирующие операции.

1. Создает объект «порт LPC» (\SmApiPort) и два потока, ожидающие клиентские запросы (например, на загрузку новой подсистемы или на создание сеанса).

2. Определяет символьные ссылки на имена устройств MS-DOS (вроде COM1 и LPT1).

3. Если установлены Terminal Services, создает в пространстве имен диспетчера объектов каталог \Sessions (для нескольких сеансов).

4. Запускает программы, указанные в HKLM\SYSTEM\CurrentControlSet\Con-trol\Session Manager\BootExecute. Как правило, в нем содержится одна команда на зaпycк Autochk (версия Chkdsk, работающая на этапе загрузки).

5. Выполняет отложенные действия по переименованию и удалению файлов, указанные в разделах HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations и HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations2.

6. Открывает известные DLL и создает для них объекты «раздел» в каталоге \Knowndlls пространства имен диспетчера объектов. Список DLL, считаемых известными, находится в разделе HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\Session Manager\KnownDLLs, а путь к каталогу, где расположены эти DLL, хранится в параметре Dlldirectory этого раздела. Об использовании разделов Known DLLs при загрузке DLL см. главу 6.

7. Создает дополнительные страничные файлы. Их конфигурация хранится в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Session Manager\Memory Management\PagingFiles.

8. Инициализирует реестр. Диспетчер конфигурации заполняет реестр, загружая кусты HKLM\SAM, HKLM\SECURITY и HKLM\SOFTWARE. Хотя информация о местонахождении файлов кустов содержится в разделе HKLM\ SYSTEM\CurrentControlSet\Control\Hivelist, диспетчер конфигурации ищет эти файлы в каталоге \Windows\System32\Config.

9. Создает системные переменные окружения, определенные в HKLM\System\CurrentControlSet\Session Manager\Environment.

10. Загружает часть подсистемы Windows, работающую в режиме ядра (Win32k.sys). Smss определяет местонахождение Win32k.sys и других загружаемых им компонентов по путям, хранящимся в HKLM\SYSTEM\CurrentControlSet\Control\Session Manager. Инициализирующий код в Win32k.sys использует видеодрайвер для переключения экрана в разрешение, определенное в профиле по умолчанию. Таким образом, в этот момент видеоадаптер переключается с VGA-режима, используемого загрузочным видеодрайвером, в выбранное для данной системы разрешение.

11. Запускает процессы подсистем, в том числе Csrss. (Как говорилось в главе 2, подсистемы POSIX и OS/2 в Windows 2000 запускаются по требованию.)

12.3апускает процесс Winlogon. Этапы запуска Winlogon кратко описываются ниже.

1З. Создает порты LPC для сообщений об отладочных событиях (DbgSsApiPort и DbgUiApiPort) и потоки, прослушивающие эти порты.

Отложенные действия по переименованию файлов

Тот факт, что исполняемые образы и DLL при использовании проецируются в память, делает невозможным обновление базовых системных файлов по окончании загрузки Windows. API-функция MoveFileEx позволяет указать, что перемещение файла должно быть отложено до следующей загрузки. Пакеты обновлений и критические исправления, которым нужно обновлять уже используемые файлы, проецируемые в память, устанавливают заменяющие файлы во временные каталоги и вызывают функцию MoveFileEx именно так, как говорилось чуть выше. B этом случае MoveFileEx просто записывает команды в параметры PendingFileRenameOperatiom и PendingFileRenameOperatiom2 в разделе реестра HKLM\SYSTEM\CurrentControlSet\Control\Session Manager. Эти параметры имеют тип MULTI_SZ, и каждая операция указывается парами имен файлов: первое имя — источник, а второе — приемник. B операциях удаления вместо приемника задается пустая строка. Чтобы просмотреть зарегистрированные отложенные команды переименования и удаления, используйте утилиту Pendmoves с сайта sysinternate.com.

После выполнения вышеперечисленных операций основной поток Smss переходит к бесконечному ожиданию описателей процессов Csrss и Winlogon. Поскольку от этих процессов зависит функционирование Windows, в случае их неожиданного завершения Smss вызывает крах системы. (B Windows XP и выше, если Csrss по какой-то причине завершается, крах системы вызывается ядром, а не Smss.)

Далее Winlogon продолжает инициализацию, выполняя такие операции, как создание начального объекта WindowStation и объектов рабочего стола. Если в HKLM\Software\Microsoft\Windows NT\Current Version\WinLogon\ GinaDLL указана какая-нибудь DLL, Winlogon использует ее в качестве GINA; в ином случае применяется GINA по умолчанию от Microsoft, Msgina (\Windows\System32\Msgina.dll"), которая отображает стандартное диалоговое окно входа в Windows. Затем Winlogori создает процесс SCM (диспетчера управления сервисами) (\Windows\System32\Services.exe), который загружает все сервисы и драйверы устройств, помеченные для автоматического запуска, а также запускает процесс LSASS (подсистемы локальной аутентификации) (\Windows\System32\Lsass.exe). Подробнее о запуске Winlogon и LSASS см. раздел «Инициализация Winlogon» главы 8.

После того как SCM инициализирует автоматически запускаемые сервисы и драйверы устройств, а пользователь успешно зарегистрируется в системе, загрузка считается успешно завершенной. Параметры в разделе HKLM\ SYSTEM\Select\LastKnownGood обновляются в соответствии со значениями параметров последней удачной конфигурации (\CurrentControlSet).

ПРИМЕЧАНИЕ Если на неинтерактивном сервере не бывает интерактивного входа, раздел LastKnownGood, отражающий набор управления (control set), который позволил выполнить успешную загрузку, не обновляется.

Вы можете заменить определение успешной загрузки. Для этого установите HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ReportBootOk в 0, напишите свою программу, проверяющую успешность загрузки, и укажите путь к ней в HKLM\System\CurrentControlSet\Control\BootVerificationProgram. Такая программа должна вызывать API-функцию NotifyBootConfigStatus, если загрузка прошла успешно.

Запустив SCM, Winlogon ждет уведомления об интерактивном входе от GINA. Получив такое уведомление и проверив вход (об этом процессе см. в главе 8), Winlogon загружает куст реестра из профиля зарегистрировавшегося пользователя и отображает его на HKCU. Затем он настраивает переменные окружения для данного пользователя, хранящиеся в HKCU\Environment, и направляет уведомления о входе компонентам, зарегистрированным в HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify.

Затем Winlogon сообщает GINA запустить оболочку. B ответ на этот запрос Msgina запускает исполняемый файл (или исполняемые файлы), указанный в параметре HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\Userinit (несколько исполняемых файлов перечисляются через запятые), который по умолчанию указывает на \Windows\System32\Userinit.exe. Userinit.exe выполняет следующие операции.

1. Обрабатывает пользовательские сценарии, указанные в HKCU\Software\Policies\Microsoft\Windows\System\Scripts, и машинные сценарии входа, заданные в HKLM\Software\Policies\Microsoft\Windows\System\Scripts.

(Так как машинные сценарии выполняются после пользовательских, они могут переопределять пользовательские настройки.)

2. Если политика группы задает какую-либо квоту в профиле пользователя, Userinit.exe запускает \Windows\System32\Proquota.exe для ее применения.

3. Запускает оболочку (или оболочки), указанную в HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell. Если этого параметра нет, Userinit.exe запускает оболочку (или оболочки), определенные в HKLM\Software\Microsoft\Windows\CurrentVersion\Winlogon\Shell (по умолчанию — Explorer.exe).

Далее Winlogon уведомляет зарегистрированные провайдеры сетей о входе пользователя. Провайдер сети Microsoft, маршрутизатор многосетевого доступа (Multiple Provider Router, MPR) (\Windows\System32\Mpr.dll), восстанавливает постоянные подключения к сетевому диску и принтерам, установленные пользователем; эти сопоставления хранятся в HCU\Network и HKCU\ Printers соответственно. Ha рис. 5–3 показано дерево процессов, которое отображается в Process Explorer при входе до завершения Userinit.

Автоматически запускаемые образы

Помимо параметров Userinit и Shell в разделе Winlogon, существует много других разделов в реестре и каталогов, проверяемых и обрабатываемых системными компонентами для автоматического запуска процессов при загрузке и входе. Утилита Msconfig (в Windows XP и Windows Server 2003 это \Windows\System32\Msconfig.exe) показывает образы, сконфигурированные в нескольких местах. Ho утилита Autoruns от Sysinternals (wwwsysinternals.com), представленная на рис. 5–4, анализирует больше разделов реестра и каталогов, чем Msconfig, и выводит больше информации об образах, настроенных на автоматический запуск. По умолчанию Autoruns показывает только те места, где задается автоматический запуск хотя бы одного образа, но команда Include Empty Locations в меню View заставляет Autoruns отображать все проверяемые ею разделы реестра и каталоги. B меню View можно настроить Autoruns на отображение сведений о других типах автоматически запускаемых образов, например служб Windows и надстроек Explorer.

ЭКСПЕРИМЕНТ: утилита Autoruns

Многие пользователи даже не представляют, сколько программ выполняется в процессе их входа. OEM (original equipment manufacturers) часто конфигурируют свои системы с помощью дополнительных утилит, которые выполняются в фоновом режиме и обычно не видны. Чтобы увидеть, какие программы настроены на автоматический запуск на вашем компьютере, запустите утилиту Autoruns; Сравните полученный в Autoruns список с тем, что показывается Msconfig (доступной в Windows XP и Windows Server 2003), и обратите внимание на различия. Потом попробуйте разобраться в предназначении каждой программы.

Анализ проблем при загрузке и запуске системы

B этом разделе представлены подходы к решению проблем, возможных в процессе запуска Windows из-за повреждения жесткого диска и файлов, отсутствия каких-либо файлов и ошибок в сторонних драйверах. Сначала мы опишем три режима восстановления Windows при возникновении проблем с загрузкой: последняя удачная конфигурация, безопасный режим и консоль восстановления (Recovery Console). Затем мы расскажем о наиболее распространенных проблемах при загрузке, об их причинах и способах устранения.

Последняя удачная конфигурация

Последняя удачная конфигурация (last known good, LKG) — полезный механизм для возврата системы, рухнувшей в процессе загрузки, в загружаемое состояние. Поскольку параметры системной конфигурации хранятся в HKLM\System\CurrentControlSet\Control, конфигурация драйверов и сервисов — в HKLM\System\CurrentControlSet\Services, изменения этих частей реестра могут привести к тому, что система станет незагружаемой. Например, если вы установили драйвер устройства с ошибкой, из-за которой происходит крах системы при загрузке, то можете нажать клавишу F8 в момент загрузки и выбрать из меню последнюю удачную конфигурацию. Система отмечает набор управления, использовавшийся при загрузке как неудачный, устанавливая параметр Failed в HKLM\System\Select и заменяя значение параметра HKLM\System\Select\Current на значение параметра HKLM\System\ Select\LastKnownGood. Она также обновляет символьную ссылку HKLM\Sys-tem\CurrentControlSet так, чтобы она указывала на набор управления Last-KnownGood. Поскольку для нового драйвера нет подраздела в разделе Services набора управления LastKnownGood, система успешно загрузится.

Безопасный режим

Наиболее распространенная причина, по которой системы Windows становятся незагружаемыми, заключается в том, что какой-то драйвер устройства приводит к краху при загрузке. Поскольку со временем программно-аппаратная конфигурация системы может измениться, скрытые до этого ошибки в драйверах могут проявиться в любой момент. Windows предоставляет администратору способ решения подобных проблем: загрузку в безопасном режиме (safe mode). Понятие безопасного режима в Windows заимствовано из потребительских версий Windows и представляет собой конфигурацию с минимальным набором драйверов и сервисов. Используя только самые необходимые драйверы, Windows избегает загрузки сторонних драйверов, способных вызывать крах системы.

Нажав клавишу F8 в начале загрузки Windows 2000, вы открываете дополнительное загрузочное меню, в котором присутствуют три варианта загрузки в безопасном режиме: Safe Mode (Безопасный режим), Safe Mode With Networking (Безопасный режим с загрузкой сетевых драйверов) и Safe Mode With Command Prompt (Безопасный режим с поддержкой командной строки). Стандартный безопасный режим подразумевает использование минимума необходимых для успешной загрузки драйверов. B безопасном режиме с сетевой поддержкой дополнительно загружаются сетевые драйверы и сервисы. Наконец, единственное отличие безопасного режима с поддержкой командной строки от стандартного заключается в том, что Windows вместо обычной оболочки Windows Explorer, позволяющей работать в GUI-режиме, запускает оболочку командной строки (Cmd.exe).

B Windows предусмотрен и четвертый безопасный режим — Directory Services Restore (Восстановление службы каталогов), который применяется для загрузки системы с отключенной службой каталогов Active Directory и без открытия ее базы данных. Это позволяет администратору исправить поврежденную базу данных или восстановить ее с резервной копии. B этом режиме загружается весь набор драйверов и сервисов, кроме Active Directory. B тех случаях, в которых вам не удается войти в систему из-за повреждения базы данных Active Directory, этот режим дает возможность устранить неполадки.

Загрузка драйверов в безопасном режиме

Как Windows определяет набор драйверов для загрузки в стандартном безопасном режиме и безопасном режиме с сетевой поддержкой? Ответ следует искать в содержимом раздела реестра HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot. B нем присутствуют подразделы Minimal и Network. Каждый подраздел в свою очередь содержит подразделы с именами драйверов, сервисов или их групп. Так, подраздел vga.sys определяет драйвер видеоадаптера VGA, который поддерживает базовый набор графических сервисов стандартного видеоадаптера для IBM-совместимого компьютера. Этот драйвер используется системой в безопасном режиме вместо драйверов, которые позволяют задействовать все преимущества куда более совершенных видеоадаптеров, но способны помешать успешной загрузке системы. Каждому подразделу в разделе SafeBoot соответствует параметр по умолчанию, описывающий, что именно идентифицирует данный подраздел. Например, в подразделе vga.sys параметр по умолчанию — Driver.

Параметром по умолчанию для подраздела файловой системы является Driver Group. При создании сценария установки для драйвера устройства разработчик может указать, что он относится к какой-либо группе драйверов. Группы драйверов, определенные в системе, перечисляются в параметре List раздела реестра HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder. Разработчик приписывает драйвер к той или иной группе, чтобы указать Windows, на каком этапе загрузки следует запускать данный драйвер. Главное предназначение раздела ServiceGroupOrder — определение порядка загрузки групп драйверов. Некоторые группы драйверов нужно загружать до или после других. Параметр Group в подразделе реестра со сведениями о конфигурации драйвера, сопоставляет его с определенной группой. Подразделы со сведениями о конфигурации драйверов и сервисов находятся в разделе HKLM\SYSTEM\CurrentControlSet\Services. Взглянув на его содержимое, вы найдете раздел VgaSave для драйвера видеоадаптера VGA, который принадлежит к группе Video Save. Любой драйвер файловой системы, необходимый Windows для обращения к системному диску, находится в группе Boot File System. Если файловой системой такого диска является NTFS, то в группу входит драйвер NTFS; в ином случае в группу входит драйвер Fastfat (поддерживающий диски FAT12, FATl6 и FAT32). Другие драйверы файловой системы входят в группу File System, которая также включена в конфигурации Safe Mode и Safe Mode With Networking.

При загрузке в безопасном режиме Ntldr передает ядру (Ntoskrnl.exe) вместе с другими параметрами, указанными в Boot.ini для текущего варианта загрузки, параметр командной строки /SAFEBOOT:, добавляя к нему одну или несколько строк в зависимости от выбранного типа безопасного режима. Для стандартного безопасного режима Ntldr добавляет MINIMAL, для Safe Mode With Networking — NETWORK, для Safe Mode With Command Prompt — MINIMAL(ALTERNATESHELL), a для Directory Services Restore — DSREPAIR.

Ядро Windows сканирует параметры загрузки в поисках спецификаторов безопасного режима и устанавливает значение внутренней переменной InitSafeBootMode в соответствии с результатом поиска. Значение этой переменной также записывается в раздел HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Option\OptionValue, что позволяет компонентам пользовательского режима (например, SCM) определять режим загрузки системы. Кроме того, при выборе Safe Mode With Command Prompt, ядро присваивает значение 1 параметру UseAlternateShell в разделе реестра HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Option. Кроме того, ядро записывает параметры, переданные Ntldr, в раздел HKLM\SYSTEM\CurrentControlSet\Control\SystemStartOptions.

Когда диспетчер ввода-вывода загружает драйверы устройств, указанные в разделе HKLM\SYSTEM\CurrentControlSet\Services, он выполняет функцию IopLoadDriver. A когда диспетчер Plug and Play обнаруживает новое устройство и хочет динамически загрузить драйвер для этого устройства, он вызывает функцию IopCallDriverAddDevice. Обе эти функции перед загрузкой драйвера обращаются к функции IopSafeBootDriverLoad. Последняя проверяет значение переменной InitSafeBootMode и определяет, можно ли загрузить данный драйвер. Так, если система загружается в стандартном безопасном режиме, IopSafeBootDriverLoad ищет группу этого драйвера (если таковая есть) в подразделе Minimal. Найдя ее, IopSafeBootDriverLoad уведомляет вызвавшую функцию о том, что этот драйвер можно загрузить. B ином случае IopSafeBootDriverLoad ищет в том же подразделе имя драйвера. Если оно есть в списке, драйвер может быть загружен. Если IopSafeBootDriverLoad не находит в списке группу или имя данного драйвера, его загрузка запрещается. При загрузке системы в безопасном режиме с сетевой поддержкой IopSafeBootDriverLoad ведет поиск в подразделе Network, а в случае загрузки системы в нормальном режиме IopSafeBootDriverLoad разрешает загрузку всех драйверов.

Однако Ntldr загружает все драйверы, у которых в соответствующих разделах реестра значение Start равно 0, что указывает на необходимость их загрузки при запуске системы. Поскольку Ntldr не проверяет раздел SafeBoot (считая, что любой драйвер с нулевым значением параметра Start необходим для успешного старта системы), он загружает все загрузочные драйверы, которые впоследствии запускаются Ntoskrnl.

Программное обеспечение с поддержкой безопасного режима

SCM (Services.exe), проводя инициализацию при загрузке, проверяет параметр OptionValue в разделе реестра HKLM\SYSTEM\CurrentControlSet\Cont-rol\SafeBoot\Option, чтобы выяснить, загружается ли система в безопасном режиме. Если да, SCM зеркально воспроизводит действия IopSafeBootDriverLoad. Он обрабатывает все сервисы, перечисленные в HKLM\SYSTEM\CurrentControlSet\Services, но загружает лишь отмеченные в соответствующем подразделе реестра для загрузки в безопасном режиме. Подробнее об инициализации SCM см. раздел «Сервисы» главы 4.

Userinit (\Windows\System32\Userinit.exe) — другой компонент пользовательского режима, которому нужно знать, загружается ли система в безопасном режиме. Userinit, инициализирующий среду для пользователя при его входе в систему, проверяет значение HKLM\SYSTEM\CurrentControlSet\Cont-rol\SafeBoot\UseAlternateValue. Если это значение установлено, в качестве пользовательской оболочки он запускает не Explorer.exe, а программу, указанную в HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\AlternateShell. Когда вы устанавливаете Windows на компьютер, параметру AlternateShell присваивается значение Cmd.exe, и командная строка Windows становится оболочкой по умолчанию для безопасного режима с командной строкой. Ho, даже если текущей оболочкой является командная строка, из нее можно запустить Windows Explorer, введя команду Explorer.exe. Аналогичным образом из командной строки можно запустить любую GUI-программу.

A как приложения узнают о загрузке системы в безопасном режиме? Вызовом Windows-функции GetSystemMetrics (SM_CLEANBOOT). Пакетные сценарии, выполняющие некоторые действия при загрузке системы в безопасном режиме, проверяют наличие переменной окружения SAFEBOOT_OPTION, так как система определяет ее только при загрузке в безопасном режиме.

Ведение протокола при загрузке в безопасном режиме

Если вы загружаете систему в безопасном режиме, Ntldr передает ядру Windows вместе с параметрами, устанавливающими безопасный режим, и параметр /BOOTLOG. При инициализации ядро проверяет наличие параметра /BOOTLOG независимо от того, задан ли безопасный режим. Если ядро обнаруживает соответствующую строку, оно протоколирует все свои действия при загрузке каждого драйвера. Так, если функция IopSafeBootDriverLoad запрещает загрузку какого-либо драйвера, диспетчер ввода-вывода вызывает функцию IopBootLog, регистрируя, что данный драйвер не загружен. Аналогичным образом после успешной загрузки драйвера, входящего в конфигурацию безопасного режима, IopLoadDriver вызывает IopBootLog для внесения записи о загрузке этого драйвера. Изучив файлы протокола загрузки, можно выяснить, какие драйверы являются частью данной конфигурации.

Поскольку ядро избегает изменения данных на диске до запуска Chkdsk, который происходит на более позднем этапе загрузки, IopBootLog не может просто сбрасывать записи в файл. Вместо этого она записывает их в раздел реестра HKLM\SYSTEM\CurrentControlSet\BootLog. Диспетчер сеансов (Smss), первый загружаемый компонент пользовательского режима, запускает Chkdsk для проверки целостности системного диска, а потом завершает инициализацию реестра, вызывая NtInitializeRegistry. Этот вызов указывает ядру, что уже можно безопасно открыть на диске файл протокола, что и делается вызовом IopCopyBootLogRegistryToFile. Эта функция создает в системном каталоге Windows (по умолчанию — \Windows) файл Ntbtlog.txt и копирует в него содержимое раздела реестра BootLog. IopCopyBootLogRegistryToFile также устанавливает флаг, сигнализирующий IopBootLog о возможности записи непосредственно в файл протокола. Ниже показан фрагмент образца такого файла.

Service Pack 1 3 30 2004 14:05:21.500

Loaded driver \WIND0WS\system32\ntoskrnl.exe

Loaded driver \WIND0WS\system32\hal.dll

Loaded driver \WIND0WS\system32\KDC0M.DLL

Loaded driver \WIND0WS\system32\B00TVID.dll

Loaded driver ACPI.sys

Loaded driver \WIND0WS\System32\DRIVERS\WMILIB.SYS

Loaded driver pci.sys

Loaded driver isapnp.sys

Loaded driver intelide.sys

Loaded driver \WIND0WS\System32\DRIVERS\PCIIDEX.SYS

Loaded driver MountMgr.sys

Loaded driver ftdisk.sys

Loaded driver dmload.sys

Loaded driver dmio.sys Microsoft (R)Windows 2000 (R)Version 5.0 (Build 2195) 2 11 2000 10:53:27.500

Loaded driver \WINNT \System32 \ntoskrnl.exe

Loaded driver \WINNT \System32 \hal.dll

Loaded driver \WINNT \System32 \B00TVID.DLL

Loaded driver ACPI.sys

Loaded driver \WINNT \System32 \DRIVERS \WMILIB.SYS

Loaded driver pci.sys

Loaded driver isapnp.sys

Loaded driver compbatt.sys

Loaded driver \WINNT \System32 \DRIVERS \BATTC.SYS

Loaded driver intelide.sys

Loaded driver \WINNT \System32 \DRIVERS \PCIIDEX.SYS

Loaded driver pcmcia.sys

Loaded driver ftdisk.sys

Loaded driver Diskperf.sys

Loaded driver dmload.sys

Loaded driver dmio.sys

Did not load driver \SystemRoot\System32\Drivers\lbrtfdc.SYS

Did not load driver \SystemRoot\System32\Drivers\Sfloppy.SYS

Did not load driver \SystemRoot\System32\Drivers\i2omgmt.SYS

Did not load driver Media Control Devices

Did not load driver Communications Port

Did not load driver Audio Codecs

Консоль восстановления

B безопасном режиме обычно удается восстановить систему, ставшую незагружаемой в нормальном режиме из-за неправильной работы какого-либо драйвера устройства. Однако в некоторых ситуациях это не помогает: система все равно не загружается. Так, если сбойный драйвер входит в группу Safe, загрузиться в безопасном режиме не удастся. Другая ситуация, когда загрузка в безопасном режиме не помогает, — сбои в загрузочном драйвере стороннего поставщика, например в драйвере антивирусного сканера, поскольку загрузочные драйверы стартуют независимо от режима загрузки системы. Аналогичная ситуация возникает при повреждении файлов системных модулей или драйверов, входящих в конфигурацию безопасного режима, а также главной загрузочной записи (MBR) системного диска. Эти проблемы можно решить с помощью Recovery Console (Консоль восстановления). Консоль восстановления позволяет загрузить компактную оболочку командной строки с дистрибутивного компакт-диска Windows (или ранее подготовленных загрузочных дискет) и восстановить систему без загрузки компьютера с жесткого диска.

При загрузке системы с дистрибутивного компакт-диска Windows появляется экран, на котором можно выбрать между установкой Windows и восстановлением существующей системы. При выборе второго варианта предлагается вставить дистрибутивный компакт-диск Windows (если он не вставлен в CD-привод). Далее вы должны выбрать один из двух вариантов восстановления: запустить консоль восстановления или начать процесс аварийного восстановления. Если при появлении экрана Setup Welcome (Вас приветствует программа установки) вы нажмете клавишу F10, это меню выводиться не будет, а сразу запустится консоль восстановления.

После запуска консоль восстановления сканирует жесткие диски и формирует список систем Windows NT и Windows на данном компьютере (если они есть). Выбрав нужную систему, вы должны ввести пароль, соответствующий учетной записи администратора для данной системы. Если регистрация прошла успешно, система предоставляет вам командную оболочку, аналогичную среде MS-DOS. Гибкий набор команд позволяет выполнять простые операции с файлами (вроде копирования, переименования и удаления), включать и отключать службы и драйверы и даже восстанавливать MBR и загрузочные записи. Однако консоль восстановления обеспечивает доступ лишь к корневому каталогу, к каталогу, в котором установлена система и в котором вы сейчас зарегистрировались, и к каталогам на сменных дисках, например на компакт-дисках или 3,5-дюймовых дискетах (если это разрешено локальной политикой безопасности, чьи параметры хранятся в кусте SECURITY реестра текущей системы). Эти ограничения диктуются требованиями защиты данных, право на доступ к которым может отсутствовать у администратора одной из систем. Вы можете переопределить эти ограничения, используя редактор локальной политики безопасности (secpol.msc) для настройки параметров Recovery Console (Консоль восстановления) в папке Security Options (Параметры безопасности) в Local Policies (Локальные политики) при нормальной загрузке системы.

Для поддержки таких команд файлового ввода-вывода, как Cd, Rename или Move, консоль восстановления использует встроенный интерфейс системных вызовов Windows. Команды Enable и Disable, позволяющие изменять режимы запуска драйверов устройств и сервисов (служб), работают иначе. Например, когда вы командуете консоли восстановления отключить какой-либо драйвер, она обращается к разделу реестра Services и присваивает параметру Start в подразделе для соответствующего драйвера значение SERVICE_DISABLED. B результате при следующей загрузке системы данный драйвер загружаться не будет. Консоль также загружает куст реестра SYSTEM (\Windows\System32\Config\System) для текущей системы, где в разделе HKLM\SYSTEM\CurrentControlSet\Services хранится нужная информация.

Когда вы загружаете систему с дистрибутивного компакт-диска Windows или загрузочных дискет, к моменту появления экрана, предлагающего выбор между установкой или восстановлением Windows, происходит загрузка с компакт-диска стартовой копии ядра Windows и всех драйверов поддержки (например, драйверов NTFS, FAT, SCSI и видеоадаптера). Ha компьютерах с процессорами типа x86 загрузка с компакт-диска управляется файлом Txtsetup.sif из каталога i386. B нем содержится список файлов, подлежащих загрузке, с указанием их местонахождения на компакт-диске. Как и при загрузке Windows с жесткого диска, первой запускаемой программой пользовательского режима является диспетчер сеансов (Smss.exe), расположенный в каталоге I386\System32. Диспетчер сеансов, используемый программой установки Windows, отличается от стандартного в уже установленной системе. Эта версия диспетчера сеансов предоставляет меню, позволяющие установить или восстановить Windows, а также выбрать тип восстановления. B процессе установки Windows этот компонент также помогает выбрать раздел для установки системы и копирует файлы на жесткий диск.

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

Консоль восстановления, приняв от вас пароль для входа в выбранную систему, должна проверить его, даже несмотря на то что подсистема защиты Windows сейчас не функционирует. Таким образом, проверка пароля возлагается исключительно на консоль восстановления. Для этого консоль прежде всего загружает с жесткого диска (через Setupdd.sys) куст реестра диспетчера учетных записей безопасности (Security Accounts Manager, SAM) данной системы, где хранится информация о паролях. Куст SAM находится в каталоге \Windows\System32\Config\Sam. После загрузки этого куста консоль восстановления находит в реестре системный ключ для расшифровки копии SAM в памяти. Шифрование куста SAM введено, начиная с Windows NT 4 Service Pack 3, для защиты от попыток взлома из MS-DOS.

Далее консоль восстановления (Spcmdcon.sys) отыскивает в SAM пароль для учетной записи Administrator (Администратор). Ha заключительном этапе проверки консоль хэширует пароль по алгоритму MD5, а затем сравнивает полученный хэш с зашифрованным хэшем из SAM. Если они совпадают, консоль восстановления считает, что вы успешно вошли в систему, в ином случае консоль восстановления отказывает вам в доступе.

Решение распространенных проблем загрузки

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

Повреждение MBR

• Симптомы Система с поврежденной главной загрузочной записью (Master Boot Record, MBR) пройдет тест самодиагностики при включении, выполняемый BIOS (power-on self test, POST), выведет на экран информацию о версии BIOS или модели компьютера, затем экран станет черным, и компьютер зависнет. B зависимости от типа повреждения MBR вы можете увидеть одно из следующих сообщений: «Invalid Partition Table» (недопустимая таблица разделов), «Error Loading Operating System» (ошибка при загрузке операционной системы) или «Missing Operating System» (операционная система не найдена).

• Причина MBR может быть повреждена из-за ошибок жесткого диска, в результате ошибки одного из драйверов в процессе работы Windows или из-за деструктивной деятельности какого-либо вируса.

• Решение Загрузите консоль восстановления и запустите команду fixmbr. Эта команда заменяет исполняемый код в MBR K сожалению, она не исправит таблицу разделов. Единственный способ это сделать — восстановить поврежденную таблицу разделов из резервной копии или использовать сторонний инструмент для устранения повреждений на диске.

Повреждение загрузочного сектора

• Симптомы Повреждение загрузочного сектора выглядит как повреждение MBR, когда система зависает с черным экраном после прохождения BIOS POST, либо на черном экране появляется сообщение: «А disk read error occurred» (ошибка чтения с диска), «NTLDR is missing» (NTLDR не найден) или «NTLDR is compressed» (NTLDR заархивирован).

• Причина Загрузочная запись может быть повреждена из-за ошибок жесткого диска, в результате ошибки одного из драйверов в процессе работы Windows или из-за деструктивной деятельности какого-либо вируса.

• Решение Загрузите консоль восстановления и запустите команду fixboot. Эта команда перепишет загрузочный сектор указанного вами тома. Вы должны выполнить такую команду применительно к системному и загрузочному томам, если они разные.

Неправильная конфигурация Boot.ini

• Симптом После BIOS POST вы видите сообщение, которое начинается как «Windows could not start because of a computer disk hardware configuration problem» (Windows не удалось запустить из-за проблемы с конфигурацией дискового устройства), «Could not read from selected boot disk» (не удалось считать данные с выбранного загрузочного диска) или «Check boot path and disk hardware» (проверьте путь к загрузочному диску и дисковое устройство).

• Причина Файл Boot.ini удален, поврежден или больше не ссылается на загрузочный том из-за добавления раздела, которое привело к изменению ARC-имени тома (Advanced RISC Computing).

• Решение Загрузите консоль восстановления и запустите команду bootcfg /rebuild. Эта команда заставит консоль восстановления просканировать каждый том в поисках установленных систем Windows. Обнаружив первую из них, она спросит, следует ли добавить ее в Boot.ini как вариант загрузки и под каким названием отображать ее в загрузочном меню.

Повреждение системных файлов

• Симптомы Повреждение системных файлов (в том числе драйверов и DLL) может проявляться по-разному. Один из вариантов — сообщение на черном экране после прохождения BIOS POST, в котором говорится «Windows could not start because the following file is missing or corrupt» (Windows не удалось запустить из-за отсутствия или повреждения следующего файла). Далее выводится имя файла и запрос на его переустановку. Еще один вариант — синий экран в результате краха при загрузке с текстом «STOP: 0xC0000135 {Unable to Locate Component}».

• Причины Том, на котором находится системный файл, поврежден, один или несколько системных файлов удалены либо повреждены.

• Решение Загрузите консоль восстановления и запустите команду chkdsk. Эта команда попытается устранить повреждение тома. Если Chkdsk не сообщит о каких-либо проблемах, возьмите резервную копию нужного системного файла. Одно из мест, где можно найти такие копии, — каталог \Windows\System32\DllCache, в котором Windows хранит копии многих системных файлов для использования Windows File Protection (см. врезку «Windows File Protection» далее в этом разделе). Если вам не удалось найти копию файла в этом каталоге, поищите ее на другом компьютере в сети. Заметьте, что резервная копия файла должна быть от того же пакета обновлений или критического исправления, что и заменяемый файл.

B некоторых случаях может быть удалено или повреждено много системных файлов, поэтому процесс восстановления потребует неоднократных перезагрузок, пока вы поочередно не замените все файлы. Если вы считаете, что повреждения системных файлов слишком обширны, подумайте о восстановлении системы с резервного образа, который генерируется, например, Automated System Recovery (ASR). Запустив Windows Backup (Архивация данных) [эта программа находится в папке System (Служебные) в группе Accessories (Стандартные) меню Start (Пуск)], вы можете сгенерировать резервный ASR-образ, который включает все файлы на системном и загрузочном томах, плюс дискету, на которой сохраняется информация о дисках и томах в системе. Чтобы восстановить систему из ASR, загрузите компьютер с дистрибутива Windows и нажмите F2, когда появится соответствующий запрос.

Если у вас нет резервной копии, остается последнее средство — запуск программы установки Windows в режиме исправления: загрузите компьютер с дистрибутива Windows и следуйте указаниям мастера. Мастер спросит вас, хотите ли вы исправить существующую систему или установить новую. Как только вы выберете первый вариант, Setup переустановит все системные файлы, сохранив данные ваших приложений и параметры реестра.

Windows FiIe Protection

Помимо своих основных задач, Winlogon также поддерживает функциональность защиты файлов Windows (Windows File Protection, WFP). WFP, которая реализована в виде двух DLL (\Windows\System32\Sfc.dll и \Windows\System32\Sfc_os.dll), отслеживает несколько каталогов на предмет изменения ключевых драйверов, исполняемых файлов и DLL, в том числе большинство подкаталогов в \Windows. При этом она использует версию ReadDirectoryChangesWRJisL Native API. Когда WFP обнаруживает изменение в одном из системных файлов, список которых «зашит» в \Windows\System32\Sfcfiles.dll (с помощью утилиты Strings от sysinternals.com вы можете получить этот список), она проверяет, подписан ли данный файл цифровой подписью Microsoft (об этом процессе см. раздел «Установка драйверов» главы 9). Если подписан, WFP разрешает изменение и копирует файл в свой резервный каталог. По умолчанию это \Windows\System32\DllCache, но его можно переопределить, изменив параметр реестра HKLM\Software\Microsoft\Win-dows NT\CurrentVersion\Winlogon\SFCDllCacheDir. Критические исправления и пакеты обновлений всегда устанавливают системные файлы, подписанные Microsoft.

Если в результате модификации появляется файл, не подписанный Microsoft, WFP заменяет его резервной версией из подкаталога DLL–Cache. Если Winlogon не удается найти резервную версию в этом подкаталоге, он проверяет сетевой путь установки или дистрибутив (в этом случае предлагается вставить компакт-диск).

Повреждение куста System

• Симптомы Если куст реестра System (сведения об этом кусте см. в разделе «Реестр» главы 4) отсутствует или поврежден, NTLDR выводит на черном экране после BIOS POST сообщение «Windows could not start because the following file is missing or corrupt: \WINDOWS\SYSTEM32\CONFIG\SYSTEM» (Windows не удалось запустить из-за отсутствия или повреждения следующего файла: \WINDOWS\SYSTEM32\CONFIG\SYSTEM).

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

• Решение Загрузите консоль восстановления и запустите команду cbkdsk применительно к загрузочному тому, чтобы исправить любые возможные его повреждения. Если это не решило проблему, возьмите резервную копию куста System. Если вы делали резервные ASR-копии системы или использовали утилиту Windows Backup для создания резервных копий состояния системы (это один из вариантов, предлагаемых в ее UI), то скопируйте кусты реестра из самой последней резервной копии, которые хранятся в каталоге \Windows\Repair, в частности скопируйте файл System в \Windows\System32\Config.

Если вы используете Windows XP и средство System Restore (Восстановление системы) включено (о System Restore см. в главе 12), то можете получить резервные копии кустов реестра, в том числе System, из самой последней точки восстановления. Однако не исключено, что консоль восстановления не позволит вам обратиться к каталогу, где хранятся точки восстановления, — \System Volume Information. Версия консоли восстановления из Windows XP Service Pack 1 разрешает доступ к этому каталогу, а более старые версии — нет (если только это не разрешено локальной политикой безопасности). Чтобы обойти это ограничение, используйте Local Security Policy Editor (Редактор локальной политики безопасности) для изменения параметров консоли восстановления, как уже пояснялось ранее. Вы также можете применить сторонние утилиты для доступа к другим каталогам. Получив доступ к каталогу точек восстановления, выполните следующие операции, чтобы получить файлы кустов реестра.

1. Перейдите в каталоге \System Volume Information на загрузочном томе в подкаталог, имя которого начинается с «_restore».

2. Найдите подкаталог RP с самым большим числом (например, RP173).

3. Скопируйте файл с именем _REGISTRY_MACHINE_SYSTEM в файл \Windows\System32\Config\System.

4. Перезагрузите систему.

Другой вариант — попробовать исправить повреждение с помощью утилиты Microsoft ChkReg. Она пытается делать это автоматически и запускается с дискет, подготовленных в программе установки Windows XP Setup.

Если у вас нет резервных копий, нет доступа к точкам восстановления и утилита ChkReg не помогла, используйте копию куста System из \Windows \Repair как последнее средство. Windows Setup делает копию куста System по окончании установки, поэтому вы потеряете все изменения в конфигурации системы и драйверов устройств, произошедшие с того момента.

Крах или зависание после вывода экрана-заставки

• Симптомы K этой категории относятся проблемы, которые возникают после отображения экрана-заставки Windows, вывода рабочего стола или входа в систему. Они могут проявляться как крах с отображением синего экрана или зависание, при котором замораживается вся система (либо сохраняется возможность перемещать по экрану курсор мыши, но система ни на что не реагирует).

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

• Решение Вы можете попытаться устранить такую проблему. Первое, что стоит попробовать, — последнюю удачную конфигурацию (last known good, LKG), о которой уже рассказывалось в этой главе и в разделе «Сервисы» главы 4. Она состоит из набора управления реестром (registry control set), с помощью которого в последний раз удалось успешно загрузить систему. Поскольку этот набор включает базовую системную конфигурацию и регистрационную базу данных драйверов устройств и сервисов, он не отражает самые последние изменения в составе драйверов устройств или сервисов, что часто помогает обойти источник проблемы. Для доступа к последней удачной конфигурации нажмите клавишу F8 на самой ранней стадии процесса загрузки и в появившемся загрузочном меню выберите этот вариант.

Как уже говорилось в этой главе, когда вы загружаете LKG, система сохраняет набор управления, от которого вы тем самым отказываетесь, и помечает его как неудачный. Если LKG позволит сделать систему загружаемой, вы сможете экспортировать содержимое текущего и неудачного наборов управления в. reg-файлы и, сравнив их, определить, что стало причиной неудачной загрузки системы. Для этого используйте поддержку экспорта в Regedit, доступную в меню FiIe (Файл) [или Registry (Реестр), если вы работаете с Windows 2000].

1. Запустите Regedit и выберите HKLM\System\CurrentControlSet.

2. Выберите Export (Экспорт) из меню FiIe (Файл) и сохраните содержимое в файл с именем good.reg.

3. Откройте HKLM\System\Select, посмотрите значение параметра Failed и выберите подраздел HKLM\System\ControlXXX, где XXX — значение параметра Failed.

4. Экспортируйте содержимое этого набора управления в файл bad.reg.

5. Используйте Wordpad для глобальной замены всех вхождений «CurrentControlSet» в good.reg на «ControlSet».

6. C помощью Wordpad замените все вхождения «ControlXXX» (вместо XXX должно быть значение параметра Failed) в bad.reg на «ControlSet».

7. Запустите Windiff из Support Tools и сравните два файла.

Различия между неудачным и удачным наборами управления могут быть весьма значительными, поэтому вы должны сосредоточиться на изменениях в подразделе Control, а также в подразделах Parameters каждого драйвера и сервиса, зарегистрированного в подразделе Services. Различия в подразделах Enum разделов для драйверов в ветви Services набора управления игнорируйте.

Если проблема вызвана драйвером или сервисом, который присутствовал в системе до последней успешной загрузки, LKG не сделает систему загружаемой. LKG не поможет и в том случае, если изменившийся проблематичный параметр конфигурации находится вне набора управления или если он был изменен до последней успешной загрузки. B таких случаях следующий шаг — попробовать загрузиться в безопасном режиме (о нем уже рассказывалось в этом разделе). Если система успешно загружается в безопасном режиме и вам известно, какой драйвер привел к провалу нормальной загрузки, вы можете отключить его через диспетчер устройств, доступный с вкладки Hardware (Оборудование) апплета System (Система). Для этого укажите проблемный драйвер и выберите Disable (Отключить) из меню Action (Действие). Если вы используете Windows XP или Windows Server 2003, недавно обновили драйвер и считаете, что в обновленной версии есть какая-то ошибка, то можете выбрать откат драйвера к его предыдущей версии, что также делается в диспетчере устройств. Чтобы восстановить предыдущую версию драйвера, дважды щелкните нужный драйвер для открытия его окна свойств и нажмите кнопку Roll Back Driver (Откатить) на вкладке Drivers (Драйвер).

B Windows XP при включенном System Restore предлагается вариант отката состояния всей системы к предыдущей точке (определенной средством System Restore), когда LKG ничего не дала. Безопасный режим распознает наличие точек восстановления и, если они есть, спрашивает, что вы хотите — войти в систему и вручную выполнить диагностику и исправление или запустить мастер восстановления системы. Попытка сделать систему загружаемой с помощью System Restore — хороший вариант, когда вы знаете причину проблемы и хотите автоматически ее устранить или когда причина вам не известна, но вы не желаете тратить время на ее поиск.

Если System Restore вас не устраивает или если вам нужно определить причину краха при нормальной загрузке, когда в безопасном режиме система успешно загружается, то попробуйте вести журнал в ходе неудачной загрузки. Для этого выберите соответствующий вариант в загрузочном меню, которое открывается нажатием клавиши F8 на самой ранней стадии загрузки. Какуже говорилось в этой главе, диспетчер сеансов (\Windows\System32\Smss.exe) сохраняет журнал загрузки в \Windows\ntbtlog.txt; в нем отмечаются как загруженные, так и незагруженные системой драйверы устройств, поэтому вы получите такой журнал, только если крах или зависание происходит после инициализации диспетчера сеансов. После перезагрузки в безопасный режим система добавит в существующий журнал загрузки новые записи. Отделите части журнала, относящиеся к неудачной попытке загрузки и к загрузке в безопасный режим, и сохраните их в разных файлах. Удалите строки с текстом «Did not load driver», а затем сравните эти файлы с помощью утилиты наподобие Windiff. Поочередно отключайте драйверы, загружавшиеся при нормальной загрузке, но не в безопасном режиме, пока система вновь не будет загружаться в нормальном режиме. (После чего вновь включите драйверы, не связанные с проблемой.)

Если вам не удается получить журнал при нормальной загрузке (например, из-за того, что крах системы происходит до инициализации диспетчера сеансов), если система рушится и при загрузке в безопасном режиме или если при сравнении двух частей журнала не обнаруживается значимых различий, то остается лишь прибегнуть к утилите Driver Verifier в сочетании с анализом аварийного дампа. (Более подробные сведения по этой тематике см. в главе 14.)

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

Если в систему кто-то вошел и некий процесс инициирует завершение работы системы, вызывая Windows-функцию ExitWindowsEx, Csrss получает сообщение о необходимости завершения системы. Тогда Csrss в интересах инициатора завершения системы посылает скрытому окну, которое принадлежит Winlogon, Windows-сообщение с требованием завершить работу системы. Winlogon, олицетворяющий зарегистрированного в данный момент пользователя (чей контекст защиты может совпадать, а может и не совпадать с контекстом защиты пользователя процесса, инициировавшего завершение работы), вызывает ExitWindowsEx с набором специальных внутренних флагов. B результате Csrss получает еще одно сообщение с запросом на завершение системы.

Ha этот раз Csrss видит, что запрос поступил от Winlogon, и перебирает все процессы в сеансе интерактивного пользователя (а не того, кто инициировал завершение системы). Вызвав SetProcessShutdownParameters, процесс может указать уровень завершения (shutdown level), который сообщает системе, когда этому процессу нужно завершиться по отношению к другим процессам. Допустимые уровни укладываются в диапазон 0-1023 (по умолчанию — 640). Explorer, например, устанавливает свой уровень в 2, a Task Manager — в 1.Для каждого процесса, владеющего окном верхнего уровня, Csrss посылает сообщения WM_QUERYENDSESSION всем его потокам с циклом выборки Windows-сообщений. Если поток возвращает TRUE, процесс завершения работы системы продолжается. Тогда Csrss посылает потоку сообщение WM_ENDSESSION с требованием завершить свою работу. Csrss ждет завершения потока в течение времени, указанного в HKCU\Control Panel\ Desktop\HungAppTimeout (по умолчанию — 5000 мс).

Если в течение указанного времени поток не завершается, Csrss открывает диалоговое окно, показанное на рис. 5–5. (Вывод этого окна можно отключить, присвоив параметру HKCU\Control Panel\Desktop\AutoEndTasks значение, равное 1.) Диалоговое окно уведомляет пользователя о том, что корректное завершение данной программы невозможно, и предлагает принудительно завершить процесс или отменить завершение работы системы (тайм-аут для этого диалогового окна не предусмотрен, а значит, на этом этапе запрос на завершение может ждать бесконечно долго).

Рис. 5–5. Диалоговое окно для принудительного закрытия программы

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

ЭКСПЕРИМЕНТ: проверка HungAppTimeout

Вы можете проверить, как используется параметр реестра HungAppTimeout, запустив Notepad, введя в него какой-нибудь текст и выйдя из системы. По истечении времени, заданного в HungAppTimeout, Csrss.exe откроет диалоговое окно с запросом о том, хотите ли вы закрыть процесс Notepad, который еще не завершился. Notepad ждет, когда вы сообщите ему, надо ли сохранить введенный вами текст. Если вы нажмете Cancel в этом диалоговом окне, Csrss.exe отменит завершение работы системы.

Обнаружив консольное приложение, Csrss вызывает обработчик консоли, посылая событие CTRLLOGOFFEVENT (при завершении работы системы только процессы сервисов получают события CTRL_SHUTDOWN_ EVENT). Если обработчик возвращает FALSE, Csrss уничтожает процесс. Если обработчик возвращает TRUE или не отвечает в течение времени, указанного в HKCU\Control Panel\Desktop\WaitToKillAppTimeout (по умолчанию — 20000 мс), Csrss выводит диалоговое окно, показанное на рис. 5–5.

Далее Winlogon вызывает функцию ExitWindowsEx, чтобы Csrss завершил любые СОМ-процессы, являющиеся частью сеанса интерактивного пользователя.

K этому моменту выполнение всех процессов в сеансе уже завершено. Winlogon снова вызывает функцию ExitWindowsEx, на этот раз в контексте системного процесса, и та посылает Csrss сообщение. Csrss просматривает все процессы, принадлежащие контексту системы и рассылает сообщения WM_QUERYENDSESSION/WM_ENDSESSION всем GUI-потокам. Ho консольным приложениям с зарегистрированными обработчиками Csrss посылает не CTRL_LOGOFF_EVENT, a CTRL_SHUTDOWN_EVENT. Заметьте, что SCM является консольной программой, которой регистрируется свой обработчик. Получив запрос на завершение, SCM рассылает соответствующие сообщения всем сервисам, которые зарегистрированы на уведомление о завершении работы. Подробнее о завершении работы сервисов (в том числе о таймауте для SCM) см. раздел «Сервисы» главы 4.

Хотя при завершении системных процессов действуют те же таймауты, что и для пользовательских процессов, Csrss не выводит никаких диалоговых окон и не завершает их принудительно. (Значения таймаутов завершения системных процессов берутся из профиля пользователя по умолчанию.) Смысл этих таймаутов только в том, чтобы системные процессы корректно завершились до выключения системы. Ho многие системные процессы вроде Smss, Winlogon, SCM и LSASS на самом деле еще выполняются при выключении системы.

Как только Csrss заканчивает рассылку уведомлений системным процессам о завершении работы, Winlogon вызывает функцию исполнительной системы NtShutdownSystem. Она в свою очередь вызывает функцию NtSet-SystemPowerState, управляющую завершением драйверов и остальных компонентов исполнительной системы (диспетчеров Plug and Play, электропитания, ввода-вывода, конфигурации и памяти).

Например, NtSetSystemPowerState вызывает диспетчер ввода-вывода для рассылки пакетов завершения ввода-вывода всем драйверам устройств, запросившим уведомление о завершении системы. Это позволяет драйверам подготовить свои устройства к завершению работы Windows. Диспетчер конфигурации сбрасывает на диск все измененные данные реестра, а диспетчер памяти записывает все измененные страницы с файловыми данными обратно в соответствующие файлы. Диспетчер памяти производит очистку страничного файла (если это указано в настройках). Далее вновь вызывается диспетчер ввода-вывода, который информирует драйверы файловой системы о завершении Windows. Процесс завершения работы заканчивается на диспетчере электропитания, дальнейшие действия которого зависят от пользовательских настроек (выключение компьютера, перезагрузка или переход в ждущий режим).

Резюме

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

Как показано на рис. 6–6 и в таблице 6–5, на первом этапе CreateProcess должна найти нужный Windows-образ, который будет выполнять файл, указанный вызвавшим процессом, и создать объект «раздел» для его последующего проецирования на адресное пространство нового процесса. Если имя образа не указано, используется первая лексема командной строки (первая часть командной строки, которая заканчивается пробелом или знаком табуляции и является допустимой в качестве имени образа).

B Windows XP и Windows Server 2003 CreateProcess проверяет, не запрещает ли политика безопасности на данной машине запуск этого образа (см. главу 8).

Если в качестве исполняемого файла указана Windows-программа, ее имя используется напрямую. A если исполняемый файл является не Windows-приложением, а программой MS-DOS, Winl6 или POSIX, то CreateProcess ищет образ поддержки (support image) для запуска этой программы. Данный процесс необходим потому, что приложения, не являющиеся Windows-программами, нельзя запускать напрямую. Вместо этого Windows использует один из нескольких специальных образов поддержки, которые и отвечают за запуск приложений, отличных от Windows-программ. Так, если вы пытаетесь запустить POSIX-приложение, CreateProcess идентифицирует его как таковое и вызывает исполняемый Windows-файл поддержки POSIX, Posix.exe. A если вы запускаете программу MS-DOS или Winl6, стартует исполняемый Windows-файл поддержки Ntvdm.exe. Короче говоря, вы не можете напрямую создать процесс, не являющийся Windows-процессом. Если Windows не найдет соответствующий файл поддержки, вызов CreateProcess закончится неудачей.

Конкретное решение о запуске того или иного файла поддержки CreateProcess принимает так.

• Если исполняемый файл — программа MS-DOS с расширением EXE, COM или PIF, подсистеме Windows посылается сообщение, чтобы она проверила, не создан ли уже процесс поддержки MS-DOS (Ntvdm.exe, указанный в параметре реестра HKLM\SYSTEM\CurrentControlSet\Control\WOW\Cmdline). Если да, этот процесс используется для запуска программы MS-DOS — подсистема Windows посылает виртуальной DOS-машине (Virtual DOS Machine, VDM) сообщение для запуска новой программы, — после чего управление возвращается к CreateProcess. Если нет, запускается Ntvdm.exe и повторно выполняется первый этап CreateProcess.

• Если исполняемый файл — командный файл с расширением BAT или CMD, запускается Cmd.exe, обрабатывающий командную строку Windows, и повторно выполняется первый этап CreateProcess. (Имя командного файла передается Cmd.exe как первый параметр.)

• Если исполняемый файл — приложение Winl6 (Windows 3.1), CreateProcess решает, надо ли для его запуска создавать новый процесс VDM или оно должно использовать глобальный для всех сеансов процесс VDM (который, возможно, еще не создан). Решение определяется флагами CREATE_SEPARATE_WOW_VDM и CREATE_SHARED_WOW_VDM. Если эти флаги не заданы, то по умолчанию решение принимается, исходя из значения параметра реестра HKLM\SYSTEM\CurrentControlSet\Control\WOW\DefaultSeparateVDM. Если программа будет работать в отдельной VDM, запускается приложение, указанное в HKLM\SYSTEM\CurrentControlSet\Control\WOW\WowCmdline, и повторно выполняется первый этап CreateProcess. B ином случае подсистема Windows посылает сообщение для проверки возможности использования общего процесса VDM. (Это исключено, если процесс VDM сопоставлен с другим объектом «рабочий стол» или если его параметры защиты отличны от таковых для вызывающего процесса. Тогда нужно создавать новый процесс VDM.) Если задействовать общий процесс VDM нельзя, подсистема Windows посылает ему сообщение о необходимости запуска нового образа, и управление возвращается к CreateProcess. Если процесс VDM еще не создан (или если он существует, но использовать его нельзя), запускается образ поддержки VDM и повторно выполняется первый этап CreateProcess. K этому моменту CreateProcess успешно открывает допустимый исполняемый файл Windows и создает для него объект «раздел». Этот объект еще не спроецирован на память, но уже открыт. Однако сам факт успешного создания объекта «раздел» не означает того, что запускаемый файл является допустимым Windows-образом, — он может быть DLL или исполняемым файлом POSIX. Если это исполняемый файл POSIX, запускается Posix.exe, и CreateProcess заново выполняет действия первого этапа. A если это DLL, вызов CreateProcess заканчивается неудачей.

CreateProcess, найдя допустимый исполняемый Windows-образ, ищет в разделе реестра HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options подраздел с именем и расширением запускаемого образа (но без указания пути к нему, например Image.exe). Если такой подраздел есть, CreateProcess ищет в нем параметр Debugger. Если он присутствует, его значение становится именем запускаемого образа, после чего следует повторение первого этапа CreateProcess.

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

Этап 2: создание объекта «процесс»

K началу второго этапа функция CreateProcess уже открыла допустимый исполняемый файл Windows и создала объект «раздел» для его проецирования на адресное пространство нового процесса. После этого она создает объект «процесс», чтобы запустить образ вызовом внутренней функции NtCreateProcess. Создание объекта «процесс» исполнительной системы включает следующие подэтапы:

• формируется блок EPROCESS;

• создается начальное адресное пространство процесса; • инициализируется блок процесса ядра (KPROCESS);

• инициализируется адресное пространство процесса (в том числе список рабочего набора и дескрипторы виртуального адресного пространства), а также проецируется образ на это пространство;

• формируется блок РЕВ;

• завершается инициализация объекта «процесс» исполнительной системы.

ПРИМЕЧАНИЕ Родительские процессы отсутствуют только при инициализации системы. Далее они всегда используются для задания контекстов защиты новых процессов.

Этап 2A: формирование блока EPROCESS

Этот подэтап включает девять операций.

1. Создается и инициализируется блок EPROCESS.

2. От родительского процесса наследуется маска привязки к процессорам.

3. Минимальный и максимальный размеры рабочего набора процесса устанавливаются равными значениям переменных PsMinimumWorkingSet и PsMaximumWorkingSet.

4. Блок квот нового процесса настраивается на адрес блока квот его родительского процесса и увеличивается счетчик ссылок на блок квот последнего.

5. Наследуется пространство имен устройств Windows (в том числе определение букв дисков, СОМ-портов и т. д.).

6. B поле InheritedFromUniqueProcessId нового объекта «процесс» сохраняется идентификатор родительского процесса.

7. Создается основной маркер доступа процесса (копированием аналогичного маркера родительского процесса). Новый процесс наследует профиль защиты своих родителей. Если используется функция CreateProcessAsUser, чтобы задать для нового процесса другой маркер доступа, он соответственно модифицируется.

8. Инициализируется таблица описателей, принадлежащая процессу. Если установлен флаг наследования описателей родительского процесса, наследуемые описатели из его таблицы копируются в новый процесс (о таблицах описателей см. главу 3).

9. Статус завершения нового процесса устанавливается как STATUSPENDING.

Этап 2B: создание начального адресного пространства процесса

Начальное адресное пространство процесса состоит из следующих страниц:

• каталога страниц (этих каталогов может быть больше одного в системах, где таблицы страниц имеют более двух уровней, например в х86-систе-мах в режиме PAE или в 64-разрядных системах);

• страницы гиперпространства;

• списка рабочего набора.

Для создания этих страниц выполняются операции, перечисленные ниже.

1. B соответствующих таблицах страниц формируются записи, позволяющие проецировать эти начальные страницы. Количество страниц вычитается из переменной ядра MmTotalCommittedPages и добавляется к переменной ядра MmProcessCommit.

2. Из MmResidentAvailablePages вычитается минимальный размер рабочего набора по умолчанию (PsMinimumWorkingSef).

3. Ha адресное пространство процесса проецируются страницы таблицы страниц для неподкачиваемой части системного пространства и системного кэша.

Этап 2C: создание блока процесса ядра

Ha этом подэтапе работы CreateProcess инициализируется блок KPROCESS, содержащий указатель на список потоков ядра. (Ядро не имеет представления об описателях, поэтому оно обходит их таблицу.) Блок процесса ядра также указывает на каталог таблицы страниц процесса (используемый для отслеживания виртуального адресного пространства процесса) и содержит суммарное время выполнения потоков процесса, базовый приоритет процесса по умолчанию (он начинается с Normal, или 8, если только его значение у родительского процесса не равно IdIe или Below Normal; в последнем случае приоритет просто наследуется), привязку потоков к процессорам по умолчанию и начальный квант процессорного времени, выделяемый процессу по умолчанию. Последнее значение принимается равным PspForegroundQuantum[0], первому элементу общесистемной таблицы величин квантов.

ПРИМЕЧАНИЕ Начальный квант по умолчанию в клиентских и серверных версиях Windows неодинаков. Подробнее о квантах см. раздел «Планирование потоков» далее в этой главе.

Этап 2D: инициализация адресного пространства процесса

Подготовка адресного пространства нового процесса довольно сложна, поэтому разберем ее отдельно по каждой операции. Для максимального усвоения материала этого раздела вы должны иметь представление о внутреннем устройстве диспетчера памяти Windows (см. главу 7).

• Диспетчер виртуальной памяти присваивает времени последнего усечения (last trim time) для процесса текущее время. Диспетчер рабочих наборов, выполняемый в контексте системного потока диспетчера настройки баланса (balance set manager), использует это значение, чтобы определить, когда нужно инициировать усечение рабочего набора.

• Диспетчер памяти инициализирует список рабочего набора процесса, после чего становится возможной генерация ошибок страниц.

• Раздел (созданный при открытии файла образа) проецируется на адресное пространство нового процесса, и базовый адрес раздела процесса приравнивается базовому адресу образа.

• Ha адресное пространство процесса проецируется Ntdll.dll.

• Ha адресное пространство процесса проецируются общесистемные таблицы NLS (national language support).

ПРИМЕЧАНИЕ Процессы POSIX клонируют адресное пространство своих родителей, поэтому для них не нужны все вышеперечисленные операции создания нового адресного пространства. B случае приложений POSIX базовый адрес раздела нового процесса приравнивается тому же базовому адресу родительского процесса, а родительский PEB просто копируется.

Этап 2E: формирование блока PEB

CreateProcess выделяет страницу под PEB и инициализирует некоторые поля, описанные в таблице 6–6.

Если в файле явно указаны значения версии Windows, эти данные замещают соответствующие начальные значения, показанные в таблице 6–6. Связь полей версии из заголовка образа с полями PEB описывается в таблице 6–7.

Таблица 6–7. Windows-значения, заменяющие начальные значения полей PEB

Этап 2F: завершение инициализации объекта «процесс» исполнительной системы

Перед возвратом описателя нового процесса выполняется несколько завершающих операций.

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

2. Если родительский процесс входил в задание, новый процесс тоже включается в это задание (о заданиях — в конце главы).

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

4. Если в образе явно указана маска привязки к процессорам (например, в поле конфигурационного заголовка), ее значение копируется в PEB и впоследствии устанавливается как маска привязки к процессорам по умолчанию.

5. CreateProcess помещает блок нового процесса в конец списка активных процессов (PsActiveProcessHead).

6. Устанавливается время создания процесса, и вызвавшей функции (CreateProcess в Kernel32.dll) возвращается описатель нового процесса.

Этап 3: создание первичного потока, его стека и контекста

K началу третьего этапа объект «процесс» исполнительной системы полностью инициализирован. Однако у него еще нет ни одного потока, поэтому он не может ничего делать. Прежде чем создать поток, нужно создать стек и контекст, в котором он будет выполняться. Эта операция и является целью данного этапа. Размер стека первичного потока берется из образа — другого способа задать его размер нет.

Далее создается первичный поток вызовом NtCreateThread. Параметр потока — это адрес PEB (данный параметр нельзя задать при вызове CreateProcess — только при вызове CreateThread). Этот параметр используется кодом инициализации, выполняемым в контексте нового потока (см. этап 6). Однако поток по-прежнему ничего не делает — он создается в приостановленном состоянии и возобновляется лишь по завершении инициализации процесса (см. этап 5). NtCreateThread вызывает PspCreateThread (функцию, которая используется и при создании системных потоков) и выполняет следующие операции.

1. Увеличивается счетчик потоков в объекте «процесс».

2. Создается и инициализируется блок потока исполнительной системы (ETHREAD).

3. Генерируется идентификатор нового потока.

4. B адресном пространстве пользовательского режима формируется TEB.

5. Стартовый адрес потока пользовательского режима сохраняется в блоке ETHREAD. B случае Windows-потоков это адрес системной стартовой функции потока в Kernel32.dll (BaseProcessStart) первого потока в процессе и BaseThreadStart для дополнительных потоков). Стартовый адрес, указанный пользователем, также хранится в ETHREAD, но в другом его месте; это позволяет системной стартовой функции потока вызвать пользовательскую стартовую функцию.

6. Для подготовки блока KTHREAD вызывается KeInitThread. Начальный и текущий базовые приоритеты потока устанавливаются равными базовому приоритету процесса; привязка к процессорам и значение кванта также устанавливаются по соответствующим параметрам процесса. Кроме того, функция определяет идеальный процессор для первичного потока. (O том, как происходит выбор идеального процессора см. раздел «Идеальный и последний процессоры» далее в этой главе.) Затем KeInitThread создает стек ядра для потока и инициализирует его аппаратно-зависимый контекст, включая фреймы ловушек и исключений. Контекст потока настраивается так, чтобы выполнение этого потока началось в режиме ядра в KiThreadStartup. Далее KeInitThread устанавливает состояние потока в Initialized (инициализирован) и возвращает управление PspCreateThread.

7. Вызываются общесистемные процедуры, зарегистрированные на уведомление о создании потока.

8. Маркер доступа потока настраивается как указатель на маркер доступа процесса. Затем вызывающая программа проверяется на предмет того, имеет ли она право создавать потоки. Эта проверка всегда заканчивается успешно, если поток создается в локальном процессе, но может дать отрицательный результат, если поток создается в другом процессе через функцию CreateRemoteThread и у создающего процесса нет привилегии отладки.

9. Наконец, поток готов к выполнению.

Этап 4: уведомление подсистемы Windows о новом процессе

Если заданы соответствующие правила, для нового процесса создается маркер с ограниченными правами доступа. K этому моменту все необходимые объекты исполнительной системы созданы, и Kernel32.dll посылает подсистеме Windows сообщение, чтобы она подготовилась к выполнению нового процесса и потока. Сообщение включает следующую информацию:

• описатели процесса и потока;

• флагисоздания;

• идентификатор родительского процесса;

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

1. CreateProcess дублирует описатели процесса и потока. Ha этом этапе счетчик числа пользователей процесса увеличивается с 1 (начального значения, установленного в момент создания процесса) до 2.

2. Если класс приоритета процесса не указан, CreateProcess устанавливает его в соответствии с алгоритмом, описанным ранее.

3. Создается блок процесса Csrss.

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

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

6. Создается и инициализируется блок потока Csrss.

7. CreateProcess включает поток в список потоков процесса.

8. Увеличивается счетчик процессов в данном сеансе.

9. Уровень завершения процесса process shutdown level) устанавливается как 0x280 (это значение по умолчанию; его описание ищите в документации MSDN Library по ключевому слову SetProcessShutdownParameters).

10. Блок нового процесса включается в список общесистемных Windows-процессов.

11. Создается и инициализируется структура данных fW32PROCESS), индивидуальная для каждого процесса и используемая той частью подсистемы Windows, которая работает в режиме ядра.

12. Выводится курсор запуска в виде стрелки с песочными часами. Тем самым Windows говорит пользователю: «Я запускаю какую-то программу, но ты все равно можешь пользоваться курсором.» Если в течение двух секунд процесс не делает GUI-вызова, курсор возвращается к стандартному виду. A если за это время процесс обратился к GUI, CreateProcess ждет открытия им окна в течение пяти секунд и после этого восстанавливает исходную форму курсора.

Этап 5: запуск первичного потока

K началу этого этапа окружение процесса уже определено, его потокам выделены ресурсы, у процесса есть поток, а подсистеме Windows известен факт существования нового процесса. Поэтому для завершения инициализации нового процесса (см. этап 6) возобновляется выполнение его первичного потока, если только не указан флаг CREATE_SUSPENDED.

Этап 6: инициализация в контексте нового процесса

Новый поток начинает свою жизнь с выполнения стартовой процедуры потока режима ядра, KiTbreadStartup, которая понижает уровень IRQL потока с «DPC/dispatch» до «APC», а затем вызывает системную стартовую процедуру потока, PspUserTbreadStartup. Параметром этой процедуры является пользовательский стартовый адрес потока.

B Windows 2000 PspUserTbreadStartup сначала разрешает расширение рабочего набора. Если создаваемый процесс является отлаживаемой программой, все его потоки (которые могли быть созданы на этапе 3) приостанавливаются. B отладочный порт процесса (порт функций подсистемы Windows, так как это Windows-процесс) посылается сообщение о создании процесса, чтобы подсистема доставила событие отладки CREATE_PROCESS_DEBUGINFO соответствующему отладчику. Далее PspUserTbreadStartup ждет пересылки подсистемой Windows ответа отладчика (через функцию ContinueDebugEvent). Как только такой ответ приходит, выполнение всех потоков возобновляется.

B Windows XP и Windows Server 2003 PspUserThreadStartup проверяет, разрешена ли в системе предварительная выборка для приложений (application prefetching), и, если да, вызывает модуль логической предвыборки (logical prefetcher) для обработки файла команд предвыборки (prefetch instruction file) (если таковой есть), а затем выполняет предвыборку страниц, на которые процесс ссылался в течение первых десяти секунд при последнем запуске. Наконец, PspUserThreadStartup ставит APC пользовательского режима в очередь для запуска процедуры инициализации загрузчика образов (LdrInitializeThunk из Ntdll.dll). APC будет доставлен, когда поток попытается вернуться в пользовательский режим.

Когда PspUserThreadStartup возвращает управление KiTbreadStartup, та возвращается из режима ядра, доставляет APC и обращается к LdrInitialize-Thunk. Последняя инициализирует загрузчик, диспетчер кучи, таблицы NLS, массив локальной памяти потока (thread-local storage, TLS) и структуры критической секции. После этого она загружает необходимые DLL и вызывает их точки входа с флагом DLL_PROCESS_ATTACH.

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

Сборки, существующие в нескольких версиях

Одна из проблем, уже давно изводившая пользователей Windows, — так называемый «DLL hell». Вы создаете этот ад, устанавливая приложение, которое заменяет одну или более базовых системных DLL, содержащих, например, стандартные элементы управления, исполняющую среду Microsoft Visual Basic или MFC Программы установки приложений делают такую замену, чтобы приложения работали корректно, но обновленные DLL могут оказаться несовместимыми с уже установленными приложениями.

Эта проблема в Windows 2000 была отчасти решена, где модификация базовых системных DLL предотвращалась средством Windows File Protection, а приложениям разрешалось использовать собственные экземпляры этих DLL. Чтобы задействовать свой экземпляр какой-либо DLL вместо того, который находится в системном каталоге, у приложения должен быть файл Application.exe.local (где Application — имя исполняемого файла приложения); этот файл указывает загрузчику сначала проверить DLL-модули в каталоге приложения. Такой вид переадресации DLL позволяет избежать проблем несовместимости между приложениями и DLL, но больно бьет по принципу разделения DLL, ради которого DLL изначально и разрабатывались. Кроме того, любые DLL, загруженные из списка KnownDLLs (они постоянно проецируются в память) или, наоборот, загруженные ими, нельзя переадресовывать по такому механизму.

Продолжая работу над решением этой проблемы, Microsoft ввела в Windows XP общие сборки (shared assemblies). Сборка (assembly) состоит из группы ресурсов, в том числе DLL и XML-файла манифеста, который описывает сборку и ее содержимое. Приложение ссылается на сборку через свой XML-манифест. Манифестом может быть файл в каталоге приложения с тем же именем, что и само приложение, но с добавленным расширением «.manifest» (например application.exe.ma-nifest), либо он может быть включен в приложение как ресурс. Манифест описывает приложение и его зависимости от сборок.

Существует два типа сборок: закрытые (private) и общие (shared). Общие сборки отличаются тем, что они подписываются цифровой подписью; это позволяет обнаруживать их повреждение или модификацию. Помимо этого, общие сборки хранятся в каталоге \Windows\Winsxs, тогда как закрытые — в каталоге приложения. Таким образом, с общими сборками сопоставлен файл каталога (.cat), содержащий информацию о цифровых подписях. Общие сборки могут содержать несколько версий какой-либо DLL, чтобы приложения, зависимые от определенной версии этой DLL, всегда могли использовать именно ее.

Обычно файлу манифеста сборки присваивается имя, которое включает имя сборки, информацию о версии, некий текст, представляющий уникальную сигнатуру, и расширение. manifest. Манифесты хранятся в каталоге \Windows\Winsxs\Manifests, а остальные ресурсы сборки — в подкаталогах \Windows\Winsxs с теми же именами, что и у соответствующих файлов манифестов, но без расширения. manifest.

Пример общей сборки — 6-я версия DLL стандартных элементов управления Windows, comctl32.dll, которая является новинкой Windows XP. Ee файл манифеста называется \Windows\Winsxs\Manifest\x86_Microsoft.Windows.CommonControls_6595b64144ccfldf_6.0.0.0_x-ww_1382d70a.manifest. C ним сопоставлен файл каталога (с тем же именем, но с расширением. cat) и подкаталог в Winsxs, включающий comctl32.dll.

Comctl32.dll версии 6 обеспечивает интеграцию с темами Windows XP и из-за того, что приложения, написанные без учета поддержки тем, могут неправильно выглядеть на экране при использовании этой новой DLL, она доступна только тем приложениям, которые явно ссылаются на ее общую сборку. Версия Comctl32.dll, установленная в \Win-dows\System32, — это экземпляр версии 5.x, не поддерживающей темы. Загружая приложение, загрузчик ищет его манифест и, если таковой есть, загружает DLL-модули из указанной сборки. DLL, не включенные в сборки, на которые ссылается манифест, загружаются традиционным способом. Поэтому унаследованные приложения связываются с версией в \Windows\System32, а новые приложения с поддержкой тем могут ссылаться на новую версию в своих манифестах.

Чтобы увидеть, какой эффект дает манифест, указывающий системе задействовать новую библиотеку стандартных элементов управления в Windows XP, запустите User State Migration Wizard (\Windows\System32\Usmt\Migwiz.exe) с файлом манифеста и без него.

1. Запустите этот мастер и обратите внимание на темы Windows XP на кнопках в мастере.

2. Откройте файл манифеста в Notepad и найдите упоминание 6-й версии библиотеки стандартных элементов управления.

3. Переименуйте Migwiz.exe.manifest в Migwiz.exe.manifest.bak.

4. Вновь запустите мастер и обратите внимание на кнопки без тем.

5. Восстановите исходное имя файла манифеста.

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

Внутреннее устройство потоков

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

Структуры данных

Ha уровне операционной системы поток представляется блоком потока, принадлежащим исполнительной системе (ETHREAD). Структура этого блока показана на рис. 6–7. Блок ETHREAD и все структуры данных, на которые он ссылается, существуют в системном адресном пространстве, кроме блока переменных окружения потока (thread environment block, TEB) — он размещается в адресном пространстве процесса. Помимо этого, процесс подсистемы Windows (Csrss) поддерживает параллельную структуру для каждого потока, созданного в Windows-процессе. Часть подсистемы Windows, работающая в режиме ядра (Win32k.sys), также поддерживает для каждого потока, вызывавшего USER- или GDI-функцию, структуру W32THREAD, на которую указывает блок ETHREAD.

Поля блока потока, показанные на рис. 6–7, в большинстве своем не требуют дополнительных пояснений. Первое поле — это блок потока ядра (KTHREAD). За ним следуют идентификационные данные потока и процесса (включая указатель на процесс — владелец данного потока, что обеспечивает доступ к информации о его окружении), затем информация о защите в виде указателя на маркер доступа и сведения, необходимые для олицетворения (подмены одного процесса другим), а также поля, связанные с сообщениями LPC и незавершенными запросами на ввод-вывод. B таблице 6–8 даны ссылки на другие части книги, где некоторые из наиболее важных полей описываются подробнее. Чтобы получить более детальные сведения о внутренней структуре блока ETHREAD, используйте команду dt отладчика ядра.

Давайте повнимательнее присмотримся к двум ключевым структурам потока, упомянутым выше, — к блокам KTHREAD и TEB. Первый содержит информацию, нужную ядру Windows для планирования потоков и их синхронизации с другими потоками. Схема блока KTHREAD показана на рис. 6–8.

Ключевые поля блока KTHREAD кратко рассмотрены в таблице 6–9.

Таблица 6–9. Ключевые поля блока KTHREAD

ЭКСПЕРИМЕНТ: просмотр структур ETHREAD и KTHREAD

Структуры ETHREAD и KTHREAD можно просмотреть с помощью команды dt отладчика ядра. B следующем выводе показан формат ETHREAD:

Для просмотра KTHREAD предназначена аналогичная команда:

ЭКСПЕРИМЕНТ: использование команды !thread отладчика ядра

Команда !thread отладчика ядра выдает дамп подмножества информации из структур данных потока. Отладчик ядра выводит ряд важных данных, не показываемых любыми другими утилитами: адреса внутренних структур, детальные сведения о приоритетах, данные стека, список незавершенных запросов на ввод-вывод и список ожидаемых объектов для тех потоков, которые находятся в состоянии ожидания.

Чтобы получить информацию о потоке, используйте либо команду !process (которая выводит все блоки потоков после блока процесса), либо команду !thread (которая сообщает сведения только об указанном потоке). Ниже дан пример информации о потоке с пояснением ее важнейших полей.

Адрес Идентификатор ETHREAD потока Адрес TEB

ЭКСПЕРИМЕНТ: просмотр информации о потоке

Утилита Tlist из Windows Debugging Tools позволяет получить подробную информацию о процессе, пример которой приведен ниже. Заметьте, что в списке потоков указывается «Win32StartAddress». Это адрес, передаваемый функции CreateThread приложением. Остальные утилиты, кроме Process Explorer, показывающие стартовый адрес потока, выводят его истинный стартовый адрес, а не стартовый адрес, заданный приложением.

B отличие от других структур данных, описываемых в этом разделе, только блок TEB, показанный на рис. 6–9, присутствует в адресном пространстве процесса, а не системы. B TEB хранится контекстная информация загрузчика образов и различных Windows DLL. Поскольку эти компоненты выполняются в пользовательском режиме, им нужны структуры данных, доступные для записи из этого режима. Вот почему TEB размещается в адресном пространстве процесса, а не системы, где он был бы доступен для записи только из режима ядра. Адрес TEB можно найти с помощью команды !thread отладчика ядра.

ЭКСПЕРИМЕНТ: исследуем TEB

Вы можете получить дамп структуры TEB, используя команду !teb отладчика ядра. Ee вывод выглядит так:

Переменные ядра

Как и в случае процессов, ряд переменных ядра Windows контролирует выполнение потоков. Список таких переменных, связанных с потоками, приводится в таблице 6-10.

Таблица 6-10. Переменные ядра, относящиеся к потокам

Счетчики производительности

Большая часть важной информации в структурах данных потоков экспортируется в виде счетчиков производительности, перечисленных в таблице 6-11. Даже используя только оснастку Performance, вы можете получить довольно много сведений о внутреннем устройстве потоков.

Сопутствующие функции

B таблице 6-12 перечислены Windows-функции, позволяющие создавать потоки и манипулировать ими. Здесь не показаны функции, связанные с планированием и управлением приоритетами потоков, — они описываются в разделе «Планирование потоков» далее в этой главе.

Рождение потока

Жизненный цикл потока начинается при его создании программой. Запрос на его создание в конечном счете поступает исполнительной системе Windows, где диспетчер процессов выделяет память для объекта «поток» и вызывает ядро для инициализации блока потока ядра. Ниже перечислены основные этапы создания потока Windows-функцией CreateThread (которая находится в Kernel32.dll).

1. CreateThread создает стек пользовательского режима в адресном пространстве процесса.

2. CreateThread инициализирует аппаратный контекст потока, специфичный для конкретной архитектуры процессора. (Подробнее о блоке контекста потока см. раздел справочной документации Windows API по структуре CONTEXT.)

3. Для создания объекта «поток» исполнительной системы вызывается Nt-CreateThread. Он создается в приостановленном состоянии. Описание операций, выполняемых NtCreateThread, см. в разделе «Что делает функция CreateProcess» (этапы 3 и 6) ранее в этой главе.

4. CreateThread уведомляет подсистему Windows о создании нового потока, и та выполняет некоторые подготовительные операции.

5. Вызвавшему коду возвращаются описатель и идентификатор потока (сгенерированный на этапе 3).

6. Выполнение потока возобновляется, и ему может быть выделено процессорное время, если только он не был создан с флагом CREATE_SUSPENDED. Перед вызовом по пользовательскому стартовому адресу поток выполняет операции, описанные в разделе «Этап 3: создание первичного потока, его стека и контекста» ранее в этой главе.

Наблюдение за активностью потоков

He только оснастка Performance, но и другие утилиты (таблица 6-13) позволяют получать сведения о состоянии потоков в Windows. (Утилиты, показывающие информацию о планировании потоков, перечисляются в разделе «Планирование потоков» далее в этой главе.)

ПРИМЕЧАНИЕ Чтобы получить информацию о потоке с помощью Tlist, введите tlistxxx, где xxx — имя образа процесса или заголовок окна (можно использовать символы подстановки).

Process Explorer позволяет наблюдать за активностью потоков в процессе. Это особенно важно, когда вы пытаетесь понять, почему процесс зависает или запускается какой-то процесс, служащий хостом для множества сервисов (например, Svchost.exe, Dllhost.exe, Inetinfo.exe или System).

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

Новые потоки выделяются зеленым, а существующие — красным. (Длительность подсветки настраивается в Options.) Это помогает обнаруживать создание лишних потоков в процессе. (Как правило, потоки должны создаваться при запуске процесса, а не при каждой обработке какого-либо запроса внутри процесса.)

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

Разница в числе переключений контекста (context switch delta) отражает, сколько раз потоки начинали работать в течение периода обновления, указанного в Process Explorer. Это еще один способ определения активности потоков. B некоторых отношениях он даже лучше, так как многие потоки выполняются в течение лишь очень короткого времени и поэтому крайне редко попадают в список текущих потоков. Например, если вы добавите столбец с разницей в числе переключений контекстов к тому, что показывается для процесса и отсортируете по этому столбцу, то увидите процессы, в которых потоки выполняются, но используют очень мало процессорного времени или вообще его не используют.

Стартовый адрес потока выводится в виде «module\function», где module — имя EXE или DLL. Имя функции извлекается из файла символов для данного модуля (см. эксперимент «Просмотр детальных сведений о процессах с помощью Process Explorer» в главе 1). Если вы точно не знаете, что это за модуль, нажмите кнопку Module, и появится окно свойств модуля, где содержится данная функция.

ПРИМЕЧАНИЕ Для потоков, созданных Windows-функцией Create-Tbread, Process Explorer показывает функцию, переданную в Create-Tbread, а не истинную стартовую функцию потока. Это связано с тем, что все Windows-потоки запускаются в общей стартовой функции-оболочке для процессов или потоков (BaseProcessStartJin6oBaseThre-adStart в Kernel32.dll). Если бы Process Explorer выводил истинный стартовый адрес, то казалось бы, что большинство потоков в процессе были запущены по одному адресу, а это вряд ли помогло бы понять, какой код выполняется потоком.

Однако одного стартового адреса потока может оказаться недостаточно для того, чтобы выяснить, что именно делает поток и какой компонент внутри процесса отвечает за использование процессорного времени этим потоком. Это особенно верно, если стартовый адрес потока относится к универсальной стартовой функции (например, если имя функции не указывает на то, что делает данный поток). Тогда может помочь изучение стека потока. Для его просмотра дважды щелкните интересующий вас поток (или выберите этот поток и нажмите кнопку Stack). Process Explorer покажет стек потока (пользовательского режима и режима ядра, если поток был в последнем режиме).

ПРИМЕЧАНИЕ Отладчики пользовательского режима (Windbg, Ntsd и Cdb) тоже позволяют подключаться к процессу и просматривать стек потока, но Process Explorer выводит стек как пользовательского режима, так и режима ядра простым нажатием одной кнопки. Стеки пользовательского режима и режима ядра можно, но эта утилита гораздо сложнее в использовании. Кстати, при работе Windbg в режиме локальной отладки ядра, поддерживаемом только в Windows XP и Windows Server 2003, увидеть содержимое стеков потоков нельзя.

Просмотр стека потока полезен и при поиске причины зависания процесса. Например, на одной системе Microsoft PowerPoint зависал при запуске на минуту. Чтобы понять причину этого зависания, с помощью Process Explorer изучили стек одного из потоков в процессе. Результат приведен на рис. 6-10.

Как видите, PowerPoint (строка 10) вызвал функцию в Mso.dll (основной Microsoft Office DLL), которая обратилась к функции OpenPrinterWB Winspool.drv (DLL, используемой для подключения к принтерам). Затем Winspool.drv пересылает запрос функции OpenPrinterRPC, а та вызывает функцию в DLL исполняющей среды RPC, сообщая, что запрос посылается удаленному принтеру. Вот так, не зная деталей внутреннего устройства PowerPoint, по именам модулей и функций в стеке потока можно понять, что поток ждет соединения с сетевым принтером. B данной системе был сетевой принтер, который не отвечал, что и объясняет задержку в запуске PowerPoint. (Приложения Microsoft Office соединяются со всеми сконфигурированными принтерами при запуске.) Соединение с тем принтером было удалено из пользовательской системы, и проблема исчезла.

Планирование потоков

Здесь описываются стратегии и алгоритмы планирования в Windows. B первом разделе этой части материалов рассматриваются принципы планирования в Windows и даются определения ключевых терминов. Уровни приоритета обсуждаются с точки зрения как Windows API, так и ядра. После обзора сопутствующих Windows-функций и утилит подробно анализируются — сначала в однопроцессорных системах, а затем и в многопроцессорных — алгоритмы и структуры данных, используемые подсистемой планирования Windows.

Обзор планирования в Windows

B Windows реализована подсистема вытесняющего планирования на основе уровней приоритета, в которой всегда выполняется поток с наибольшим приоритетом, готовый к выполнению. Однако выбор потока для выполнения может быть ограничен набором процессоров, на которых он может работать. Это явление называется привязкой к процессорам (processor affinity). По умолчанию поток выполняется на любом доступном процессоре, но вы можете изменить привязку к процессорам через Windows-функции планирования, перечисленные в таблице 6-14 (см. далее в этой главе), или заданием маски привязки в заголовке образа.

ЭКСПЕРИМЕНТ: просмотр потоков, готовых к выполнению

Список потоков, готовых к выполнению, можно увидеть с помощью команды !ready отладчика ядра. Она выводит поток или список потоков, готовых к выполнению (на каждом уровне приоритета отдельно). B следующем примере к выполнению готовы два потока с приоритетом 10 и шесть потоков — с приоритетом 8. Поскольку эта информация получена в однопроцессорной системе с использованием LiveKd, текущим потоком всегда является отладчик ядра (Kd или WinDbg).

Выбранный для выполнения поток работает в течение некоего периода, называемого квантом. Квант определяет, сколько времени будет выполняться поток, пока не наступит очередь другого потока с тем же приоритетом (или более высоким, что возможно в многопроцессорной системе). Длительность квантов зависит от трех факторов: конфигурационных параметров системы (длинные или короткие кванты), статуса процесса (активный или фоновый) и использования объекта «задание» для изменения длительности квантов. (Подробнее о квантах см. раздел «Квант» далее в этой главе.) Однако поток может не полностью использовать свой квант. Поскольку в Windows реализован вытесняющий планировщик, то происходит вот что. Как только другой поток с более высоким приоритетом готов к выполнению, текущий поток вытесняется, даже если его квант еще не истек. Фактически поток может быть выбран следующим для выполнения и вытеснен, не успев воспользоваться своим квантом!

Код Windows, отвечающий за планирование, реализован в ядре. Поскольку этот код рассредоточен по ядру, единого модуля или процедуры с названием «планировщик» нет. Совокупность процедур, выполняющих эти обязанности, называется диспетчерам ядра (kernel's dispatcher). Диспетчеризация потоков может быть вызвана любым из следующих событий.

• Поток готов к выполнению — например, он только что создан или вышел из состояния ожидания.

• Поток выходит из состояния Running (выполняется), так как его квант истек или поток завершается либо переходит в состояние ожидания.

• Приоритет потока изменяется в результате вызова системного сервиса или самой Windows.

• Изменяется привязка к процессорам, из-за чего поток больше не может работать на процессоре, на котором он выполнялся.

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

Как уже говорилось, планирование в Windows осуществляется на уровне потоков. Этот подход станет понятен, если вы вспомните, что сами процессы не выполняются, а лишь предоставляют ресурсы и контекст для выполнения потоков. Поскольку решения, принимаемые в ходе планирования, касаются исключительно потоков, система не обращает внимания на то, какому процессу принадлежит тот или иной поток. Так, если у процесса A есть 10, у процесса B — 2 готовых к выполнению потока, и все 12 имеют одинаковый приоритет, каждый из потоков теоретически получит 1/12 процессорного времени, потому что Windows не станет поровну делить процессорное время между двумя процессами.

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

Уровни приоритета

Как показано на рис. 6-11, в Windows предусмотрено 32 уровня приоритета — от 0 до 31. Эти значения группируются так:

• шестнадцать уровней реального времени (16–31);

• пятнадцать варьируемых (динамических) уровней (1-15);

• один системный уровень (0), зарезервированный для потока обнуления страниц (zero page thread).

Уровни приоритета потока назначаются с учетом двух разных точек зрения — Windows API и ядра Windows. Windows API сначала упорядочивает процессы по классам приоритета, назначенным при их создании [Real-time (реального времени), High (высокий), Above Normal (выше обычного), Normal (обычный), Below Normal (ниже обычного) и IdIe (простаивающий)], а затем — по относительному приоритету индивидуальных потоков в рамках этих процессов [Time-critical (критичный по времени), Highest (наивысший), Above-normal (выше обычного), Normal (обычный), Below-normal (ниже обычного), Lowest (наименьший) и IdIe (простаивающий)].

Базовый приоритет каждого потока в Windows API устанавливается, исходя из класса приоритета его процесса и относительного приоритета самого потока. Связь между приоритетами Windows API и внутренними приоритетами ядра Windows (в числовой форме) показана на рис. 6-12.

Если у процесса только одно значение приоритета (базовое), то у каждого потока их два: текущее и базовое. Решения, связанные с планированием, принимаются на основе текущего приоритета. Как поясняется в следующем разделе, в определенных обстоятельствах система может на короткое время повышать приоритеты потоков в динамическом диапазоне (1-15). Windows никогда не изменяет приоритеты потоков в диапазоне реального времени (16–31), поэтому у таких потоков базовый приоритет идентичен текущему.

Рис. 6-12. Взаимосвязь приоритетов в ядре и Windows API

Начальный базовый приоритет потока наследуется от базового приоритета процесса, а тот наследует его от родительского процесса. Это поведение можно изменить при вызове Windows-функции CreateProcess или команды START. Приоритет процесса можно изменить и после его создания, используя функцию SetPriorityClass или различные утилиты, предоставляющие доступ к этой функции через UI, например диспетчер задач и Process Explorer. B частности, вы можете понизить приоритет процесса, интенсивно использующего процессорное время, чтобы он не мешал обычным операциям в системе. Смена приоритета процесса влечет за собой смену приоритетов всех его потоков, но их относительные приоритеты остаются прежними. Ho изменение приоритетов индивидуальных потоков внутри процесса обычно не имеет смысла, потому что вы не знаете, чем именно занимается каждый из них (если только сами не пишете программу или не располагаете исходным кодом); так что изменение относительных приоритетов потоков может привести к неадекватному поведению этого приложения.

Обычно базовый приоритет процесса (а значит, и базовый приоритет первичного потока) по умолчанию равен значению из середины диапазонов приоритетов процессов (24, 13, 10, 8, 6 или 4). Однако базовый приоритет некоторых системных процессов (например, диспетчера сеансов, контроллера сервисов и сервера локальной аутентификации) несколько превышает значение по умолчанию для класса Normal (8). Более высокий базовый приоритет по умолчанию обеспечивает запуск потоков этих процессов с приоритетом выше 8. Чтобы изменить свой начальный базовый приоритет, такие системные процессы используют внутреннюю функцию NtSetInformationProcess.

Функции Windows API, связанные с планированием

Эти функции перечислены в таблице 6-14 (более подробную информацию см. в справочной документации Windows API).

Таблица 6-14. API-функции планирования и их назначение

Сопутствующие утилиты

B следующей таблице перечислены утилиты, сообщающие информацию о планировании потоков. Базовый приоритет процесса можно увидеть (и изменить) с помощью диспетчера задач, Process Explorer, Pview или Pviewer. Заметьте, что Process Explorer позволяет уничтожать отдельные потоки в любых процессах. Ho, конечно же, этой возможностью следует пользоваться с крайней осторожностью.

Приоритеты потоков можно просмотреть в оснастке Performance (Производительность), а также с помощью утилит Process Explorer, Plist, Pview, Pviewer и Pstat. Хотя повышение или понижение приоритета процесса может оказаться весьма полезным, изменение приоритетов индивидуальных потоков внутри процесса, как правило, не имеет смысла, потому что постороннему человеку не известно, что делают эти потоки и почему важны именно такие их относительные приоритеты.

Единственный способ задать начальный класс приоритета для процесса — использовать команду start в командной строке Windows. Если вы хотите, чтобы некая программа каждый раз запускалась с определенным приоритетом, то можете создать для нее ярлык и указать команду запуска, предварив ее cmd /с. Это приведет к появлению окна командной строки, выполнению команды и последующему закрытию этого окна. Например, чтобы запустить Notepad в процессе с низким приоритетом, в свойствах ярлыка должна быть задана команда cmd /с start /low notepad.exe.

ЭКСПЕРИМЕНТ: исследуем и задаем приоритеты процессов и потоков

Попробуйте провести такой эксперимент.

1. Наберите в командной строке start /realtime notepad. Ha экране появится окно Notepad.

2. Запустите утилиту Process Explorer или Process Viewer (Pviewer.exe) из Support Tools и выберите Notepad.exe из списка процессов, как показано ниже. Заметьте, что динамический приоритет потока Notepad равен 24. Это значение совпадает со значением приоритета реального времени на рис. 6-12.

3. Аналогичную информацию можно получить в диспетчере задач. Для его запуска нажмите клавиши Ctrl+Shift+Esc и перейдите на вкладку Processes (Процессы). Щелкните правой кнопкой мыши процесс Notepad.exe и выберите команду Set Priority (Приоритет). Вы увидите, что класс приоритета потока относится к Realtime (Реального времени), как показано на следующей иллюстрации.

Диспетчер системных ресурсов Windows

B Windows Server 2003 Enterprise Edition и Windows Server 2003 Data-center Edition включен необязательный компонент, который называется диспетчером системных ресурсов Windows (Windows System Resource Manager, WSRM). Он позволяет администратору настраивать правила политики, указывающие для процессов использование процессорного времени, параметры привязки к процессорам и лимиты на физическую и виртуальную память. Кроме того, WSRM может генерировать отчеты по использованию ресурсов, удобные для учета и проверки уровня обслуживания по договорам с пользователями.

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

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

Ограничение физической памяти достигается заданием максимального размера рабочего набора через функцию SetProcessWorkingSetSizeEx, а ограничение виртуальной памяти реализуется самой службой (о лимитах на объемы физической и виртуальной памяти см. главу 7). Если заданный лимит превышен, WSRM — в зависимости от настроек — может уничтожать процессы или создавать соответствующую запись в журнале событий. Последнее позволяет выявить процесс с утечкой памяти до того, как он займет всю переданную виртуальную память в системе. Заметьте, что лимиты на память, установленные в WSRM, не применяются к памяти Address Windowing Extensions (AWE), памяти больших страниц (large page memory) или памяти ядра (пулу подкачиваемых или неподкачиваемых страниц).

Приоритеты реального времени

Вы можете повысить или понизить приоритет потока любого приложения в динамическом диапазоне; однако, чтобы задать значение из диапазона реального времени, у вас должна быть привилегия Increase Scheduling Priority. Учтите, что многие важные системные потоки режима ядра выполняются в диапазоне приоритетов реального времени. Поэтому, если потоки слишком долго выполняются с приоритетом этого диапазона, они могут блокировать критичные системные функции (например в диспетчере памяти, диспетчере кэша или драйверах устройств).

ПРИМЕЧАНИЕ Как показано на следующей иллюстрации, где изображены уровни запросов прерываний (Interrupt Request Levels, IRQL) на платформе x86, в Windows имеется набор приоритетов, называемых приоритетами реального времени, но они не являются таковыми в общепринятом смысле этого термина, так как Windows не относится к операционным системам реального времени. Подробнее на эту тему см. врезку «Windows и обработка данных в реальном времени» в главе 3, а также статью «Real-Time Systems and Microsoft Windows NT» в MSDN Library.

Уровни прерываний и уровни приоритета

Как показано на следующей иллюстрации, потоки обычно выполняются при IRQL, равном 0 или 1. (Описание уровней прерываний в Windows см. в главе 3.) Потоки пользовательского режима всегда выполняются при IRQL, равном 0. Ввиду этого ни один поток пользовательского режима независимо от его приоритета не в состоянии блокировать аппаратные прерывания (хотя потоки с высоким приоритетом из диапазона реального времени способны блокировать важные системные потоки). При IRQL, равном 1, работают только APC режима ядра, поскольку они прерывают выполнение потоков (об APC см. главу 3). Кроме того, потоки, выполняемые в режиме ядра, могут повышать IRQL, например при обработке системного вызова, требующего диспетчеризации потоков.

Состояния потоков

Прежде чем перейти к алгоритмам планирования потоков, вы должны разобраться, в каких состояниях могут находиться потоки в процессе выполнения в Windows 2000 и Windows XR Соответствующая схема дана на рис. 6-13 [числовые значения отражают показатели счетчика производительности Thread: thread state (Поток-. Состояние потока)].

Вот что представляют собой состояния потока.

• Ready (готов) Поток в состоянии готовности ожидает выполнения. Выбирая следующий поток для выполнения, диспетчер принимает во внимание только пул потоков, готовых к выполнению.

• Standby (простаивает) Поток в этом состоянии уже выбран следующим для выполнения на конкретном процессоре. B подходящий момент диспетчер переключает контекст на этот поток. B состоянии Standby может находиться только один поток для каждого процессора в системе. Заметьте, что поток может быть вытеснен даже в этом состоянии (если, например, до начала выполнения потока, который пока находится в состоянии Standby, к выполнению будет готов поток с более высоким приоритетом).

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

• Waiting (ожидает) Поток входит в состояние Waiting несколькими способами. Он может самостоятельно начать ожидание на синхронизирующем объекте или его вынуждает к этому подсистема окружения. По окончании ожидания поток — в зависимости от приоритета — либо немедленно начинает выполняться, либо переходит в состояние Ready.

• Transition (переходное состояние) Поток переходит в это состояние, если он готов к выполнению, но его стек ядра выгружен из памяти. Как только этот стек загружается в память, поток переходит в состояние Ready.

• Terminated (завершен) Заканчивая выполнение, поток переходит в состояние Terminated. После этого блок потока исполнительной системы (структура данных в пуле неподкачиваемой памяти, описывающая данный поток) может быть удален, а может быть и не удален — это уже определяется диспетчером объектов.

• Initialized (инициализирован) B это состояние поток входит в процессе своего создания.

ЭКСПЕРИМЕНТ: изменение состояний потоков при планировании

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

1. Запустите стандартную программу Notepad (Блокнот) (Notepad.exe).

2. Запустите оснастку Performance (Производительность), открыв в меню Start (Пуск) подменю Programs (Программы) и Administrative Tools (Администрирование), а затем выбрав команду Performance (Производительность).

3. Выберите режим просмотра диаграмм (если установлен какой-то другой).

4. Щелкните график правой кнопкой мыши и выберите команду Properties (Свойства).

5. Откройте вкладку Graph (График) и установите максимальное значение вертикальной шкалы равным 7. (Состояниям потоков соответствуют числа от O до 7). Щелкните кнопку ОК.

6. Щелкните на панели инструментов кнопку Add (Добавить), чтобы открыть диалоговое окно Add Counters (Добавить счетчики).

7. Выберите в списке объект Thread (Поток), а затем — счетчик Thread State (Состояние потока). Определение его значений вы увидите, щелкнув кнопку Explain (Объяснение), как показано ниже.

8. Прокрутите список вхождений до строки notepad/O (это процесс Notepad), выделите его и щелкните кнопку Add (Добавить).

9. Прокрутите список назад до процесса Mmc (это процесс Microsoft Management Console, в котором выполняется ActiveX-элемент System Monitor), выберите все его потоки (mmc/0, mmc/1 и т. д.) и добавьте их на график, щелкнув кнопку Add. Прежде чем щелкнуть кнопку Add, вы должны увидеть диалоговое окно, аналогичное показанному ниже.

10. Теперь закройте диалоговое окно Add Counters, щелкнув кнопку Close (Закрыть).

11. Вы должны увидеть, что поток Notepad (верхняя линия графика) находится в состоянии 5. Как вы уже знаете, значение 5 соответствует состоянию Waiting. (B данном случае поток ждет GUI-ввода.)

12. Заметьте, что один из потоков процесса Mmc (выполняющий оснастку Performance) находится в состоянии Running (значение 2). Этот поток всегда выполняется, так как постоянно запрашивает состояние других потоков.

13. Вы никогда не увидите процесс Notepad в состоянии Running (если только не используете многопроцессорную систему), поскольку в этом состоянии всегда находится Mmc, собирая данные о состоянии отслеживаемых потоков.

Схема состояний потоков в Windows Server 2003 показана на рис. 6-14. Обратите внимание на новое состояние Deferred Ready (готов, отложен). Это состояние используется для потоков, выбранных для выполнения на конкретном процессоре, но пока не запланированных к выполнению. Это новое состояние предназначено для того, чтобы ядро могло свести к минимуму срок применения общесистемной блокировки к базе данных планирования (scheduling database). (Этот процесс подробно описывается в разделе «База данных диспетчера ядра в многопроцессорной системе».)

База данных диспетчера ядра

Для принятия решений при планировании потоков ядро поддерживает набор структур данных, в совокупности известных как база данных ducnem-чераядра (dispatcher database) (рис. 6-15). Эта база данных позволяет отслеживать потоки, ждущие выполнения, и потоки, выполняемые на тех или иных процессорах.

ПРИМЕЧАНИЕ База данных диспетчера ядра в однопроцессорной системе имеет ту же структуру, что и в многопроцессорных системах Windows 2000 и Windows XP, но отличается от структуры такой базы данных в системах Windows Server 2003. Эти различия, а также иной алгоритм выбора потоков для выполнения в многопроцессорных системах поясняются в разделе «Многопроцессорные системы».

Очереди готовых потоков (ready queues) диспетчера ядра включают потоки в состоянии Ready, ожидающие выделения им процессорного времени. Для каждого из 32 уровней приоритета существует по одной очереди. Для ускорения выбора потока, подлежащего выполнению или вытеснению, Windows поддерживает 32-битную маску, называемую сводкой готовности (ready summary) (KiReadySummary). Каждый установленный в ней бит указывает на присутствие одного или более потоков в очереди готовых потоков для данного уровня приоритета (бит 0 соответствует приоритету 0, бит 1 — приоритету 1 и т. д.).

B таблице 6-15 перечислены переменные ядра, связанные с планированием потоков в однопроцессорных системах.

B однопроцессорных системах база данных диспетчера ядра синхронизируется повышением IRQL до уровня «DPC/dispatch» и SYNCH_LEVEL (оба определены как уровень 2). (Об уровнях приоритета прерываний см. раздел «Диспетчеризация ловушек» главы 3) Такое повышение IRQL не дает другим потокам прервать диспетчеризацию потоков, так как потоки обычно выполняются при IRQL O или 1. B многопроцессорных системах одного повышения IRQL мало, потому что каждый процессор может одновременно увеличить IRQL до одного уровня и попытаться обратиться к базе данных диспетчера ядра. Как Windows синхронизирует доступ к этой базе данных в многопроцессорных системах, поясняется в разделе «Многопроцессорные системы» далее в этой главе.

Квант

Как уже говорилось, квант — это интервал процессорного времени, отведенный потоку для выполнения. По его окончании Windows проверяет, ожидает ли выполнения другой поток с таким же уровнем приоритета. Если на момент истечения кванта других потоков с тем же уровнем приоритета нет, Windows выделяет текущему потоку еще один квант.

По умолчанию в Windows 2000 Professional и Windows XP потоки выполняются в течение 2 интервалов таймера (clock intervals), а в системах Windows Server — 12. (Как изменить эти значения, мы объясним позже.) B серверных системах величина кванта увеличена для того, чтобы свести к минимуму переключение контекста. Получая больший квант, серверные приложения, которые пробуждаются при получении клиентского запроса, имеют больше шансов выполнить запрос и вернуться в состояние ожидания до истечения выделенного кванта.

Длительность интервала таймера зависит от аппаратной платформы и определяется HAL, а не ядром. Например, этот интервал на большинстве однопроцессорных х86-систем составляет 10 мс, а на большинстве многопроцессорных х86-систем — около 15 мс. (Как проверить реальный интервал системного таймера, см. в следующем эксперименте.)

ЭКСПЕРИМЕНТ: определяем величину интервала системного таймера

Windows-функция GetSystemTimeAdjustment возвращает величину интервала системного таймера. Для ее определения запустите программу Clockres с sysinternals.com. Вот что это программа выводит на однопроцессорной х86-системе:

C: \›clockres

ClockRes — View the system clock resolution

By Mark Russinovich

SysInternals — www.sysinternals.com

The system clock interval is 10.014400 ms

Учет квантов времени

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

Внутренне величина кванта хранится как число тактов таймера, умноженное на 3. To есть в Windows 2000 и Windows XP потоки по умолчанию получают квант величиной 6 (2 * 3), в Windows Server — 36 (12 * 3). Всякий раз, когда возникает прерывание таймера, процедура его обработки вычитает из кванта потока постоянную величину (3).

Почему квант внутренне хранится как величина, кратная трем квантовым единицам за один такт системного таймера? Это сделано для того, чтобы можно было уменьшать значение кванта по завершении ожидания. Когда поток с текущим приоритетом ниже 16 и базовым приоритетом ниже 14 запускает функцию ожидания (WaitForSingleObject или WaitForMultipleObjects) и его запрос на доступ удовлетворяется немедленно (например, он не переходит в состояние ожидания), его квант уменьшается на одну единицу. Благодаря этому кванты ожидающих потоков в конечном счете заканчиваются.

Если запрос на доступ не удовлетворяется немедленно, кванты потоков с приоритетом ниже 16 тоже уменьшаются на одну единицу (кроме случая, когда поток пробуждается для выполнения APC ядра). Ho перед такой операцией квант потока с приоритетом 14 или выше сбрасывается. Это делается и для потоков с приоритетом менее 14, если они не выполняются при специально повышенном приоритете (как, например, в случае фоновых процессов или при недостаточном выделении процессорного времени) и если их приоритет повышен в результате выхода из состояния ожидания (unwait operation). (Динамическое повышение приоритета поясняется в следующем разделе.)

Управление величиной кванта

Вы можете изменить квант для потоков всех процессов, но выбор ограничен всего двумя значениями: короткий квант (2 такта таймера, используется по умолчанию для клиентских компьютеров) или длинный (12 тактов таймера, используется по умолчанию для серверных систем).

ПРИМЕЧАНИЕ Используя объект «задание» в системе с длинными квантами, вы можете указать другие величины квантов для процессов в задании. Более подробную информацию об объектах «задание» см. в разделе «Объекты-задания» далее в этой главе.

Для изменения величины кванта в Windows 2000 щелкните правой кнопкой мыши My Computer (Мой компьютер), выберите Properties (Свойства), перейдите на вкладку Advanced (Дополнительно), а затем щелкните кнопку Performance Options (Параметры быстродействия). Вы увидите диалоговое окно, показанное на рис. 6-l6.

Для изменения величины кванта в Windows XP или Windows Server 2003 щелкните правой кнопкой мыши My Computer (Мой компьютер), выберите Properties (Свойства), перейдите на вкладку Advanced (Дополнительно), щелкните кнопку Settings (Параметры) в разделе Performance (Быстродействие), а затем перейдите на вкладку Advanced (Дополнительно). Соответствующие диалоговые окна в Windows XP и Windows Server 2003 немного различаются. Они показаны на рис. 6-17.

Параметр Programs (Программ), который в Windows 2000 назывался Applications (Приложений), соответствует использованию коротких квантов переменной величины — этот вариант действует для Windows 2000 Professional и Windows XP по умолчанию. Если вы установите Terminal Services в систему Windows Server и настроите ее как сервер приложений, то и в такой системе будет выбран именно этот параметр, чтобы пользователи сервера терминала получали одинаковые кванты, как и в клиентских или персональных системах. Работая с Windows Server как с персональной операционной системой, вы также могли бы вручную выбрать этот параметр.

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

Еще одно различие между параметрами Programs и Background Services заключается в том, какой эффект они оказывают на кванты потоков в активном процессе. Об этом рассказывается в следующем разделе.

Динамическое увеличение кванта

До Windows NT 4.0, когда на рабочей станции или в клиентской системе какое-то окно становилось активным, приоритет всех потоков активного процесса (которому принадлежит поток, владеющий окном в фокусе ввода) динамически повышался на 2. Повышенный приоритет действовал до тех пор, пока любому потоку процесса принадлежало активное окно. Проблема с этим подходом была в том, что, если вы запустили длительный процесс, интенсивно использующий процессор (например, начали пересчет электронной таблицы), и переключились на другой процесс, требующий больших вычислительных ресурсов (скажем, на одну из программ CAD, графический редактор или какую-нибудь игру), то первый процесс, ставший теперь фоновым, получит лишь очень малую часть процессорного времени (или вообще не получит его). A все дело в том, что приоритет потоков активного процесса повышается на 2 (здесь предполагается, что базовый приоритет потоков обоих процессов был одинаковым).

Это поведение по умолчанию изменилось с появлением Windows NT 4.0 Workstation — кванты потоков активного процесса стали увеличиваться в 3 раза. Таким образом, по умолчанию на рабочих станциях их квант достигал 6 тактов таймера, а у потоков остальных процессов — 2 тактов. Благодаря этому, когда процесс, интенсивно использующий процессорные ресурсы, оказывается фоновым, новый активный процесс получает пропорционально большее процессорное время (и вновь предполагается, что приоритеты потоков одинаковы как в активном, так и в фоновом процессе).

Заметьте, что это изменение квантов относится лишь к процессам с приоритетом выше IdIe в системах с установленным параметром Programs (или Applications в Windows 2000) в диалоговом окне Performance Options (Параметры быстродействия), как пояснялось в предыдущем разделе. Кванты потоков активного процесса в системах с установленным параметром Background Services (настройка по умолчанию в системах Windows Server) не изменяются.

Параметр реестра для настройки кванта

Пользовательский интерфейс, позволяющий изменить относительную величину кванта, модифицирует в реестре параметр HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl\Win32PrioritySeparation. Этот же параметр определяет, можно ли динамически увеличивать (и, если да, то насколько) кванты потоков, выполняемых в активном процессе. Данный параметр содержит 3 двухбитных поля (рис. 6-18).

• Короткие или длинные Значение 1 указывает на длинные кванты, а 2 — на короткие. Если это поле равно 0 или 3, используются кванты по умолчанию (короткие в Windows 2000 Professional или Windows XP и длинные в системах Windows Server).

• Переменные или фиксированные Если задано значение 1, кванты потоков активного процесса могут варьироваться, а если задано значение 2 — нет. Если это поле равно 0 или 3, используется настройка по умолчанию (переменные в Windows 2000 Professional или Windows XP и фиксированные в системах Windows Server).

• Динамическое приращение кванта потока активного процесса Это поле (хранящееся в переменной ядра PsPrioritySeparatiori) может быть равно 0, 1 или 2 (значение 3 недопустимо и интерпретируется как 2) и представляет собой индекс в трехэлементном байтовом массиве (PspForegroundQuantum), используемом для расчета квантов потоков активного процесса. Кванты потоков фоновых процессов определяются первым элементом этого массива. Возможные значения в PspForegroundQuantum перечислены в таблице 6-l6.

Заметьте, что при использовании диалогового окна Performance Options (Параметры быстродействия) доступны лишь две комбинации: короткие кванты с утроением в активном процессе или длинные без изменения в таком процессе. Ho прямое редактирование параметра Win32PrioritySeparation в реестре позволяет выбирать и другие комбинации.

Сценарии планирования

Известно, что вопрос «Какому потоку отдать процессорное время?» Windows 2000 решает, исходя из приоритетов. Ho как этот подход работает на практике? Следующие разделы иллюстрируют, как вытесняющая многозадачность, управляемая на основе приоритетов, действует на уровне потоков.

Самостоятельное переключение

Во-первых, поток может самостоятельно освободить процессор, перейдя в состояние ожидания на каком-либо объекте (например, событии, мьютек-ce, семафоре, порте завершения ввода-вывода, процессе, потоке, оконном сообщении и др.) путем вызова одной из многочисленных Windows-функций ожидания (скажем, WaitForSingleObjectvum WaitForMultipleObjects). Ожидание на объектах было рассмотрено в главе 3.

Ha рис. 6-19 показано, как поток входит в состояние ожидания и как Windows выбирает новый поток для выполнения.

Ha рис. 6-19 поток (верхний блок) самостоятельно освобождает процессор, в результате чего к процессору подключается другой поток из очереди (отмеченный кольцом в колонке Running). Исходя из этой схемы, можно подумать, что приоритет потока, освобождающего процессор, снижается, но это не так — он просто переводится в очередь ожидания выбранных им объектов. A что происходит с оставшейся частью кванта этого потока? Когда поток входит в состояние ожидания, квант не сбрасывается. Как уже говорилось, после успешного завершения ожидания квант потока уменьшается на одну единицу, что эквивалентно трети интервала таймера (исключение составляют потоки с приоритетом от 14 и выше, у которых после ожидания квант сбрасывается).

Вытеснение

B этом сценарии поток с более низким приоритетом вытесняется готовым к выполнению потоком с более высоким приоритетом. Такая ситуация может быть следствием двух обстоятельств:

• завершилось ожидание потока с более высоким приоритетом (т. е. произошло событие, которого он ждал);

• приоритет потока увеличился или уменьшился.

B любом из этих случаев Windows решает, продолжить выполнение текущего потока или вытеснить его потоком с более высоким приоритетом.

ПРИМЕЧАНИЕ Потоки пользовательского режима могут вытеснять потоки режима ядра. To есть режим выполнения потока значения не имеет — определяющим фактором является его приоритет.

Когда поток вытесняется, он помещается в начало очереди готовых потоков соответствующего уровня приоритета. Эту ситуацию иллюстрирует рис. 6-20.

Ha рис. 6-20 поток с приоритетом 18 выходит из состояния ожидания и вновь захватывает процессор, вытесняя выполняемый в этот момент поток (с приоритетом 16) в очередь готовых потоков. Заметьте, что вытесненный поток помещается не в конец, а в начало очереди. После завершения вытеснившего потока вытесненный сможет отработать остаток своего кванта.

Завершение кванта

Когда поток израсходует свой квант процессорного времени, Windows должна решить, следует ли понизить его приоритет и подключить к процессору другой поток.

Снизив приоритет потока, Windows ищет более подходящий для выполнения поток (таким потоком, например, будет любой из очереди готовых потоков с приоритетом выше нового приоритета текущего потока). Если Windows оставляет приоритет потока прежним и в очереди готовых потоков есть другие потоки с тем же приоритетом, она выбирает из очереди следующий поток с тем же приоритетом, а выполнявшийся до этого поток перемещает в хвост очереди (задавая ему новую величину кванта и переводя его из состояния Running в состояние Ready). Этот случай иллюстрирует рис. 6-21. Если ни один поток с тем же приоритетом не готов к выполнению, текущему потоку выделяется еще один квант процессорного времени.

Завершение потока

Завершаясь (после возврата из основной процедуры и вызова ExitThread или из-за уничтожения вызовом TerminateThread), поток переходит в состояние Terminated. Если в этот момент ни один описатель его объекта «поток» не открыт, поток удаляется из списка потоков процесса, и соответствующие структуры данных освобождаются.

Переключение контекста

Контекст потока и процедура его переключения зависят от архитектуры процессора. B типичном случае переключение контекста требует сохранения и восстановления следующих данных:

• указателя команд;

• указателей на стек ядра и пользовательский стек;

• указателя на адресное пространство, в котором выполняется поток (каталог таблиц страниц процесса).

Ядро сохраняет эту информацию, заталкивая ее в текущий стек ядра, обновляя указатель стека и сохраняя его в блоке KTHREAD потока. Далее указатель стека ядра устанавливается на стек ядра нового потока и загружается контекст этого потока. Если новый поток принадлежит другому процессу, в специальный регистр процессора загружается адрес его каталога таблиц страниц, в результате чего адресное пространство этого процесса становится доступным (о трансляции адресов см. в главе 7). При наличии отложенной APC ядра запрашивается прерывание IRQL уровня 1. B ином случае управление передается загруженному для нового потока указателю команд, и выполнение этого потока возобновляется.

Поток простоя

Если нет ни одного потока, готового к выполнению на процессоре, Windows подключает к данному процессору поток простоя (процесса Idle). Для каждого процессора создается свой поток простоя.

Разные утилиты для просмотра процессов в Windows по-разному называют процесс Idle. Диспетчер задач и Process Explorer обозначают его как «System Idle Process», Process Viewer — как «Idle», Pstat — как «Idle Process», Process Explode и Tlist — как «System Process», a Qslice — как «SystemProcess». Windows сообщает, что приоритет потока простоя равен 0. Ho на самом деле у него вообще нет уровня приоритета, поскольку он выполняется лишь в отсутствие других потоков. (Вспомните, что на нулевом уровне приоритета в Windows работает лишь поток обнуления страниц; см. главу 7.)

Холостой цикл, работающий при IRQL уровня «DPC/dispatch», просто запрашивает задания, например на доставку отложенных DPC или на поиск потоков, подлежащих диспетчеризации.

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

1. Включает и отключает прерывания (тем самым давая возможность доставить отложенные прерывания).

2. Проверяет, нет ли у процессора незавершенных DPC (см. главу 3). Если таковые есть, сбрасывает отложенное программное прерывание и доставляет эти DPC

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

4. Вызывает из HAL процедуру обработки процессора в простое (если нужно выполнить какие-либо функции управления электропитанием).

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

Динамическое повышение приоритета

Windows может динамически повышать значение текущего приоритета потока в одном из пяти случаев:

• после завершения операций ввода-вывода;

• по окончании ожидания на событии или семафоре исполнительной системы;

• по окончании операции ожидания потоками активного процесса;

• при пробуждении GUI-потоков из-за операций с окнами;

• если поток, готовый к выполнению, задерживается из-за нехватки процессорного времени.

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

ПРИМЕЧАНИЕ Windows никогда не увеличивает приоритет потоков в диапазоне реального времени (16–31). Поэтому планирование таких потоков по отношению к другим всегда предсказуемо. Windows считает: тот, кто использует приоритеты реального времени, знает, что делает.

Динамическое повышение приоритета после завершения ввода-вывода

Windows временно повышает приоритет потоков по окончании определенных операций ввода-вывода, поэтому у потоков, ожидавших завершения таких операций, больше шансов немедленно возобновить выполнение и обработать полученные данные. Вспомните: после пробуждения потока оставшийся у него квант уменьшается на одну единицу, так что потоки, ожидавшие завершения ввода-вывода, не получают неоправданных преимуществ. Хотя рекомендованные приращения в результате динамического повышения приоритета определены в заголовочных файлах DDK (ищите строки «#define IO» в Wdm.h или Ntddk.h; эти же значения перечислены в таблице 6-17), реальное приращение определяется драйвером устройства. Именно драйвер устройства указывает — через функцию ядра IoCompleteRequest — на необходимость динамического повышения приоритета после выполнения запроса на ввод-вывод. Заметьте, что для запросов на ввод-вывод, адресованных устройствам, которые гарантируют меньшее время отклика, предусматриваются большие приращения приоритета.

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

Как уже отмечалось, динамическое повышение приоритета применяется только к потокам с приоритетом динамического диапазона (0-15). Независимо от приращения приоритет потока никогда не будет больше 15. Иначе говоря, если к потоку с приоритетом 14 применить динамическое повышение на 5 уровней, его приоритет возрастет лишь до 15. Если приоритет потока равен 15, он остается неизменным при любой попытке его повышения.

Динамическое повышение приоритета по окончании ожидания событий и семафоров

Когда ожидание потока на событии исполнительной системы или объекте «семафор» успешно завершается (из-за вызова SetEvent, PulseEvent или ReleaseSemaphore), его приоритет повышается на 1 уровень (см. значения EVENT_INCREMENT и SEMAPHORE_INCREMENT в заголовочных файлах DDK). Причина повышения приоритета потоков, закончивших ожидание событий или семафоров, та же, что и для потоков, ожидавших окончания операций ввода-вывода: потокам, блокируемым на событиях, процессорное время требуется реже, чем остальным. Такая регулировка позволяет равномернее распределять процессорное время.

B данном случае действуют те же правила динамического повышения приоритета, что и при завершении операций ввода-вывода (см. предыдущий раздел).

K потокам, которые пробуждаются в результате установки события вызовом специальных функций NtSetEventBoostPriority (используется в Ntdll.dll для критических секций) и KeSetEventBoostPriority (используется для ресурсов исполнительной системы и блокировок с заталкиванием указателя) повышение приоритета применяется особым образом. Если поток с приоритетом 13 или ниже, ждущий на событии, пробуждается в результате вызова специальной функции, его приоритет повышается до приоритета потока, установившего событие, плюс 1. Если длительность его кванта меньше 4 единиц, она приравнивается 4 единицам. Исходный приоритет восстанавливается по истечении этого кванта.

Динамическое повышение приоритета потоков активного процесса после выхода из состояния ожидания

Всякий раз, когда поток в активном процессе завершает ожидание на объекте ядра, функция ядра KiUnwaitThread динамически повышает его текущий (не базовый) приоритет на величину текущего значения PsPrioritySeparation. (Какой процесс является активным, определяет подсистема управления окнами.) Как было сказано в разделе «Управление величиной кванта» ранее в этой главе, PsPrioritySeparation представляет собой индекс в таблице квантов (байтовом массиве), с помощью которой выбираются величины квантов для потоков активных процессов. Однако в данном случае PsPrioritySeparation используется как значение, на которое повышается приоритет.

Это увеличивает отзывчивость интерактивного приложения по окончании ожидания. B результате повышаются шансы на немедленное возобновление его потока — особенно если в фоновом режиме выполняется несколько процессов с тем же базовым приоритетом.

B отличие от других видов динамического повышения приоритета этот поддерживается всеми системами Windows, и его нельзя отключить даже через Windows-функцию SetThreadPriorityBoost.

ЭКСПЕРИМЕНТ: наблюдение за динамическим изменением приоритета потока активного процесса

Увидеть механизм повышения приоритета в действии позволяет утилита CPU Stress (входит в состав ресурсов и Platform SDK).

1. B окне Control Panel (Панель управления) откройте апплет System (Система) или щелкните правой кнопкой мыши значок My Computer (Мой компьютер), выберите команду Properties (Свойства) и перейдите на вкладку Advanced (Дополнительно). Если вы используете Windows 2000, щелкните кнопку Performance Options (Параметры быстродействия) и выберите переключатель Applications (Приложений). B случае Windows XP или Windows Server 2003 щелкните кнопку Options (Параметры) в разделе Performance (Быстродействие), откройте вкладку Advanced (Дополнительно) и выберите переключатель Programs (Программ). B итоге PsPrioritySeparation получит значение 2.

2. Запустите Cpustres.exe.

3. Запустите Windows NT 4 Performance Monitor (Perfmon4.exe на компакт-диске ресурсов Windows 2000). Для эксперимента нужна имен-

но эта устаревшая версия, поскольку она способна запрашивать значения счетчиков производительности с более высокой частотой, чем оснастка Performance (Производительность), которая запрашивает такие значения не чаще, чем раз в секунду.

4. Щелкните на панели инструментов кнопку Add Counter (или нажмите клавиши Ctrl+I), чтобы открыть диалоговое окно Add To Chart.

5. Выберите объект Thread и счетчик Priority Current.

6. Пролистайте список Instance и найдите процесс Cpustres. Выберите второй поток под номером 1, так как первый (под номером 0) является потоком GUI.

7. Щелкните кнопку Add, затем — кнопку Done.

8. Из меню Options выберите команду Chart. Установите максимум по вертикальной шкале на 16, а в поле Interval введите 0.010 и щелкните кнопку ОК.

9. Теперь активизируйте процесс Cpustres. B результате приоритет потока Cpustres должен повыситься на 2 уровня, а потом снизиться до базового, как показано на следующей иллюстрации.

10. Причиной наблюдаемого повышения приоритета Cpustres на 2 уровня является пробуждение его потока, который спит около 75 % времени. Чтобы повысить частоту динамического повышения приоритета потока, увеличьте значение Activity с Low до Medium, затем до Busy. Если вы поднимете Activity до Maximum, то не увидите никакого повышения приоритета, поскольку при этом поток входит в бесконечный цикл и не вызывает никаких функций ожидания. A значит, его приоритет будет оставаться неизменным.

11. Закончив эксперимент, закройте Performance Monitor и CPU Stress.

Динамическое повышение приоритета после пробуждения GUI-потоков

Приоритет потоков, владеющих окнами, дополнительно повышается на 2 уровня после их пробуждения из-за активности подсистемы управления окнами, например при получении оконных сообщений. Подсистема управления окнами (Win32k.sys) повышает приоритет, вызывая KeSetEvent для установки события, пробуждающего GUI-поток. Приоритет повышается по той же причине, что и в предыдущем случае, — для создания преимуществ интерактивным приложениям.

ЭКСПЕРИМЕНТ: наблюдаем динамическое повышение приоритета GUI-потоков

Чтобы увидеть, как подсистема управления окнами повышает на 2 уровня приоритет GUI-потоков, пробуждаемых для обработки оконных сообщений, понаблюдайте за текущим приоритетом GUI-приложения, перемещая мышь в пределах его окна. Для этого сделайте вот что. 1. B окне Control Panel (Панель управления) откройте апплет System (Система) или щелкните правой кнопкой мыши значок My Computer (Мой компьютер), выберите команду Properties (Свойства) и перейдите на вкладку Advanced (Дополнительно). Если вы используете Windows 2000, щелкните кнопку Performance Options (Параметры быстродействия) и выберите переключатель Applications (Приложений). B случае Windows XP или Windows Server 2003 щелкните кнопку Options (Параметры) в разделе Performance (Быстродействие), откройте вкладку Advanced (Дополнительно) и выберите переключатель Programs (Программы). B итоге PsPrioritySepara-tion получит значение 2.

2. Запустите Notepad, выбрав из меню Start (Пуск) команды Programs (Программы), Accessories (Стандартные) и Notepad (Блокнот).

3. Запустите Windows NT 4 Performance Monitor (Perfmon4.exe на компакт-диске ресурсов Windows 2000). Для эксперимента нужна именно эта устаревшая версия, поскольку она способна запрашивать значения счетчиков производительности с более высокой частотой, чем оснастка Performance (Производительность), которая запрашивает такие значения не чаще, чем раз в секунду.

4. Щелкните на панели инструментов кнопку Add Counter (или нажмите клавиши Ctrl+I), чтобы открыть диалоговое окно Add To Chart.

5. Выберите объект Thread и счетчик Priority Current.

6. Пролистайте список Instance и найдите процесс Notepad. Выберите поток 0, щелкните кнопку Add, а затем — кнопку Done.

7. Как и в предыдущем эксперименте, выберите из меню Options команду Chart. Установите максимум по вертикальной шкале на 16, а в поле Interval введите 0.010 и щелкните кнопку ОК.

8. B итоге вы должны увидеть, как колеблется приоритет нулевого потока Notepad (от 8 до 10). Поскольку Notepad — вскоре после повышения его приоритета (как потока активного процесса) на 2 уровня — перешел в состояние ожидания, его приоритет мог не успеть снизиться с 10 до 9 или до 8.

9. Активизировав окно Performance Monitor, подвигайте курсор мыши в окне Notepad (но сначала расположите эти окна на рабочем столе так, чтобы они оба были видны). Вы заметите, что в силу описанных выше причин приоритет иногда остается равным 10 или 9, и скорее всего вы вообще не увидите приоритет 8, так как он будет на этом уровне в течение очень короткого времени.

10. Теперь сделайте активным окно Notepad. При этом вы должны заметить, что его приоритет повышается до 12 и остается на этом уровне (или снижается до 11, поскольку приоритет потока по окончании его кванта уменьшается на 1). Почему приоритет потока Notepad достигает такого значения? Дело в том, что приоритет потока повышается на 2 уровня дважды: первый раз — когда GUI-поток пробуждается из-за активности подсистемы управления окнами, и второй — когда он становится потоком активного процесса.

11. Если после этого вы снова подвигаете курсор мыши в окне Notepad (пока оно активно), то, возможно, заметите падение приоритета до 11 (или даже до 10) из-за динамического снижения приоритета потока по истечении кванта. Ho приоритет этого потока все равно превышает базовый на 2 уровня, так как процесс Notepad остается активным до тех пор, пока активно его окно.

12. Закончив эксперимент, закройте Performance Monitor и Notepad.

Динамическое повышение приоритета при нехватке процессорного времени

Представьте себе такую ситуацию: поток с приоритетом 7 постоянно вытесняет поток с приоритетом 4, не давая ему возможности получить процессорное время; при этом поток с приоритетом 11 ожидает какой-то ресурс, заблокированный потоком с приоритетом 4. Ho, поскольку поток с приоритетом 7 занимает все процессорное время, поток с приоритетом 4 никогда не получит процессорное время, достаточное для завершения и освобождения ресурсов, нужных потоку с приоритетом 11. Что же делает Windows в подобной ситуации? Раз в секунду диспетчер настройки баланса (balance set manager), системный поток, предназначенный главным образом для выполнения функций управления памятью (см. главу 7), сканирует очереди готовых потоков и ищет потоки, которые находятся в состоянии Ready в течение примерно 4 секунд. Обнаружив такой поток, диспетчер настройки баланса повышает его приоритет до 15. B Windows 2000 и Windows XP квант потока удваивается относительно кванта процесса. B Windows Server 2003 квант устанавливается равным 4 единицам. Как только квант истекает, приоритет потока немедленно снижается до исходного уровня. Если этот поток не успел закончить свою работу и если другой поток с более высоким приоритетом готов к выполнению, то после снижения приоритета он возвращается в очередь готовых потоков. B итоге через 4 секунды его приоритет может быть снова повышен.

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

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

ЭКСПЕРИМЕНТ: динамическое повышение приоритетов при нехватке процессорного времени

Утилита CPU Stress (она входит в состав ресурсов и Platform SDK) позволяет наблюдать, как работает механизм динамического повышения приоритетов. B этом эксперименте мы увидим, как изменяется интенсивность использования процессора при повышении приоритета потока. Для этого проделайте следующие операции. 1. Запустите Cpustres.exe. Измените значение в списке Activity для активного потока (по умолчанию — Thread 1) с Low на Maximum. Далее смените приоритет потока с Normal на Below Normal. При этом окно утилиты должно выглядеть так:

2. Запустите Windows NT 4 Performance Monitor (Perfmon4.exe на компакт-диске ресурсов Windows 2000). Нам снова понадобится эта устаревшая версия, поскольку она запрашивает значения счетчиков чаще, чем раз в секунду.

3. Щелкните на панели инструментов кнопку Add Counter (или нажмите клавиши Ctrl+I), чтобы открыть диалоговое окно Add To Chart.

4. Выберите объект Thread и счетчик % Processor Time.

5. Пролистайте список Instance и найдите процесс Cpustres. Выберите второй поток под номером 1, так как первый (под номером 0) является потоком GUI.

6. Щелкните кнопку Add, затем — кнопку Done.

7. Увеличьте приоритет Performance Monitor до уровня реального времени. Для этого запустите Task Manager (Диспетчер задач) и выберите процесс Perfmon4.exe на вкладке Processes (Процессы). Щелкните имя процесса правой кнопкой мыши, выберите Set Priority (Приоритет) и укажите Realtime (Реального времени). При этом вы получите предупреждение о возможности нестабильной работы системы — щелкните кнопку Yes (Да).

8. Запустите еще один экземпляр CPU Stress. Измените в нем параметр Activity для Thread 1 с Low на Maximum.

9. Теперь переключитесь обратно в Performance Monitor. Вы должны наблюдать всплески активности процессора примерно каждые 4 секунды, так как приоритет потока возрос до 15.

Закончив эксперимент, закройте Performance Monitor и все экземпляры CPU Stress.

ЭКСПЕРИМЕНТ: «прослушивание» динамического повышения приоритета

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

1. Запустите Windows Media Player (или другую программу для воспроизведения музыки) и откройте какой-нибудь музыкальный файл.

2. Запустите Cpustres из ресурсов Windows 2000 и задайте для потока 1 максимальный уровень активности.

3. Повысьте приоритет потока 1 с Normal до Time Critical.

4. Воспроизведение музыки должно остановиться, так как вычисления, выполняемые потоком, расходуют все процессорное время.

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

6. Закройте Cpustres и Windows Media Player.

Многопроцессорные системы

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

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

База данных диспетчера ядра в многопроцессорной системе

Как уже говорилось в разделе «База данных диспетчера ядра» ранее в этой главе, в такой базе данных хранится информация, поддерживаемая ядром и необходимая для планирования потоков. B многопроцессорных системах Windows 2000 и Windows XP (рис. 6-15) очереди готовых потоков и сводка готовых потоков имеют ту же структуру, что и в однопроцессорных системах. Кроме того, Windows поддерживает две битовые маски для отслеживания состояния процессоров в системе. (Как используются эти маски, см. в разделе «Алгоритмы планирования потоков в многопроцессорных системах» далее в этой главе.) Вот что представляют собой эти маски.

• Маска активных процессоров (KeActiveProcessors), в которой устанавливаются биты для каждого используемого в системе процессора. (Их может быть меньше числа установленных процессоров, если лицензионные ограничения данной версии Windows не позволяют задействовать все физические процессоры.)

• Сводка простоя (idle summary) (KiIdleSummary), в которой каждый установленный бит представляет простаивающий процессор. Если в однопроцессорной системе диспетчерская база данных блокируется повышением IRQL (в Windows 2000 и Windows XP до уровня «DPC/ dispatch», а в Windows Server 2003 до уровней «DPC/dispatch» и «Synch»), то в многопроцессорной системе требуется большее, потому что каждый процессор одновременно может повысить IRQL и попытаться манипулировать этой базой данных. (Кстати, это относится к любой общесистемной структуре, доступной при высоких IRQL. Общее описание синхронизации режима ядра и спин-блокировок см. в главе 3.) B Windows 2000 и Windows XP для синхронизации доступа к информации о диспетчеризации потока применяется две спин-блокировки режима ядра: спин-блокировка диспетчера ядра (dispatcher spinlock) (KiDispatcherLock) и спин-блокировка обмена контекста (context swap spinlock) (KiContextSwapLocM). Первая удерживается, пока вносятся изменения в структуры, способные повлиять на то, как должен выполняться поток, а вторая захватывается после принятия решения, но в ходе самой операции обмена контекста потока.

Для большей масштабируемости и улучшения поддержки параллельной диспетчеризации потоков в многопроцессорных системах Windows Server 2003 очереди готовых потоков диспетчера создаются для каждого процессора, как показано на рис. 6-23. Благодаря этому в Windows Server 2003 каждый процессор может проверять свои очереди готовых потоков, не блокируя аналогичные общесистемные очереди.

Очереди готовых потоков и сводки готовности, индивидуальные для каждого процессора, являются частью структуры PRCB (processor control block). (Чтобы увидеть поля этой структуры, введите dt nt!_prcb в отладчике ядра.) Поскольку в многопроцессорной системе одному из процессоров может понадобиться изменить структуры данных, связанные с планированием, для другого процессора (например, вставить поток, предпочитающий работать на определенном процессоре), доступ к этим структурам синхронизируется с применением новой спин-блокировки с очередями, индивидуальной для каждой PRCB; она захватывается при IRQL SYNCH_LEVEL. (Возможные значения SYNCH_LEVEL см. в таблице 6-18.) Таким образом, поток может быть выбран при блокировке PRCB лишь какого-то одного процессора — в отличие от Windows 2000 и Windows XP, где с этой целью нужно захватить общесистемную спин-блокировку диспетчера ядра.

Для каждого процессора создается и список потоков в готовом, но отложенном состоянии (deferred ready state). Это потоки, готовые к выполнению, но операция, уведомляющая в результате об их готовности, отложена до более подходящего времени. Поскольку каждый процессор манипулирует только своим списком отложенных готовых потоков, доступ к этому списку не синхронизируется по спин-блокировке PRCB. Список отложенных готовых потоков обрабатывается до выхода из диспетчера потоков, до переключения контекста и после обработки DPC Потоки в этом списке либо немедленно диспетчеризуются, либо перемещаются в одну из индивидуальных для каждого процессора очередей готовых потоков (в зависимости от приоритета).

Заметьте, что общесистемная спин-блокировка диспетчера ядра по-прежнему существует и используется в Windows Server 2003, но она захватывается лишь на период, необходимый для модификации общесистемного состояния, которое может повлиять на то, какой поток будет выполняться следующим. Например, изменения в синхронизирующих объектах (мьютексах, событиях и семафорах) и их очередях ожидания требуют захвата блокировки диспетчера ядра, чтобы предотвратить попытки модификации таких объектов (и последующей операции перевода потоков в состояние готовности к выполнению) более чем одним процессором. Другие примеры — изменение приоритета потока, срабатывание таймера и обмен содержимого стеков ядра для потоков.

Наконец, в Windows Server 2003 улучшена сихронизация переключения контекста потоков, так как теперь оно синхронизируется с применением спин-блокировки, индивидуальной для каждого потока, а в Windows 2000 и Windows XP переключение контекста синхронизировалось захватом общесистемной спин-блокировки обмена контекста.

Системы с поддержкой Hyperthreading

Как уже говорилось в разделе «Симметричная многопроцессорная обработка» главы 2, Windows XP и Windows Server 2003 поддерживают многопроцессорные системы, использующие технологию Hyperthreading (аппаратная реализация логических процессоров на одном физическом).

1. Логические процессоры не подпадают под лицензионные ограничения на число физических процессоров. Так, Windows XP Home Edition, которая по условиям лицензии может использовать только один процессор, задействует оба логических процессора в однопроцессорной системе с поддержкой Hyperthreading.

2. Если все логические процессоры какого-либо физического процессора простаивают, для выполнения потока выбирается один из логических процессоров этого физического процессора, а не того, у которого один из логических процессоров уже выполняет другой поток.

ЭКСПЕРИМЕНТ: просмотр информации, связанной с Hyperthreading

Изучить такую информацию позволяет команда !smt отладчика ядра. Следующий вывод получен в системе с двумя процессорами Xeon с технологией Hyperthreading (четыре логических процессора):

Логические процессоры 0 и 1 находятся на разных физических процессорах (на что указывает ключевое слово «Master»).

Системы NUMA

Другой тип многопроцессорных систем, поддерживаемый Windows XP и Windows Server 2003, — архитектуры памяти с неунифицированным доступом (nonuniform memory access, NUMA). B NUMA-системе процессоры группируются в узлы. B каждом узле имеются свои процессоры и память, и он подключается к системе соединительной шиной с когерентным кэшем (cache-coherent interconnect bus). Доступ к памяти в таких системах называется неунифицированным потому, что у каждого узла есть локальная высокоскоростная память. Хотя любой процессор в любом узле может обращаться ко всей памяти, доступ к локальной для узла памяти происходит гораздо быстрее.

Ядро поддерживает информацию о каждом узле в NUMA-системе в структурах данных KNODE. Переменная ядра KeNodeBlock содержит массив указателей на структуры KNODE для каждого узла. Формат структуры KNODE можно просмотреть командой dt отладчика ядра:

ЭКСПЕРИМЕНТ: просмотр информации, относящейся к NUMA

Вы можете исследовать информацию, поддерживаемую Windows для каждого узла в NUMA-системе, с помощью команды !numa отладчика ядра. Ниже приведен фрагмент вывода, полученный в 32-процессорной NUMA-системе производства NEC с 4 процессорами в каждом узле:

21: kd›!numa NUMA Summary:

—

Number of NUMA nodes: 8 Number of Processors: 32

A это фрагмент вывода, полученный в 64-процессорной NUMA-системе производства Hewlett Packard с 4 процессорами в каждом узле:

Приложения, которым нужно выжать максимум производительности из NUMA-систем, могут устанавливать маски привязки процесса к процессорам в определенном узле. Получить эту информацию позволяют функции, перечисленные в таблице 6-19. (Функции, с помощью которых можно изменять привязку потоков к процессорам, были перечислены в таблице 6-14.)

O том, как алгоритмы планирования учитывают особенности NUMA-систем, см. в разделе «Алгоритмы планирования потоков в многопроцессорных системах» далее в этой главе (а об оптимизациях в диспетчере памяти для использования преимуществ локальной для узла памяти см. в главе 7).

Привязка к процессорам

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

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

• Вызовом функции SetThreadAffintiyMask, чтобы задать маску привязки к процессорам для индивидуального потока;

• Вызовом функции SetProcessAffinityMask, чтобы задать маску привязки к процессорам для всех потоков в процессе. Диспетчер задач и Process Explorer предоставляют GUI-интерфейс к этой функции: щелкните процесс правой кнопкой мыши и выберите Set Affinity (Задать соответствие). Утилита Psexec (с сайта sysinternals.com) предоставляет к той же функции интерфейс командной строки (см. ключ — a).

• Включением процесса в задание, в котором действует глобальная для задания маска привязки к процессорам, установленная через функцию SetInformationJobObject (о заданиях см. раздел «Объекты-задания» далее в этой главе.)

• Определением маски привязки к процессорам в заголовке образа с помощью, например, утилиты Imagecfg из Windows 2000 Server Resource Kit Supplement 1. (O формате образов в Windows см. статью «Portable Executable and Common Object File Format Specification в MSDN Library.)

B образе можно установить и «однопроцессорный» флаг (используя в Imagecfg ключ — u). Если этот флаг установлен, система выбирает один процессор в момент создания процесса и закрепляет его за этим процессом; при этом процессоры меняются от первого и до последнего по принципу карусели. Например, в двухпроцессорной системе при первом запуске образа, помеченного как однопроцессорный, он закрепляется за процессором 0, при втором — за процессором 1, при третьем — за процессором 0, при четвертом — за процессором 1 и т. д. Этот флаг полезен, когда нужно временно обойти ошибку в программе, связанную с неправильной синхронизацией потоков, но проявляющуюся только в многопроцессорных системах.

ЭКСПЕРИМЕНТ: просмотр и изменение привязки процесса к процессорам

B этом эксперименте вы модифицируете привязку процесса к процессорам и убедитесь, что привязка наследуется новыми процессами.

1. Запустите окно командной строки (cmd.exe).

2. Запустите диспетчер задач или Process Explorer и найдите cmd.exe в списке процессов.

3. Щелкните этот процесс правой кнопкой мыши и выберите команду Set Affinity (Задать соответствие). Должен появиться список процессоров. Например, в двухпроцессорной системе вы увидите окно, как на следующей иллюстрации.

4. Выберите подмножество доступных процессоров в системе и нажмите ОК. Теперь потоки процесса будут работать только на выбранных вами процессорах.

5. Запустите Notepad.exe из окна командной строки (набрав notepad.exe).

6. Вернитесь в диспетчер задач или Process Explorer и найдите новый процесс Notepad. Щелкните его правой кнопкой мыши и выберите Set Affinity. Вы должны увидеть список процессоров, выбранных вами для процесса cmd.exe. Это вызвано тем, что процессы наследуют привязки к процессорам от своего родителя.

ЭКСПЕРИМЕНТ: изменение маски привязки образа

B этом эксперименте (который потребует доступа к многопроцессорной системе) вы измените маску привязки к процессорам для какой-нибудь программы, чтобы заставить ее работать на первом процессоре.

1. Создайте копию Cpustres.exe (эта утилита содержится в ресурсах Windows 2000). Например, если у вас есть каталог c: \temp, то в командной строке введите:

сору c: \program files\resource kit\cpustres.exe c: \temp\cpustres.exe

2. Задайте маску привязки так, чтобы она заставляла потоки процесса выполняться на процессоре 0. Для этого в командной строке (предполагается, что путь к ресурсам прописан в переменной окружения PATH) введите:

imagecfg — а 1 c: \temp\cpustres.exe

3. Теперь запустите модифицированную Cpustres из каталога c.\temp.

4. Включите два рабочих потока и установите уровень активности обоих потоков в Maximum (не Busy). Окно Cpustres должно выглядеть следующим образом.

5. Найдите процесс Cpustres в Process Explorer или диспетчере задач, щелкните его правой кнопкой мыши и выберите Set Affinity. Вы должны увидеть, что процесс привязан к процессору 0.

6. Посмотрите общесистемное использование процессора, выбрав Show, System Information (в Process Explorer) или открыв вкладку Performance (в диспетчере задач). Если в системе нет других процессов, занятых интенсивными вычислениями, общая процентная доля использования процессорного времени должна составить примерно 1 /(число процессоров) (скажем, около 50 % в двухпроцессорной системе или около 25 % в четырехпроцессорной), потому что оба потока в Cpustres привязаны к одному процессору и остальные процессоры простаивают. 7. Наконец, измените маску привязки процесса Cpustres так, чтобы разрешить ему выполнение на всех процессорах. Снова проверьте общесистемное использование процессорного времени. Теперь оно должно быть 100 % в двухпроцессорной системе, 50 % в четырехпроцессорной и т. д.

Windows не перемещает уже выполняемый поток с одного процессора на второй, чтобы готовый поток с маской привязки именно к первому процессору немедленно начал на нем работать. Рассмотрим, например, такой сценарий: к процессору 0 подключен поток с приоритетом 8, который может работать на любом процессоре, а к процессору 1 — поток с приоритетом 4, который тоже может выполняться на любом процессоре. Ho вот готов поток с приоритетом 6, привязанный только к процессору 0. Что произойдет? Windows не станет переключать поток с приоритетом 8 на процессор 1 (вытесняя при этом поток с приоритетом 4), и поток с приоритетом 6 будет ждать освобождения процессора 0.

Следовательно, изменение маски привязки для процесса или потока может привести к тому, что потоки будут получать меньше процессорного времени, чем обычно, поскольку это ограничивает Windows в выборе процессоров для данного потока. A значит, задавать маску привязки нужно с крайней осторожностью — в большинстве ситуаций оптимальнее оставить выбор за самой Windows.

Идеальный и последний процессоры

B блоке потока ядра каждого потока хранятся номера двух особых процессоров:

• идеального (ideal processor) — предпочтительного для выполнения данного потока;

• последнего (last processor) — на котором поток работал в прошлый раз.

Идеальный процессор для потока выбирается случайным образом при его создании с использованием зародышевого значения (seed) в блоке процесса. Это значение увеличивается на 1 всякий раз, когда создается новый поток, поэтому создаваемые потоки равномерно распределяются по набору доступных процессоров. Например, первый поток в первом процессе в системе закрепляется за идеальным процессором 0, второй поток того же процесса — за идеальным процессором 1. Однако у следующего процесса в системе идеальный процессор для первого потока устанавливается в 1, для второго — в 2 и т. д. Благодаря этому потоки внутри каждого процесса равномерно распределяются между процессорами.

Заметьте: здесь предполагается, что потоки внутри процесса выполняют равные объемы работы. Ho в многопоточном процессе это обычно не так; в нем есть, как правило, один или более «служебных» потоков (housekeeping threads) и несколько рабочих. Поэтому, если в многопоточном приложении нужно задействовать все преимущества многопроцессорной платформы, целесообразно указывать номера идеальных процессоров для потоков вызовом функции SetTbreadIdealProcessor.

B системах с Hyperthreading следующим идеальным процессором является первый логический процессор на следующем физическом. Например, в двухпроцессорной системе с Hyperthreading логических процессоров — 4; если для первого потока идеальным процессором назначен логический процессор 0, то для второго потока имело бы смысл назначить таковым логический процессор 2, для третьего — логический процессор 1, для четвертого — логический процессор 3 и т. д. Тогда потоки равномерно распределялись бы по физическим процессорам.

B NUMA-системах идеальный узел для процесса выбирается при его (процесса) создании. Первому процессу назначается узел 0, второму — 1 и т. д. Затем идеальные процессоры для потоков процесса выбираются из идеального узла. Идеальным процессором для первого потока в процессе назначается первый процессор в узле. По мере создания дополнительных потоков в процессе за ними закрепляется тот же идеальный узел; следующий процессор в этом узле становится идеальным для следующего потока и т. д.

Алгоритмы планирования потоков в многопроцессорных системах

Теперь, описав типы многопроцессорных систем, поддерживаемых Windows, а также привязку потоков к процессорам и выбор идеального процессора, мы готовы объяснить вам применение этой информации при определении того, какие потоки выполняются и на каких процессорах. При этом система принимает два базовых решения:

• выбор процессора для потока, который готов к выполнению;

• выбор потока для конкретного процессора.

Выбор процессора для потока при наличии простаивающих процессоров

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

B Windows XP и Windows Server 2003 выбор простаивающего процессора не так прост. Во-первых, выделяются простаивающие процессоры из числа тех, на которых маска привязки разрешает выполнение данного потока. Если система имеет архитектуру NUMA и в узле, где находится идеальный процессор для потока, есть простаивающие процессоры, то список всех простаивающих процессоров уменьшается до этого набора. Если в результате такой операции в списке не останется простаивающих процессоров, список не сокращается. Затем, если в системе работают процессоры с технологией Hyperthreading и имеется физический процессор, все логические процессоры которого свободны, список простаивающих процессоров уменьшается до этого набора. И вновь, если в результате такой операции в списке не останется простаивающих процессоров, список не сокращается.

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

Из оставшегося набора простаивающих процессоров исключаются все процессоры, находящиеся в состоянии сна. (Эта операция не выполняется, если в ее результате такой список опустел бы.) Наконец, поток подключается к процессору с наименьшим номером в оставшемся списке.

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

Выбор процессора для потока в отсутствие простаивающих процессоров

Если простаивающих процессоров нет в момент, когда готовый к выполнению поток переведен в состояние Standby, Windows проверяет приоритет выполняемого потока (или того, который находится в состоянии Standby) и идеальный процессор для него, чтобы решить, следует ли вытеснить выполняемый. B Windows 2000 маска привязки может исключить идеальный процессор. (B Windows XP такое не допускается.) Если этот процессор не входит в маску привязки потока, Windows выбирает для потока процессор с наибольшим номером.

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

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

Как мы уже сказали, если готовый поток нельзя выполнить немедленно, он помещается в очередь готовых потоков и ждет выделения процессорного времени. Однако в Windows Server 2003 потоки всегда помещаются в очереди готовых потоков на своих идеальных процессорах.

Выбор потока для выполнения на конкретном процессоре (Windows 2000 и Windows XP)

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

• поток уже выполнялся в прошлый раз на данном процессоре; • данный процессор должен быть идеальным для этого потока; • поток провел в состоянии Ready более трех тактов системного таймера;

• поток имеет приоритет не менее 24.

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

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

Выбор потока для выполнения на конкретном процессоре (Windows Server 2003)

Поскольку в Windows Server 2003 у каждого процессора собственный список потоков, ждущих выполнения на этом процессоре, то по окончании выполнения текущего потока процессор просто проверяет свою очередь готовых потоков. Если его очереди пусты, к процессору подключается поток простоя. Затем этот поток начинает сканировать очереди готовых потоков при других процессорах и ищет потоки, которые можно было бы выполнять на данном процессоре. Заметьте, что в NUMA-системах поток простоя проверяет процессоры сначала в своем узле, а потом в других узлах.

Объекты-задания

Объект «задание» (job object) — это именуемый, защищаемый и разделяемый объект ядра, обеспечивающий управление одним или несколькими процессами как группой. Процесс может входить только в одно задание. По умолчанию его связь с объектом «задание» нельзя разрушить, и все процессы, создаваемые данным процессом и его потомками, будут сопоставлены с тем же заданием. Объект «задание» также регистрирует базовую учетную информацию всех включенных в него процессов, в том числе уже завершившихся. Windows-функции, предназначенные для создания объектов-заданий и манипулирования ими, перечислены в таблице 6-20.

Ниже кратко поясняются некоторые ограничения, которые можно налагать на задания.

• Максимальное число активных процессов Ограничивает число одновременно выполняемых процессов задания.

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

• Индивидуальный лимит на процессорное время пользовательского режима для каждого процесса Ограничивает максимальное количество процессорного времени, потребляемого каждым процессом в задании. По достижении этого лимита процесс завершается (не получая шанса на очистку).

• Класс планирования задания Устанавливает длительность кванта для потоков процессов, входящих в задание. Этот параметр применим только в системах, использующих длинные фиксированные кванты (в системах Windows Server по умолчанию). Длительность кванта определяется классом планирования задания, как показано в следующей таблице.

• Привязка задания к процессорам Устанавливает маску привязки к процессорам для каждого процесса задания. (Отдельные потоки могут изменять свои привязки на любое подмножество привязок задания, но процессы этого делать не могут.)

• Класс приоритета для всех процессов задания Определяет класс приоритета для каждого процесса в задании. Потоки не могут повышать свой приоритет относительно класса (как они это обычно делают). Все попытки повышения приоритета игнорируются. (При вызове SetTbreadPriority ошибка не генерируется, но и приоритет не повышается.)

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

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

Задания можно настроить на отправку в очередь объекта «порт завершения ввода-вывода» какого-либо элемента, который могут ждать другие потоки через Windows-функцию GetQueuedCompletionStatus.

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

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

B Windows 2000 Datacenter Server имеется утилита Process Control Manager, позволяющая администратору определять объекты «задание», устанавливать для них различные квоты и лимиты, а также указывать процессы, которые следует включать в то или иное задание при запуске. Заметьте, что эта утилита больше не поставляется с Windows Server 2003 Datacenter Edition, но останется в системе при обновлении Windows 2000 Datacenter Server до Windows Server 2003 Datacenter Edition.

ЭКСПЕРИМЕНТ: просмотр объекта «задание»

Вы можете просматривать именованные объекты «задание» в оснастке Performance (Производительность). Для просмотра неименованных заданий нужно использовать команду !job или dt nt!_ejob отладчика ядра.

Выяснить, сопоставлен ли данный процесс с заданием, позволяет команда !process отладчика ядра или — в Windows XP и Windows Server 2003 — утилита Process Explorer. Чтобы создать неименованный объект «задание» и понаблюдать за ним, придерживайтесь следующей схемы.

1. Введите команду runas для создания процесса командной строки (Cmd.exe). Например, наберите runas /user:‹домен›\‹имя_пользователя›cmd. Далее введите свой пароль, и на экране появится окно командной строки. Windows-сервис, выполняющий команду runas, создаст неименованное задание, включающее все процессы (они будут завершены в момент вашего выхода из системы).

2. Из командной строки запустите Notepad.exe.

3. Запустите Process Explorer и обратите внимание на то, что процессы Cmd.exe и Notepad.exe выделяются как часть задания. Эти два процесса показаны на следующей иллюстрации.

4. Дважды щелкните либо процесс Cmd.exe, либо процесс Notepad.exe, чтобы открыть окно свойств. B этом окне вы увидите вкладку Jоb.

5. Перейдите на вкладку Jоb для просмотра детальных сведений о задании. B нашем случае с заданием не сопоставлены никакие квоты — в него просто включены два процесса.

6. Теперь запустите отладчик ядра в работающей системе (либо Win-Dbg в режиме локальной отладки ядра, либо LiveKd, если вы используете Windows 2000), выведите на экран список процессов командой !process и найдите в нем только что созданный процесс Cmd.exe. Затем просмотрите содержимое блока процесса, введя команду !process ‹идеитификатор_процесса›, и найдите адрес объекта «задание». Наконец, исследуйте объект «задание» с помощью команды !job. Ниже приведен фрагмент вывода отладчика для этих команд в работающей системе:

7. Наконец, используйте команду dt для просмотра объекта-задания и обратите внимание на дополнительные поля:

Резюме

Мы изучили структуру процессов, потоков и заданий, узнали, как они создаются, а также познакомились с алгоритмами распределения процессорного времени в Windows.

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

Как и большинство современных операционных систем, Windows поддерживает механизм разделения памяти. Разделяемой (shared memory) называется память, видимая более чем одному процессу или присутствующая в виртуальном адресном пространстве более чем одного процесса. Например, если два процесса используют одну и ту же DLL, есть смысл загрузить ее код в физическую память лишь один раз и сделать ее доступной всем процессам, проецирующим эту DLL (рис. 7–1).

Каждый процесс поддерживает закрытые области памяти для хранения собственных данных, но программные инструкции и страницы немодифицируемых данных в принципе можно использовать совместно с другими процессами. Как вы еще увидите, такой вид разделения реализуется автоматически, поскольку страницы кода в исполняемых образах проецируются с атрибутом «только для выполнения», а страницы, доступные для записи, — с атрибутом «копирование при записи» (copy-on-write) (см. раздел «Копирование при записи» далее в этой главе).

Для реализации разделяемой памяти используются примитивы диспетчера памяти, объекты «раздел», которые в Windows API называются объектами «проекция файла» (file mapping objects). Внутренняя структура и реализация этих объектов описывается в разделе «Объекты-разделы» далее в этой главе.

Этот фундаментальный примитив диспетчера памяти применяется для проецирования виртуальных адресов в основной памяти, страничном файле или любых других файлах, к которым приложение хочет обращаться так, будто они находятся в памяти. Раздел может быть открыт как одним процессом, так и несколькими; иначе говоря, объекты «раздел» вовсе не обязательно представляют разделяемую память.

Объект «раздел» может быть связан с открытым файлом на диске (который в этом случае называется проецируемым) или с переданной памятью (для ее разделения). Разделы, проецируемые на переданную память, называются разделами, поддерживаемыми страничными файлами (page file backed sections), так как при нехватке памяти их страницы перемещаются в страничный файл. (Однако Windows может работать без страничного файла, и тогда эти разделы «поддерживаются» физической памятью.) Разделяемые переданные страницы, как и любые другие страницы, видимые в пользовательском режиме (например, закрытые переданные страницы), всегда обнуляются при первом обращении к ним.

Для создания объекта «раздел» используется Windows-функция Create-FileMapping, которой передается описатель проецируемого файла (или INVALID_HANDLE_VALUE в случае раздела, поддерживаемого страничным файлом), а также необязательные имя и дескриптор защиты. Если разделу присвоено имя, его может открыть другой процесс вызовом OpenFileMapping. Кроме того, вы можете предоставить доступ к объектам «раздел» через наследование описателей (определив при открытии или создании описателя, что он является наследуемым) или их дублирование (с помощью Duplicate-Handle). Драйверы также могут манипулировать объектами «раздел» через функции ZwOpenSection, ZwMapViewOfSection и ZwUnmapViewOfSection.

Объект «раздел» может ссылаться на файлы, длина которых намного превышает размер адресного пространства процесса. (Если раздел поддерживается страничным файлом, в нем должно быть достаточно места для размещения всего раздела.) Используя очень большой объект «раздел», процесс может проецировать лишь необходимую ему часть этого объекта, которая называется представлением (view) и создается вызовом функции MapViewOfFiIe с указанием проецируемого диапазона. Это позволяет процессам экономить адресное пространство, так как на память проецируется только представление объекта «раздел».

Windows-приложения могут использовать проецирование файлов для упрощения ввода-вывода в файлы на диске, просто делая их доступными в своем адресном пространстве. Приложения — не единственные потребители объектов «раздел»: загрузчик образов использует их для проецирования в память исполняемых образов, DLL и драйверов устройств, а диспетчер кэша — для доступа к данным кэшируемых файлов. (Об интеграции диспетчера кэша с диспетчером памяти см. в главе 11.) O реализации разделов совместно используемой памяти мы расскажем потом.

ЭКСПЕРИМЕНТ: просмотр файлов, проецируемых в память

Просмотреть спроецированные в память файлы для какого-либо процесса позволяет утилита Process Explorer от Sysinternals. Для этого настройте нижнюю секцию ее окна на режим отображения DLL. (Выберите View, Lower Pane View, DLLs.) Заметьте, что это не просто список DLL, — здесь представлены все спроецированные в память файлы в адресном пространстве процесса. Некоторые являются DLL, один из них — файлом выполняемого образа (EXE), а другие элементы списка могут представлять файлы данных, проецируемые в память. Например, на следующей иллюстрации показан вывод Process Explorer применительно к процессу Microsoft PowerPoint, в адресное пространство которого загружен документ PowerPoint.

Для поиска спроецированных в память файлов щелкните Find, DLL. Это удобно, когда нужно определить, какие процессы используют DLL, которую вы пытаетесь заменить.

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

Защита памяти

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

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

ПРИМЕЧАНИЕ Некоторые страницы в системном адресном пространстве Windows 95/98 и Windows Millennium Edition, напротив, доступны для записи из пользовательского режима, что позволяет сбойным приложениям портить важные системные структуры данных и вызывать крах системы.

Во-вторых, у каждого процесса имеется индивидуальное закрытое адресное пространство, защищенное от доступа потоков других процессов. Исключение составляют те случаи, когда процесс разделяет какие-либо страницы с другими процессами или когда у другого процесса есть права на доступ к объекту «процесс» для чтения и/или записи, что позволяет ему использовать функции ReadProcessMemory и WriteProcessMemory. Как только поток ссылается на какой-нибудь адрес, аппаратные средства поддержки виртуальной памяти совместно с диспетчером памяти перехватывают это обращение и транслируют виртуальный адрес в физический. Контролируя трансляцию виртуальных адресов, Windows гарантирует, что потоки одного процесса не получат несанкционированного доступа к страницам другого процесса.

В-третьих, кроме косвенной защиты, обеспечиваемой трансляцией виртуальных адресов в физические, все процессоры, поддерживаемые Windows, предоставляют ту или иную форму аппаратной защиты памяти (например доступ для чтения и записи, только для чтения и т. д.); конкретные механизмы такой защиты зависят от архитектуры процессора. Скажем, страницы кода в адресном пространстве процесса помечаются атрибутом «только для чтения», что защищает их от изменения пользовательскими потоками.

Атрибуты защиты памяти, определенные в Windows API, перечислены в таблице 7–3 (см. также документацию на функции VirtualProtect, VirtualProtectEx, VirtualOuery и VirtualQuervEx}.

ПРИМЕЧАНИЕ Атрибут защиты «запрет на выполнение» (no execute protection) поддерживается Windows XP Service Pack 2 и Windows Server 2003 Service Pack 1 на процессорах с соответствующей аппаратной поддержкой (например, на x64-, IA64- и будущих x86-npoueccopax). B более ранних версиях Windows и на процессорах без поддержки атрибута защиты «запрет на выполнение», выполнение всегда разрешено. Более подробные сведения об этом атрибуте защиты см. в следующем разделе.

Наконец, совместно используемые объекты «раздел» имеют стандартные для Windows списки контроля доступа (access control lists, ACL), проверяемые при попытках процессов открыть эти объекты. Таким образом, доступ к разделяемой памяти ограничен кругом процессов с соответствующими правами. Когда поток создает раздел для проецирования файла, в этом принимает участие и подсистема защиты. Для создания раздела поток должен иметь права хотя бы на чтение нижележащего объекта «файл», иначе операция закончится неудачно.

После успешного открытия описателя раздела действия потока все равно зависят от описанных выше атрибутов защиты, реализуемых диспетчером памяти на основе аппаратной поддержки. Поток может менять атрибуты защиты виртуальных страниц раздела (на уровне отдельных страниц), если это не противоречит разрешениям, указанным в ACL для данного раздела. Так, диспетчер памяти позволит потоку сменить атрибут страниц общего раздела «только для чтения» на «копирование при записи», но запретит его изменение на атрибут «для чтения и записи». Копирование при записи разрешается потому, что не влияет на другие процессы, тоже использующие эти данные.

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

Запрет на выполнение

Хотя в API управления памятью в Windows всегда были определены биты защиты страницы, позволяющие указывать, может ли страница содержать исполняемый код, лишь с появлением Windows XP Service Pack 2 и Windows Server 2003 Service Pack 1 эта функциональность стала поддерживаться на процессорах с аппаратной защитой «запрет на выполнение», в том числе на всех процессорах AMD64 (AMD Athlon64, AMD Opteron), на некоторых чисто 32-разрядных процессорах AMD (отдельных AMD Sempron), на Intel IA64 и Intel Pentium 4 или Xeon с поддержкой EM64T (Intel Extended Memory 64 Technology).

Эта защита, также называемая предотвращением выполнения данных (data execution prevention, DEP), означает, что попытка передачи управления какой-либо инструкции на странице, помеченной атрибутом «запрет на выполнение», приведет к нарушению доступа к памяти. Благодаря этому блокируются попытки определенных типов вирусов воспользоваться ошибками в операционной системе, которые иначе позволили бы выполнить код, размещенный на странице данных. Попытка выполнить код на странице, помеченной атрибутом «запрет на выполнение», в режиме ядра вызывает крах системы с кодом ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY. Если такая же попытка предпринимается в пользовательском режиме, то генерируется исключение STATUS_ACCESS_VIOLATION (0xc0000005); оно доставляется потоку, в котором была эта недопустимая ссылка. Если процесс выделяет память, которая должна быть исполняемой, то при вызове функций, отвечающих за выделение памяти, он обязан явно указать для соответствующих страниц флаг PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE или PAGE_EXECUTE_WRITECOPY.

B 64-разрядных версиях Windows атрибут защиты «запрет на выполнение» всегда применяется ко всем 64-разрядным программам и драйверам устройств, и его нельзя отключить. Поддержка такой защиты для 32-разрядных программ зависит от конфигурационных параметров системы. B 64-разрядной Windows защита от выполнения применяется к стекам потоков (как режима ядра, так и пользовательского режима), к страницам пользовательского режима, не помеченным явно как исполняемые, к пулу подкачиваемой памяти ядра и к сеансовому пулу ядра (описание пулов памяти ядра см. в разделе «Системные пулы памяти»). Однако в 32-разрядной Windows защита от выполнения применяется только к стекам потоков и страницам пользовательского режима. Кроме того, когда в 32-разрядной Windows разрешена защита от выполнения, система автоматически загружается в PAE-режиме (переходя на использование РАЕ-ядра, \Windows\System32\Ntkrnlpa.exe). Описание PAE см. в разделе «Physical Address Extension (PAE)».

Активизация защиты от выполнения для 32-разрядных программ зависит от ключа /NOEXECUTE= в Boot.ini. Эти настройки можно изменить и на вкладке Data Execution Prevention, которая открывается последовательным выбором My Computer, Properties, Advanced, Performance Settings (см. рис. 7–2.) Когда вы выбираете защиту от выполнения в диалоговом окне настройки DEP, файл Boot.ini модифицируется добавлением в него соответствующего ключа /NOEXECUTE. Список аргументов для этого ключа и их описание см. в таблице 7–4. 32-разрядные приложения, исключенные из защиты от выполнения, перечисляются в параметрах в разделе реестра HKLM\Software\Microsoft\Windows NT \CurrentVersion\AppCompatFlags\Layers; при этом в качестве имени параметра используется полный путь к исполняемому файлу, а в качестве его значения — «DisableNXShowUI».

Рис. 7–2. Параметры Data Execution Protection

B Windows XP (в 64- и 32-разрядных версиях) защита от выполнения для 32-разрядных программ по умолчанию применяется только к базовым исполняемым образам операционной системы Windows (/NOEXECUTE=OPTIN), чтобы не нарушить работу 32-разрядных приложений, которые могут полагаться на выполнение кода в страницах, не помеченных как исполняемые. B Windows Server 2003 такая защита по умолчанию распространяется на все 32-разрядные приложения (/NOEXECUTE=OPTOUT).

ПРИМЕЧАНИЕ Чтобы получить полный список защищаемых программ, установите Windows Application Compatibility Toolkit (его можно скачать с microsoft.com) и запустите CompatibilityAdministrator Tool. Выберите System Database, Applications и Windows Components. B правой секции окна появится список защищенных исполняемых файлов.

Программный вариант DEP

Поскольку большинство процессоров, на которых сегодня работает Windows, не поддерживает аппаратную защиту от выполнения, Windows XP Service Pack 2 и Windows Server 2003 Service Pack 1 (или выше) поддерживают ограниченный программный вариант DEP (data execution prevention). Одна из функций программного DEP — сужать возможности злоумышленников в использовании механизма обработки исключений в Windows. (Описание структурной обработки исключений см. в главе 3.) Если файлы образа программы опираются на безопасную структурную обработку исключений (новая функциональность компилятора Microsoft Visual C++ 2003), то, прежде чем передавать исключение, система проверяет, зарегистрирован ли обработчик этого исключения в таблице функций, которая помещается в файл образа. Если в файлах образа программы безопасная структурная обработка исключений не применяется, программный DEP проверяет, находится ли обработчик исключения в области памяти, помеченной как исполняемая, еще до передачи исключения.

Копирование при записи

Защита страницы типа «копирование при записи» — механизм оптимизации, используемый диспетчером памяти для экономии физической памяти. Когда процесс проецирует копируемое при записи представление объекта «раздел» со страницами, доступными для чтения и записи, диспетчер памяти — вместо того чтобы создавать закрытую копию этих страниц в момент проецирования представления (как в операционной системе Hewlett Packard OpenVMS) — откладывает создание копии до тех пор, пока не закончится запись в них. Эта методика используется и всеми современными UNIX-системами. Ha рис. 7–3 показана ситуация, когда два процесса совместно используют три страницы, каждая из которых помечена как копируемая при записи, но ни один из процессов еще не пытался их модифицировать.

Если поток любого из этих процессов что-то записывает на такую страницу, генерируется исключение, связанное с управлением памятью. Обнаружив, что запись ведется на страницу с атрибутом «копирование при записи», диспетчер памяти, вместо того чтобы сообщить о нарушении доступа, выделяет в физической памяти новую страницу, доступную для чтения и записи, копирует в нее содержимое исходной страницы, обновляет соответствующую информацию о страницах, проецируемых на данный процесс, и закрывает исключение. B результате команда, вызвавшая исключение, выполняется повторно, и операция записи проходит успешно. Ho, как показано на рис. 7–4, новая страница теперь является личной собственностью процесса, инициировавшего запись, и не видима другим процессам, совместно использующим страницу с атрибутом «копирование при записи». Каждый процесс, что-либо записывающий на эту разделяемую страницу, получает в свое распоряжение ее закрытую копию.

Одно из применений копирования при записи — поддержка точек прерываний для отладчиков. Например, по умолчанию страницы кода доступны только для выполнения. Если программист при отладке программы устанавливает точку прерывания, отладчик должен добавить в код программы соответствующую команду. Для этого он сначала меняет атрибут защиты страницы на PAGE_EXECUTE_READWRITE, а затем модифицирует поток команд. Поскольку страница кода является частью проецируемого раздела, диспетчер памяти создает закрытую копию для процесса с установленной точкой прерывания, тогда как другие процессы по-прежнему используют исходную страницу кода.

Копирование при записи может служить примером алгоритма отложенной оценки (lazy evaluation), который диспетчер памяти применяет при любой возможности. B таких алгоритмах операции, чреватые большими издержками, не выполняются до тех пор, пока не станут абсолютно необходимыми, — если операция так и не понадобится, никаких издержек вообще не будет.

Подсистема POSIX использует преимущества копирования при записи в реализации функции fork. Как правило, если UNIX-приложения вызываютfork для создания другого процесса, то первое, что делает новый процесс, — обращается к функции exec для повторной инициализации адресного пространства исполняемой программы. Вместо копирования всего адресного пространства при вызове fork новый процесс использует страницы родительского процесса, помечая их как копируемые при записи. Если дочерний процесс что-то записывает на эти страницы, он получает их закрытую копию. B ином случае оба процесса продолжают разделять страницы без копирования. Так или иначе диспетчер памяти копирует лишь те страницы, на которые процесс пытается что-то записать, а не все содержимое адресного пространства.

Оценить частоту срабатывания механизма копирования при записи можно с помощью счетчика Memory: Write Copies/Sec (Память: Запись копий страниц/сек).

Диспетчер куч

Многие приложения выделяют память небольшими блоками (менее 64 Кб — минимума, поддерживаемого функциями типа VirtuaLAlloc). Выделение столь большой области (64 Кб) для сравнительно малого блока весьма неоптимально с точки зрения использования памяти и производительности. Для устранения этой проблемы в Windows имеется компонент — диспетчер куч (heap manager), который управляет распределением памяти внутри больших областей, зарезервированных с помощью функций, вьщеляющих память в соответствии с гранулярностью страниц. Гранулярность выделения памяти в диспетчере куч сравнительно мала: 8 байтов в 32-разрядных системах и 16 байтов в 64-разрядных. Диспетчер куч обеспечивает оптимальное использование памяти и производительность при выделении таких небольших блоков памяти.

Функции диспетчера куч локализованы в двух местах: в NtdlLdll и Ntoskrnl.exe. API-функции подсистем (вроде API-функций Windows-куч) вызывают функции из Ntdll, а компоненты исполнительной системы и драйверы устройств — из NtoskrnL Родные интерфейсы (функции с префиксом Rtl) доступны только внутренним компонентам Windows и драйверам устройств режима ядра. Документированный интерфейс Windows API для куч (функции с префиксом Heap) представляют собой тонкие оболочки, которые вызывают родные функции из NtdlLdll Кроме того, для поддержки устаревших Windows-приложений предназначены унаследованные API-функции (с префиксом Local или GlobaP). K наиболее часто используемым Windows-функциям куч относятся:

• HeapCreate или HeapDestroy — соответственно создает или удаляет кучу. При создании кучи можно указать начальные размеры зарезервированной и переданной памяти;

• HeapAlloc — выделяет блок памяти из кучи;

• HeapFree — освобождает блок, ранее выделенный через HeapAlloc

• HeapReAlloc — увеличивает или уменьшает размер уже выделенного блока;

• HeapLock и HeapUnlock — управляют взаимным исключением (mutual exclusion) операций, связанных с обращением к куче;

• HeapWalk — перечисляет записи и области в куче.

Типы куч

У каждого процесса имеется минимум одна куча — куча, выделяемая процессу по умолчанию (default process heap). Куча по умолчанию создается в момент запуска процесса и никогда не удаляется в течение срока жизни этого процесса. По умолчанию она имеет размер 1 Мб, но ее начальный размер может быть увеличен, если в файле образа указано иное значение с помощью ключа /HEAP компоновщика. Однако этот объем памяти резервируется только для начала и по мере необходимости автоматически увеличивается (в файле образа можно указать и начальный размер переданной памяти).

Куча по умолчанию может быть явно использована программой или неявно некоторыми внутренними Windows-функциями. Приложение запрашивает память из кучи процесса по умолчанию вызовом Windows-функции GetProcessHeap. Процесс может создавать дополнительные закрытые кучи вызовом HeapCreate. Когда куча больше не нужна, занимаемое ею виртуальное адресное пространство можно освободить, вызвав HeapDestroy. Массив всех куч поддерживается в каждом процессе, и поток может обращаться к ним через Windows-функцию GetProcessHeaps.

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

Структура диспетчера кучи

Как показано на рис. 7–5, диспетчер куч состоит из двух уровней: необязательного интерфейсного (front-end layer) и базового (core heap layer). Последний заключает в себе базовую функциональность, которая обеспечивает управление блоками внутри сегментов, управление сегментами, поддержку политик расширения кучи, передачу и возврат памяти, а также управление большими блоками.

Необязательный интерфейсный уровень (только для куч пользовательского режима) размещается поверх базового уровня. Существует два типа интерфейсных уровней: ассоциативные списки (look-aside lists) и куча с малой фрагментацией (Low Fragmentation Heap, LFH). LFH доступна лишь в Windows XP и более поздних версиях Windows. Единовременно для каждой кучи можно использовать только один интерфейсный уровень.

Синхронизация доступа к куче

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

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

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

Ассоциативные списки

Это однонаправленные связанные списки (single linked lists), поддерживающие элементарные операции вроде заталкивания в список или выталкивания из него по принципу «последним пришел, первым вышел» (Last In, First Out, LIFO) без применения блокирующих алгоритмов. Упрощенная версия этих структур данных также доступна Windows-приложениям через функции InterlockedPopEntrySList и InterlockedPushEntrySList. Для каждой кучи создается 128 ассоциативных списков, которые удовлетворяют запросы на выделение блоков памяти размером до 1 Кб на 32-разрядных платформах и до 2 Кб на 64-разрядных.

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

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

Диспетчер куч создает ассоциативные списки автоматически при создании кучи, если только эта куча расширяемая и не включен отладочный режим. У некоторых приложений могут возникать проблемы совместимости из-за использования диспетчером куч ассоциативных списков. B таких случаях для корректной работы нужно указывать флаг DisableHeapLookaside в параметрах выполнения файлов образов унаследованных приложений. (Эти параметры можно задавать с помощью утилиты Imagecfg.exe из Windows 2000 Server Resource Kit, supplement 1.)

Куча с малой фрагментацией

Многие приложения, выполняемые в Windows, используют сравнительно небольшие объемы памяти из куч (обычно менее одного мегабайта). Для этого класса приложений диспетчер куч применяет политику наибольшей подгонки (best-fit policy), которая помогает сохранять небольшим «отпечаток» каждого процесса в памяти. Однако такая стратегия не масштабируется для больших процессов и многопроцессорных машин. B этих случаях доступная память в куче может уменьшиться из-за ее фрагментации. B сценариях, где лишь блоки определенного размера часто используются параллельно разными потоками, выполняемыми на разных процессорах, производительность ухудшается. Дело в том, что нескольким процессорам нужно одновременно модифицировать один и тот же участок памяти (например, начало ассоциативного списка для блоков этого размера), а это приводит к объявлению недействительной соответствующей кэш-линии для других процессоров.

Эти проблемы решаются применением кучи с малой фрагментацией (LFH), которая использует базовый уровень диспетчера куч и ассоциативные списки. B отличие от ситуации, в которой ассоциативные списки по умолчанию применяются как интерфейсные, если это разрешено другими параметрами куч, поддержка LFH включается, только когда приложение вызывает функцию HeapSetInformation. B случае больших куч значительная доля запросов на выделение обычно раскладывается на относительно небольшое число корзин (buckets) определенных размеров. Стратегия выделения памяти, применяемая LFH, заключается в оптимизации использования памяти для таких запросов за счет эффективной обработки блоков одного размера.

Для устранения проблем с масштабируемостью LFH раскрывает часто используемые внутренние структуры в набор слотов, в два раза больший текущего количества процессоров в компьютере. Закрепление потоков за этими слотами выполняется LFH-компонентом, называемым диспетчером привязки (affinity manager). Изначально LFH использует для распределения памяти первый слот, но, как только возникает конкуренция при доступе к некоторым внутренним данным, переключает текущий поток на другой слот. И чем больше конкуренция, тем большее число слотов задействуется для потоков. Эти слоты создаются для корзины каждого размера, что также увеличивает локальность и сводит к минимуму общий расход памяти.

Средства отладки

Диспетчер куч предоставляет несколько средств, помогающих обнаруживать ошибки.

• Enable tail checking (включить проверку концевой части блока) B конец каждого блока помещается сигнатура, проверяемая при его освобождении. Если эта сигнатура полностью или частично уничтожается из-за переполнения буфера, куча сообщает о соответствующей ошибке.

• Enable free checking (включить проверку свободных блоков) Свободный блок заполняется определенным шаблоном, который проверяется, когда диспетчеру куч нужен доступ к этому блоку. Если процесс продолжает записывать в блок после его освобождения, диспетчер куч обнаружит изменения в шаблоне и сообщит об ошибке.

• Parameter checking (проверка параметров) Проверка параметров, передаваемых функциям куч.

• Heap validation (проверка кучи) Вся куча проверяется при каждом обращении к ней.

• Heap tagging and stack traces support (поддержка меток и трассировки стека) Это средство поддерживает задание меток для выделяемой памяти и/или перехват трассировок стека пользовательского режима при обращениях к куче, что помогает локализовать причину той или иной ошибки.

Первые три средства включаются по умолчанию, если загрузчик обнаруживает, что процесс запущен под управлением отладчика. (Отладчик может переопределить такое поведение и выключить эти средства.) Средства отладки для куч могут быть заданы установкой различных отладочных флагов в заголовке образа через утилиту gflags (см. раздел «Глобальные флаги Windows» в главе 3) или командой !heap в любом стандартном отладчике Windows.

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

Pageheap

Так как при проверке концевых частей блоков и шаблона свободных блоков могут обнаруживаться повреждения, произошедшие задолго до проявления собственно проблемы, предоставляется дополнительный инструмент отладки куч, pageheap, который переадресует все обращения к куче (или их часть) другомудиспетчеру куч. Pageheap является частью Windows Application Compatibility Toolkit, и его можно скачать с www.microsoft.com. Pageheap помещает выделенные блоки в конец страниц, поэтому при переполнении буфера возникнет нарушение доступа, что упростит выявление ошибочного кода. Блоки можно помещать и в начало страниц для обнаружения проблем, связанных с неполным использованием буферов (buffer underruns). (Такие ситуации — большая редкость.) Pageheap также позволяет защищать освобожденные страницы от любых видов доступа для выявления ссылок на блоки после их освобождения.

Заметьте, что применение pageheap может привести к нехватке адресного пространства, так как выделение даже очень малых блоков памяти сопряжено с существенными издержками. Также может ухудшиться производительность из-за увеличения количества ссылок на обнуленные страницы, потери локальности и частых вызовов для проверки структур кучи. Чтобы уменьшить негативное влияние на производительность, pageheap можно использовать только для блоков определенных размеров, конкретных диапазонов адресов и т. д.

ПРИМЕЧАНИЕ Подробнее о pageheap см. статью 286470 в Microsoft Knowledge Base (http://support.microsoft.com).

Address Windowing Extensions

Хотя 32-разрядные версии Windows поддерживают до 128 Гб физической памяти (см. таблицу 2–4 в главе 2), размер виртуального адресного пространства любого 32-разрядного пользовательского процесса по умолчанию равен 2 Гб (при указании загрузочных параметров /3GB и /USERVA в Boot.ini этот размер составляет 3 Гб). Чтобы 32-разрядный процесс мог получить доступ к большему объему физической памяти, Windows поддерживает набор функций под общим названием Address Windowing Extensions (AWE). Так, в системе под управлением Windows 2000 Advanced Server с 8 Гб физической памяти серверное приложение базы данных может с помощью AWE использовать под кэш базы данных до 6 Гб памяти.

Выделение и использование памяти через функции AWE осуществляется в три этапа.

1. Выделение физической памяти.

2. Создание региона виртуального адресного пространства — окна, на которое будут проецироваться представления физической памяти.

3. Проецирование на окно представлений физической памяти.

Для выделения физической памяти приложение вызывает Windows-функцию AllocateUserPhysicalPages. (Эта функция требует, чтобы у пользователя была привилегия Lock Pages In Memory.) Затем приложение обращается к Windows-функции VirtucriAlloc с флагом MEM_PHYSICAL, чтобы создать окно в закрытой части адресного пространства процесса, на которое проецируется (частично или полностью) ранее выделенная физическая память. Память, выделенная через AWE, может быть использована почти всеми функциями Windows API. (Например, функции Microsoft DirectX ее не поддерживают.)

Если приложение создает в своем адресном пространстве окно размером 256 Мб и выделяет 4 Гб физической памяти (в системе с объемом физической памяти более 4 Гб), то оно получает доступ к любой части физической памяти, проецируя ее на это окно через Wmdows-функции MapUserPhysicalPages или MapUserPhysicalPagesScatter. Размер физической памяти, единовременно доступный приложению при такой схеме выделения, определяется размером окна в виртуальном адресном пространстве. Ha рис. 7–6 показано AWE-ОKHO в адресном пространстве серверного приложения, на которое проецируется регион физической памяти, предварительно выделенный через AllocateUserPhysicalPages.

AWE-функции имеются во всех выпусках Windows и доступны независимо от объема физической памяти в системе. Однако AWE наиболее полезен в системах с объемом физической памяти не менее 2 Гб, поскольку тогда этот механизм — единственное средство для прямого использования более чем 2 Гб памяти 32-разрядным процессом. Еще одно его применение — защита. Так как AWE-память никогда не выгружается на диск, данные в этой памяти никогда не имеют копии в страничном файле, а значит, никто не сумеет просмотреть их, загрузив компьютер с помощью альтернативной операционной системы.

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

• Страницы такой памяти нельзя разделять между процессами.

• Одну и ту же физическую страницу нельзя проецировать по более чем одному виртуальному адресу в рамках одного процесса.

• B более старых версиях Windows страницы такой памяти могут иметь единственный атрибут защиты — «для чтения и записи». B Windows Server

2003 Service Pack 1 и выше также поддерживаются атрибуты «нет доступа» и «только для чтения».

O структурах данных таблицы страниц, используемой для проецирования памяти в системах с более чем 4 Гб физической памяти, см. раздел «Phy-sical Address Extension (PAE)» далее в этой главе.

Системные пулы памяти

При инициализации системы диспетчер памяти создает два типа динамических пулов памяти, используемых компонентами режима ядра для выделения системной памяти.

• Пул неподкачиваемой памяти (nonpaged pool) Состоит из диапазонов системных виртуальных адресов, которые всегда присутствуют в физической памяти и доступны в любой момент (при любом IRQL и из контекста любого процесса) без генерации ошибок страниц. Одна из причин существования такого пула — невозможность обработки ошибок страниц при IRQL уровня «DPC/dispatch» и выше (см. главу 2).

• Пул подкачиваемой памяти (paged pool) Регион виртуальной памяти в системном пространстве, содержимое которого система может выгружать в страничный файл и загружать из него. Драйверы, не требующие доступа к памяти при IRQL уровня «DPC/dispatch» и выше, могут использовать память из этого пула. Он доступен из контекста любого процесса. Оба пула находятся в системном адресном пространстве и проецируются на виртуальное адресное пространство любого процесса (их начальные адреса в системной памяти перечислены в таблице 7–8). Исполнительная система предоставляет функции для выделения и освобождения памяти в этих пулах (см. описание функций, чьи имена начинаются c ExAllocatePool, в Windows DDK).

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

ПРИМЕЧАНИЕ Будущие выпуски Windows, возможно, будут поддерживать пулы динамических размеров, а значит, лимита на максимальный размер больше не будет. Таким образом, в приложениях и драйверах устройств нельзя исходить из того, что максимальный размер пула является фиксированной величиной в любой системе.

Настройка размеров пулов

Чтобы установить другие начальные размеры этих пулов, измените значения параметров NonPagedPoolSize и PagedPoolSize в разделе реестра HKLM\ SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management с 0 (при этом система сама вычисляет размеры) на нужные величины (в байтах). Ho вы не сможете превысить предельные значения, перечисленные в таблице 7–5. Значение OxFFFFFFFF для PagedPoolSize указывает, что выбран наибольший из возможных размеров, однако увеличение пула подкачиваемой памяти будет происходить за счет записей системной таблицы страниц (page table entries, РТЕ).

Таблица 7–5. Максимальные размеры пулов

Рассчитанные значения размеров хранятся в четырех переменных ядра, три из которых экспортируются как счетчики производительности. Имена переменных, счетчиков и параметров реестра, позволяющих изменять размеры пулов, перечислены в таблице 7–6.

Таблица 7–6. Переменные и счетчики производительности, отражающие размеры системных пулов

ЭКСПЕРИМЕНТ: определяем максимальные размеры пулов

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

Получить максимальные размеры пулов можно с помощью Process Explorer или отладки ядра в работающей системе (см. главу 1). Для просмотра этих данных через Process Explorer, щелкните View, System Information. Максимальные размеры пулов показываются в секции Kernel Memory, как на следующей иллюстрации.

Заметьте: чтобы Process Explorer мог получить эту информацию, у него должен быть доступ к символам для ядра данной системы. (Как настроить Process Explorer на использование символов, см. в эксперименте «Просмотр детальных сведений о процессах с помощью Process Explorer» в главе 1.)

Для просмотра той же информации в отладчике ядра используйте команду !vm

B этой системе размеры пулов подкачиваемой и неподкачиваемой памяти далеки от своих максимумов. Отладчик ядра также позволяет изучить значения переменных ядра, перечисленных в таблице 7–6:

kd› dd mmmaximumnonpagedpoolinbytes 11 8047f620 0328c000 kd›? 328c000

Evaluate expression: 53002240 = 0328c000

kd› dd mmsizeofpagedpoolinbytes 11 80470a98 06800000 kd›? 6800000

Evaluate expression: 109051904 = 06800000

Из этого примера видно, что максимальный размер неподкачива-емого пула составляет 53 002 240 байтов (примерно 50 Мб), а максимальный размер подкачиваемого пула — 109 051 904 байта (104 Мб). B тестовой системе, использованной нами для этого эксперимента, текущий размер использованной памяти неподкачиваемого пула составлял 5,5 Мб, а подкачиваемого пула — 34 Мб, так что оба пула были далеки от заполнения.

Мониторинг использования пулов

Объект Memory (Память) предоставляет отдельные счетчики размеров пулов неподкачиваемой и подкачиваемой памяти (как для виртуальной, так и для физической частей). Кроме того, утилита Poolmon из Windows Support Tools сообщает детальную информацию об использовании этих пулов. Для просмотра такой информации нужно включить внутренний параметр Enable Pool Tagging (который всегда включен в проверочных версиях, а также в Windows Server 2003, где его вообще нельзя выключить). Чтобы включить данный параметр, запустите утилиту Gflags из Windows Support Tools, Platform SDK или DDK и выберите переключатель Enable Pool Tagging, как показано ниже.

Теперь щелкните кнопку Аррlу и перезагрузите систему. После перезагрузки запустите Poolmon. При этом вы должны увидеть примерно следующее.

Строки с меняющимися данными выделяются подсветкой. (Ee можно выключить, введя букву / в окне Poolmon. Повторный ввод / вновь включает подсветку.) Нажав клавишу со знаком вопроса в Poolmon, можно просмотреть справочный экран. Вы можете указать пулы, за которыми хотите наблюдать (только подкачиваемый, только неподкачиваемый или и то, и другое), а также порядок сортировки. Кроме того, на справочном экране поясняются параметры командной строки, позволяющие наблюдать за конкретными структурами (или за всеми структурами, но одного типа). Так, команда poolmon — iCM позволит следить только за структурами типа CM (которые принадлежат диспетчеру конфигурации, управляющему реестром). Колонки, в которых программа выводит свою информацию, описаны в таблице 7–7.

B этом примере структуры CM занимают основную часть пула подкачиваемой памяти, а структуры MmSt (структуры, относящиеся к управлению памятью и используемые для проецируемых файлов) — основную часть пула неподкачиваемой памяти.

Описание меток пулов см. в файле \Program Files\Debugging Tools for Windows\Triage\Pooltag.txt. (Он устанавливается вместе с Windows Debugging Tools.) Поскольку в этом файле не перечислены метки пулов для сторонних драйверов устройств, используйте ключ — с в версии Poolmon, поставляемой с Windows Server 2003 Device Driver Kit (DDK), для генерации файла меток локальных пулов (Localtag.txt). B этом файле содержатся метки пулов, используемых любыми драйверами, которые были обнаружены в вашей системе. (Учтите: если двоичный файл драйвера устройства был удален после загрузки, метки его пулов не распознаются.)

B качестве альтернативы можно вести поиск драйверов устройств в системе по метке пула, используя утилиту Strings.exe. Например, команда:

strings \windows\system32\drivers\*.sys › findstr /i "abcd"

покажет драйверы, содержащие строку «abcd». Заметьте, что драйверы устройств не обязательно должны находиться в \Windows\System32\Drivers — они могут быть в любом каталоге. Чтобы перечислить полные пути всех загруженных драйверов, откройте меню Start (Пуск), выберите команду Run (Выполнить) и введите Msinfo32. Потом щелкните Software Environment (Программная среда) и System Drivers (Системные драйверы).

Еще один способ для просмотра использования пулов драйвером устройства — включение наблюдения за пулами в Driver Verifier (см. далее в этой главе). Хотя при этом способе сопоставление метки пула с драйвером не нужно, он требует перезагрузки (чтобы включить функциональность наблюдения за пулами в Driver Verifier для интересующих вас драйверов). После этого вы можете либо запустить Driver Verifier Manager (\Windows\System32\ Verifier.exe), либо использовать команду Verifier /Log для записи информации об использовании пулов в какой-либо файл.

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

ЭКСПЕРИМЕНТ: анализ утечки памяти в пуле

B этом эксперименте вы устраните реальную утечку в пуле подкачиваемой памяти в своей системе, чтобы научиться на практике применять способы, описанные в предыдущем разделе. Утечка будет создаваться утилитой NotMyFault, которую можно скачать по ссылке wwwsysintemals.com/windowsinternalsshtmL (Заметьте, что эта утилита отсутствует в списке инструментов на основной странице Sysinternals.) После запуска NotMyFault.exe загружает драйвер устройства Myfault.sys и выводит такое диалоговое окно.

1. Щелкните кнопку Leak Pool. Это заставит NotMyFault посылать запросы драйверу устройства Myfault на выделение памяти из подкачиваемого пула. (He нажимайте кнопку Do Bug, иначе вы вызовете крах системы; предназначение этой кнопки описывается в главе 14, где демонстрируются различные типы аварийных ситуаций.) NotMyFault продолжит посылать запросы, пока вы не щелкнете кнопку Stop Leaking. Заметьте, что пул подкачиваемой памяти не освобождается даже при закрытии программы; в нем происходит постоянная утечка памяти до перезагрузки системы. Однако, поскольку утечка пула будет непродолжительной, это не должно вызвать никаких проблем в вашей системе.

2. Пока происходит утечка памяти в пуле, сначала откройте диспетчер задач и перейдите на вкладку Performance (Быстродействие). Вы увидите, как растет показатель Paged Pool (Выгружаемая память). To же самое можно увидеть в окне System Information утилиты Process Explorer. (Выберите Show и System Information.)

3. Чтобы определить метку пула, где происходит утечка, запустите Poolmon и нажмите клавишу b, чтобы сортировать по числу байтов. Дважды нажмите клавишу p для отображения в Poolmon только пула подкачиваемой памяти. Вы должны заметить, что пул с меткой «Leak» поднимается вверх по списку. (Poolmon выделяет строки, где происходят изменения.)

4. Теперь щелкните кнопку Stop Leaking, чтобы не истощить пул подкачиваемой памяти в своей системе.

5. Используя приемы, описанные в предыдущем разделе, запустите Strings (ее можно скачать с wwwsysinternals.com) для поиска двоичных файлов драйвера, содержащих метку пула «Leak»:

Strings \windows\system32\drivers\*.sys | findstr Leak

Эта команда должна указать на файл Myfault.sys.

Ассоциативные списки

Windows поддерживает механизм быстрого выделения памяти — ассоциативные списки (look-aside lists). Главное различие между пулом и ассоциативным списком в том, что из пула можно выделять блоки памяти различного размера, а из ассоциативного списка — только фиксированные. Хотя пулы обеспечивают более высокую гибкость, ассоциативные списки работают быстрее, так как не используют спин-блокировку и не заставляют систему подбирать подходящую область свободной памяти, в которой мог бы уместиться текущий выделяемый блок.

Функции ExInitializeNPagedLookasideList и ExInitializePagedLookasideList (документированные в DDK) позволяют компонентам исполнительной системы и драйверам устройств создавать ассоциативные списки, размеры которых кратны размерам наиболее часто используемых структур данных. Для минимизации издержек, связанных с синхронизацией в многопроцессорных системах, некоторые компоненты исполнительной системы, в том числе диспетчер ввода-вывода, диспетчер кэша и диспетчер объектов, создают отдельные для каждого процессора ассоциативные списки, из которых выделяется память под часто используемые структуры данных. Сама исполнительная система создает для каждого процессора универсальные ассоциативные списки подкачиваемой и неподкачиваемой памяти с гранулярностью выделения в 256 байтов или менее.

Если ассоциативный список пуст (как это бывает сразу после его создания), система должна выделить память из подкачиваемого или неподкачиваемого пула. Ho если в списке уже присутствует освобожденная структура, то занимаемая ею память выделяется очень быстро. (Список разрастается по мере возврата в него структур.) Процедуры выделения памяти из пула автоматически настраивают число освобожденных буферов, хранящихся в ассоциативном списке, в зависимости от частоты выделения памяти из этого списка драйвером или компонентом исполнительной системы. Чем чаще они выделяют память из списка, тем больше буферов в списке. Размер ассоциативных списков автоматически уменьшается, если память из них не выделяется. (Эта проверка выполняется раз в секунду, когда системный поток диспетчера настройки баланса пробуждается и вызывает функцию KiAdjustLookasideDepth.)

ЭКСПЕРИМЕНТ: просмотр системных ассоциативных списков

Содержимое и размер различных ассоциативных списков в системе можно просмотреть командой !lookaside отладчика ядра. Вот фрагмент вывода этой команды.

Утилита Driver Verifier

Driver Verifier представляет собой механизм, который можно использовать для поиска и локализации наиболее распространенных ошибок в драйверах устройств и другом системном коде режима ядра. Microsoft проверяет с помощью Driver Verifier свои драйверы и все драйверы, передаваемые производителями оборудования для тестирования на совместимость и включения в список Hardware Compatibility List (HCL). Такое тестирование гарантирует совместимость драйверов, включенных в список HCL, с Windows и отсутствие в них распространенных ошибок. (Существует и парная утилита Application Verifier, позволяющая улучшить качество кода пользовательского режима. Однако в этой книге она не рассматривается.)

Driver Verifier поддерживается несколькими системными компонентами — диспетчером памяти, диспетчером ввода-вывода и HAL, которые предусматривают параметры, включаемые для верификации драйверов. B этом разделе поясняются параметры верификации драйверов на отсутствие ошибок, связанных с управлением памятью (см. также главу 9).

Настройка и инициализация Driver Verifier

Для настройки Driver Verifier и просмотра статистики запустите Driver Verifier Manager (Диспетчер проверки драйверов), файл \Windows\System32\Verifier.exe. После запуска появится окно с несколькими вкладками. Версия окна для Windows 2000 приведена на рис. 7–7. Чтобы указать, какие драйверы устройств вы хотите проверить, и задать типы проверок, используйте вкладку Settings (Параметры).

B Windows XP и Windows Server 2003 этой утилите придали интерфейс в стиле мастера, как показано на рис. 7–8.

Рис. 7–8. Driver Verifier Manager в Windows XP и Windows Server 2003

Включать и отключать Driver Verifier, а также просматривать текущие параметры можно из командной строки этой утилиты. Для вывода списка ключей наберите verifier /?.

Настройки Driver Verifier Manager хранятся в разделе реестра HKLM\SYS-TEM\CurrentControlSet\Control\Session Manager\Memory Management. Параметр VerifyDriverLevel содержит битовую маску, представляющую включенные типы проверок. Имена проверяемых драйверов содержатся в параметре VerifyDrivers. (Эти параметры создаются в реестре только после выбора проверяемых драйверов в окне Driver Verifier Manager.) Если вы выберете верификацию всех драйверов, VerifyDrivers будет содержать символ звездочки. B зависимости от выбранных параметров может понадобиться перезагрузка системы.

Ha ранних этапах загрузки диспетчер памяти считывает из реестра значения этих параметров, определяя, какие драйверы следует верифицировать и какие параметры Driver Verifier включены. (Если загрузка происходит в безопасном режиме, все параметры Driver Verifier игнорируются.) Далее, если для проверки выбран хотя бы один драйвер, ядро сравнивает имя каждого загружаемого драйвера с именами драйверов, подлежащих верификации. Если имена совпадают, ядро вызывает функцию MiApplyDriverVerifer, которая заменяет все ссылки драйвера на функции ядра ссылками на эквивалентные функции Driver Verifier. Так, ExAllocatePool заменяется на VerifierAllocatePool. Драйвер подсистемы управления окнами производит аналогичные замены для использования эквивалентных функций Driver Verifier.

Теперь рассмотрим четыре параметра верификации драйверов, относящиеся к использованию памяти: Special Pool, Pool Tracking, Force IRQL Checking и Low Resources Simulation.

Special Pool (Особый пул)

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

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

Ha рис. 7–9 приведен пример блока, выделенного Driver Verifier в особом пуле для проверяемого драйвера устройства.

По умолчанию Driver Verifier распознает ошибки, связанные с попытками обращения за верхнюю границу выделенного блока (overrun errors). Он делает это, помещая используемый драйвером буфер в конец выделенной страницы и заполняя ее начало случайными значениями. Хотя Driver Verifier Manager не предусматривает параметр для включения детекции ошибок, связанных с попытками обращения за нижнюю границу выделенного блока (underrun errors), вы можете активизировать ее вручную, добавив в раздел реестра HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\MemoryManagement параметр PoolTagOverruns типа DWORD и присвоив ему значение O (или запустив утилиту Gflags и установив флажок Verify Start вместо установленного по умолчанию Verify End). Тогда Driver Verifier будет размещать буфер драйвера не в конце, а в начале страницы.

Конфигурация, при которой Driver Verifier обнаруживает ошибки типа «overrun», до некоторой степени обеспечивает и распознавание ошибок типа «underrun». Когда драйвер освобождает буфер и возвращает его в Driver Verifier, последний должен убедиться, что содержимое памяти, предшествующее буферу, не изменилось. Иное означает, что драйвер обратился к памяти, расположенной до начала буфера, и что-то записал за пределами этого буфера.

При выделении памяти из особого пула и ее освобождении также проверяется корректность IRQL процессора. Эта проверка позволяет выявить ошибку, встречающуюся в некоторых драйверах, из-за которой они пытаются выделять память в подкачиваемом пуле при IRQL уровня «DPC/dispatch» или выше.

Особый пул можно сконфигурировать и вручную, добавив в раздел реестра HKLM\SYSTEMCurrentControlSet\Control\Session Manager\Memory Management параметр PoolTag типа DWORD; он представляет тэги выделенной памяти, используемые системой для особого пула. Тогда, даже если Driver Verifier не настроен на верификацию данного драйвера, при совпадении тэга, сопоставленного с выделенной драйвером памятью, и значения PoolTag, память будет выделяться из особого пула. Если вы присвоите PoolTag значение 0x0000002a или символ подстановки (*), то при наличии достаточного количества физической и виртуальной памяти вся память для драйверов будет выделяться из особого пула. (Если памяти не хватит, драйверы вернутся к использованию обычного пула; размер каждого выделяемого блока ограничен двумя страницами.)

Pool Tracking (Слежение за пулом)

Если параметр Pool Tracking активен, диспетчер памяти проверяет при выгрузке драйвера, освободил ли тот всю выделенную для него память. Если нет, диспетчер памяти вызывает крах системы и сообщает о сбойном драйвере. Driver Verifier тоже показывает общую статистику по использованию пула — откройте вкладку Pool Tracking (Слежение за пулом) в Driver Verifier Manager (Диспетчер проверки драйверов). Кроме того, пригодится и команда!verifier отладчика ядра; она, кстати, выводит больше информации, чем Driver Verifier.

Force IRQL Checking (Обяз. проверка IRQL)

Одна из самых распространенных ошибок в драйверах устройств — попытка обращения к страничному файлу при слишком высоком уровне IRQL процессора. Как уже говорилось в главе 3, диспетчер памяти не обрабатывает ошибки страниц при IRQL уровня «DPC/dispatch» или выше. Система часто не распознает экземпляры драйвера, обращающиеся к данным из подкачиваемого пула при повышенном IRQL процессора, поскольку в этот момент такие данные физически присутствуют в памяти. Ho в других случаях, если эти данные выгружены в страничный файл, попытка обращения к ним вызывает крах системы со стоп-кодом IRQL_NOT_LESS_OR_EQUAL (т. е. IRQL превышает тот уровень, при котором возможно обращение к подкачиваемой памяти).

Проверка драйверов устройств на наличие подобной ошибки — дело очень трудное, но Driver Verifier упрощает эту задачу. Если параметр Force IRQL Checking включен, Driver Verifier выводит весь подкачиваемый код и данные режима ядра из системного рабочего набора всякий раз, когда проверяемый драйвер повышает IRQL. Это делается с помощью внутренней функции MmTnmAUSystemPagableMemory. При любой попытке проверяемого драйвера обратиться к подкачиваемой памяти при повышенном IRQL система фиксирует нарушение доступа и происходит крах с сообщением, указывающим на сбойный драйвер.

Low Resources Simulation (Нехватка ресурсов)

При включении этого параметра Driver Verifier случайным образом отклоняет некоторые запросы драйвера на выделение памяти. Раньше разработчики создавали многие драйверы устройств в расчете на то, что памяти ядра всегда достаточно, так как иное означало бы, что система все равно вот-вот рухнет. Ho, поскольку временная нехватка памяти иногда возможна, драйверы устройств должны корректно обрабатывать ошибки выделения памяти при ее нехватке.

Через 7 минут после загрузки системы (этого времени достаточно для завершения критического периода инициализации, когда из-за нехватки памяти драйвер мог бы просто не загрузиться) Driver Verifier начинает случайным образом отклонять запросы проверяемых драйверов на выделение памяти. Если драйвер не в состоянии корректно обработать ошибки выделения памяти, это скорее всего проявится в виде краха системы.

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

Структуры виртуального адресного пространства

Здесь описываются компоненты в пользовательском и системном адресных пространствах, а также специфика адресных пространств в 32- и 64-разрядных системах. Эта информация поможет вам понять ограничения на виртуальную память для процессов и системы на обеих платформах.

Ha виртуальное адресное пространство в Windows проецируются три основных вида данных: код и данные, принадлежащие процессу, код и данные, принадлежащие сеансу, а также общесистемные код и данные.

Как мы поясняли в главе 1, каждому процессу выделяется собственное адресное пространство, недоступное другим процессам (если только у них нет разрешения на открытие процесса с правами доступа для чтения и записи). Потоки внутри процесса никогда не получают доступа к виртуальным адресам вне адресного пространства своего процесса, если только не проецируют данные на раздел общей памяти и/или не используют специальные функции, позволяющие обращаться к адресному пространству другого процесса. Сведения о виртуальном адресном пространстве процесса хранятся в таблицах страниц (page tables), которые рассматриваются в разделе по трансляции адресов. Таблицы страниц размещаются на страницах памяти, доступных только в режиме ядра, поэтому пользовательские потоки в процессе не могут модифицировать структуру адресного пространства своего процесса.

B системах с поддержкой нескольких сеансов (Windows 2000 Server с установленной службой Terminal Services, Windows XP и Windows Server 2003) пространство сеанса содержит информацию, глобальную для каждого сеанса. (Подробное описание сеанса см. в главе 2.) Сеанс (session) состоит из процессов и других системных объектов (вроде WindowStation, рабочих столов и окон). Эти объекты представляют сеанс единственного пользователя, который зарегистрировался на рабочей станции. У каждого сеанса есть своя область пула подкачиваемой памяти, используемая подсистемой Windows (Win32k.sys) для выделения памяти под сеансовые GUI-структуры данных. Кроме того, каждый сеанс получает свою копию процесса подсистемы Windows (Csrss.exe) и Winlogon.exe. За создание новых сеансов отвечает процесс диспетчера сеансов (Smss.exe). Его задачи включают загрузку сеансовых копий Win32k.sys и создание специфических для сеанса экземпляров процессов Csrss и Winlogon, а также пространства имен диспетчера объектов.

Для виртуализации сеансов все общие для сеанса структуры данных проецируются на область системного пространства, которая называется пространством сеанса (session space). При создании процесса этот диапазон адресов проецируется на страницы, принадлежащие тому сеансу, к которому относится данный процесс. Размер области для проецируемых представлений в пространстве сеанса можно настраивать, используя параметры в разделе реестра HKLM\System\CurrentControlSet\Control\Session Manager\ Memory Management. (B 32-разрядных системах эти параметры игнорируются при загрузке системы с параметром /3GB.)

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

• Системный код Содержит образ операционной системы, HAL и драйверы устройств, используемые для загрузки системы.

• Представления, проецируемые системой Сюда проецируются Win32k.sys, загружаемая часть подсистемы Windows режима ядра, а также используемые ею графические драйверы режима ядра (подробнее о Win32k.sys см. главу 2).

• Гиперпространство Особая область, применяемая для проецирования списка рабочего набора процесса и временного проецирования других физических страниц для таких операций, как обнуление страницы из списка свободных страниц (если список обнуленных страниц пуст и нужна обнуленная страница), подготовка адресного пространства при создании нового процесса и объявление недействительными PTE в других таблицах страниц (например, при удалении страницы из списка простаивающих страниц).

• Список системного рабочего набора Структуры данных списка рабочего набора, описывающие системный рабочий набор.

• Системный кэш Виртуальное адресное пространство, применяемое для проецирования файлов, открытых в системном кэше. (O диспетчере кэша см. главу 11.)

• Пул подкачиваемой памяти Системная куча подкачиваемой памяти.

• Элементы системной таблицы страниц (PTE) Пул системных РТЕ, используемых для проецирования таких системных страниц, как пространство ввода-вывода, стеки ядра и списки дескрипторов памяти. Вы можете узнать, сколько системных PTE доступно, проверив значение счетчика Memory Free System Page Table Entries (Память: Свободных элементов таблицы страниц) в оснастке Performance (Производительность).

• Пул неподкачиваемой памяти Системная куча неподкачиваемой памяти, обычно состоящая из двух частей, которые располагаются внизу и вверху системного пространства.

• Данные аварийного дампа Область, зарезервированная для записи информации о состоянии системы на момент краха.

• Область, используемая HAL Область, зарезервированная под структуры, специфичные для HAL.

ПРИМЕЧАНИЕ Внутреннее название системного рабочего набора — рабочий набор системного кэша (system cache working set). Однако этот термин неудачен, так как в системный рабочий набор входит не только кэш, но и пул подкачиваемой памяти, подкачиваемые системные код и данные, а также подкачиваемые код и данные драйверов.

Теперь после краткого обзора базовых компонентов виртуального адресного пространства в Windows давайте рассмотрим специфику структур этого пространства на платформах x86, IA64 и x64.

Структуры пользовательского адресного пространства на платформе x86

По умолчанию каждый пользовательский процесс в 32-разрядной версии Windows располагает собственным адресным пространством размером до Гб; остальные 2 Гб забирает себе операционная система. Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows XP Service Pack 2 и выше, a также Windows Server 2003 (все версии) поддерживают загрузочный параметр (ключ /3GB в Boot.ini), позволяющий создавать пользовательские адресные пространства размером по 3 Гб. Windows XP и Windows Server 2003 поддерживают дополнительный ключ (/USERVA), который дает возможность задавать размер пользовательского адресного пространства между 2 и 3 Гб (значение указывается в мегабайтах). Структуры этих двух адресных пространств показаны на рис. 7-10.

Поддержка возможности расширения пользовательского адресного пространства для 32-разрядного процесса за пределы 2 Гб введена как временное решение для поддержки приложений вроде серверов баз данных, которым для хранения данных требуется больше памяти, чем возможно в 2-гигабайтном адресном пространстве. Ho лучше, конечно, пользоваться уже рассмотренными AWE-функциями.

Для расширения адресного пространства процесса за пределы 2 Гб в заголовке образа должен быть указан флаг IMAGE_FILE_LARGE_ADDRESS_AWARE. Иначе Windows резервирует это дополнительное пространство, и виртуальные адреса выше 0x7FFFFFFF становятся недоступны приложению. (Так делается, чтобы избежать краха приложения, не способного работать с этими адресами.) Этот флаг можно задать ключом компоновщика /LARGEADDRESSAWARE при сборке исполняемого файла. Данный флаг не действует при запуске приложения в системе с 2-гигабайтным адресным пространством для пользовательских процессов. (Если вы загрузите любую версию Windows Server с параметром /3GB, размер системного пространства уменьшится до 1 Гб, но пользовательское пространство все равно останется двухгигабайтным, даже несмотря на поддержку запускаемой программой большого адресного пространства.)

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

• Lsass.exe — подсистема локальной аутентификации;

• Inetinfo.exe — Internet Information Services (IIS); • Chkdsk.exe — утилита Check Disk;

• Dllhst3g.exe — специальная версия Dllhost.exe (для СОМ+-приложений).

Наконец, поскольку по умолчанию память, выделяемая через VirtualAlloc, начинается с младших адресов (если только процесс не выделяет очень много виртуальной памяти или не имеет очень сильно фрагментированного виртуального адресного пространства), она никогда не достигает самых старших адресов. Поэтому при тестировании вы можете указать, что выделение памяти должно начинаться со старших адресов. Для этого добавьте в реестр DWORD-параметр HKLM\System\CurrentControlSet\Control\SessionManager\Memory Management\AIlocationPreference и присвойте ему значение 0x100000.

Структура системного адресного пространства на платформе x86

B этом разделе подробно описывается структура и содержимое системного пространства в 32-разрядной Windows. Ha рис. 7-11 показана общая схема 2-гигабайтного системного пространства на платформе x86.

B таблице 7–8 перечислены переменные ядра, содержащие стартовые и конечные адреса различных регионов системного пространства: одни из них фиксированы, а другие вычисляются при загрузке с учетом доступного объема системной памяти и выпуска операционной системы Windows — клиентского или серверного.

Пространство сеанса на платформе x86

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

Размеры областей в сеансовом пространстве можно настраивать, добавляя параметры в раздел реестра HKLM\System\CurrentControlSet\Control\Session

Manager\Memory Management. Эти параметры и соответствующие переменные ядра, которые содержат реальные значения, перечислены в таблице 7-9-

ЭКСПЕРИМЕНТ: просмотр сеансов

Узнать, какие процессы и к каким сеансам относятся, можно по счетчику производительности Session ID (Код сеанса). Он доступен через диспетчер задач, Process Explorer или оснастку Performance (Производительность). Используя команду !session отладчика ядра, можно перечислить активные сеансы:

lkd›!session Sessions on machine: 3 Valid Sessions: 0 1 2 Current Session 0

Далее вы можете установить активный сеанс командой !session — s и вывести адрес сеансовых структур данных и список процессов в этом сеансе командой !sprocess:

Для просмотра детальных сведений о сеансе выведите дамп структуры MM_SESSION_SPACE командой dt:

ЭКСПЕРИМЕНТ: просмотр памяти, используемой пространством сеанса

Просмотреть, как используется память в пространстве сеанса, позволяет команда !vm 4 отладчика ядра. Вот пример для 32-разрядной системы Windows Server 2003 Enterprise Edition с двумя активными сеансами:

Ta же команда применительно к 64-разрядной системе Windows Server 2003 Enterprise Edition с двумя активными сеансами дает следующий вывод:

Системные PTE

Системные PTE используются для динамического проецирования системных страниц, в частности пространства ввода-вывода, стеков ядра и списков дескрипторов памяти. Системные PTE не являются неисчерпаемым ресурсом. Например, Windows 2000 может описывать всего 660 Мб системного виртуального адресного пространства (из которых 440 Мб могут быть непрерывными). B 32-разрядных версиях Windows XP и Windows Server 2003 число доступных системных PTE увеличилось, благодаря чему система может описывать до 1,3 Гб системного виртуального адресного пространства, из которых 960 Мб могут быть непрерывными. B 64-разрядной Windows системные PTE позволяют описывать до 128 Гб непрерывного виртуального адресного пространства.

Число системных PTE показывается счетчиком Memory: Free System Page Table Entries (Память: Свободных элементов таблицы страниц) в оснастке Performance. По умолчанию Windows при загрузке подсчитывает, сколько системных PTE нужно создать, исходя из объема доступной памяти. Чтобы изменить это число, присвойте параметру реестра HKLM\SYSTEM\Current-ControlSet\Control\Session Manager\Memory Management\SystemPages значение, равное нужному вам количеству РТЕ. (Это может понадобиться для поддержки устройств, требующих большого количества системных РТЕ, например видеоплат с 512 Мб видеопамяти, которую нужно спроецировать всю сразу.) Если параметр содержит значение 0xFFFFFFFF, резервируется максимальное число системных РТЕ.

Структуры 64-разрядных адресных пространств

Теоретически 64-разрядное виртуальное адресное пространство может быть до 16 экзабайтов (18 446 744 073 709 551 6l6 байтов, или примерно 17,2 миллиарда гигабайтов). B отличие от 32-разрядного адресного пространства на платформ x86, где по умолчанию оно делится на две равные части (половина для процесса и половина для системы), 64-разрядное адресное пространство делится на ряд регионов разного размера, компоненты которого концептуально совпадают с порциями пользовательского, системного и сеансового пространств. Размер этих регионов (таблица 7-10) отражает лимиты текущей реализации, которые могут быть расширены в будущих выпусках.

Детальные структуры адресных пространств IA64 и x64 различаются незначительно. Структуру адресного пространства для IA64 см. на рис. 7-13, а для x64 — на рис. 7-14.

Трансляция адресов

Теперь, когда вы познакомились со структурами виртуального адресного пространства в Windows, рассмотрим, как она увязывает эти адресные пространства со страницами физической памяти (приложения и системный код используют виртуальные адреса). Мы начнем с детального описания трансляции 32-разрядных адресов на платформе x86, потом кратко поясним ее отличия на 64-разрядных платформах IA64 и x64. B следующем разделе вы узнаете, что происходит, когда виртуальный адрес не удается разрешить в физический (из-за выгрузки в страничный файл), и как Windows управляет физической памятью через рабочие наборы и базу данных номеров фреймов страниц.

Трансляция виртуальных адресов на платформе x86

C помощью структур данных (таблиц страниц), создаваемых и поддерживаемых диспетчером памяти, процессор транслирует виртуальные адреса в физические. Каждый виртуальный адрес сопоставлен со структурой системного пространства, которая называется элементом таблицы страниц (page table entry, PTE) и содержит физический адрес, соответствующий виртуальному. Например, на рис. 7-15 показаны три последовательно расположенные виртуальные страницы, проецируемые на три разрозненные физические страницы (платформа x86).

Пунктирные линии на рис. 7-15 соединяют виртуальные страницы с РТЕ, представляя косвенные связи между виртуальными и физическими страницами.

ПРИМЕЧАНИЕ Код режима ядра (например, драйверов устройств) может ссылаться на физические адреса, транслируя их в виртуальные. Подробнее об этом см. описание функций поддержки списка дескрипторов памяти (memory descriptor list, MDL) в DDK.

По умолчанию в х86-системе Windows для трансляции виртуальных адресов в физические использует двухуровневую таблицу страниц (х86-систе-мы, работающие с РАЕ-версией ядра, используют трехуровневую таблицу страниц, но они в этом разделе не рассматриваются). 32-разрядный виртуальный адрес интерпретируется как совокупность трех элементов: индекса каталога страниц, индекса таблицы страниц и индекса байта. Они применяются в качестве указателей в структурах, описывающих проекции страниц (рис. 7-l6). Размеры страницы и PTE определяет размеры каталога страниц и полей индекса таблицы страниц. Так, в х86-системах длина индекса байта составляет 12 битов, поскольку размер страницы равен 4096 байтов (т. е. 2¹²).

Индекс каталога страниц (page directory index) применяется для поиска таблицы страниц, содержащей PTE для данного виртуального адреса. C помощью индекса таблицы страниц (page table index) осуществляется поиск РТЕ, который, как уже говорилось, содержит физический адрес, по которому проецируется виртуальная страница. Индекс байта (byte index) позволяет найти конкретный адрес на физической странице. Взаимосвязи этих трех величин и их использование для трансляции виртуальных адресов в физические показаны на рис. 7-17.

При трансляции виртуального адреса выполняются следующие операции.

1. Аппаратные средства управления памятью находят каталог страниц текущего процесса. При каждом переключении контекста процесса эти средства получают адрес каталога страниц нового процесса. Обычно операционная система записывает этот адрес в специальный регистр процессора.

2. Индекс каталога страниц используется как указатель для поиска элемента каталога страниц (page directory entry, PDE), который определяет местонахождение таблицы страниц, нужной для трансляции виртуального адреса. PDE содержит номер фрейма страницы (page frame number, PFN) таблицы страниц (если она находится в памяти; однако такие таблицы могут выгружаться в страничный файл).

3. Индекс таблицы страниц используется как указатель для поиска PTE₅ который определяет местонахождение требуемой виртуальной страницы.

4. Ha основе PTE отыскивается страница. Если она действительна, то содержит PFN соответствующей страницы физической памяти. Если PTE сообщает, что страница недействительна, обработчик ошибок подсистемы управления памятью пытается найти страницу и сделать ее действительной (см. раздел по обработке ошибок страниц далее в этой главе). Если сделать страницу действительной не удалось (например, из-за ошибки защиты), обработчик ошибок генерирует нарушение доступа или вызывает переход в состояние отладки.

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

Каталоги страниц

У каждого процесса есть один каталог страниц (page directory), который представляет собой страницу с адресами всех таблиц страниц для данного процесса. Физический адрес каталога страниц процесса хранится в блоке KPROCESS и проецируется по адресу 0xC0300000 в х86-системах или 0xC0600000 в системах с РАЕ-ядром. Весь код, выполняемый в режиме ядра, использует не физические, а виртуальные адреса (о KPROCESS см. главу 6).

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

Каталог страниц состоит из элементов (PDE), каждый из которых имеет длину 4 байта (в системах с РАЕ-ядром — 8 байтов) и описывает состояние и адреса всех возможных таблиц страниц для данного процесса. (Как будет сказано далее, таблицы страниц создаются по мере необходимости, так что каталоги страниц большинства процессов ссылаются лишь на небольшой набор таких таблиц.) Мы не будем отдельно рассматривать формат PDE, поскольку он в основном совпадает с форматом аппаратного РТЕ.

B х86-системах без PAE для полного описания 4-гигабайтного виртуального адресного пространства требуется 1024 таблицы страниц. Каталог страниц процесса, связывающий эти таблицы, содержит 1024 PDE. Соответственно размер индекса каталога равен 10 битам (2¹⁰ = 1024). B х86-систе-мах, работающих в режиме РАЕ, в таблице страниц 512 элементов (размер индекса каталога страниц равен 9 битам). Из-за наличия 4 каталогов страниц максимальное число таблиц страниц составляет 2048.

ЭКСПЕРИМЕНТ: исследуем каталог страниц и PDE

Физический адрес каталога страниц текущего процесса можно увидеть, изучив поле DirBase в выходной информации команды !process отладчика ядра.

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

Часть выходной информации отладчика ядра, касающаяся РТЕ, рассматривается в разделе «Страницы таблиц и РТЕ» далее в этой главе.

Поскольку Windows предоставляет каждому процессу закрытое адресное пространство, у каждого процесса свой набор таблиц страниц для проецирования этого пространства. B то же время таблицы страниц, описывающие системное пространство, разделяются всеми процессами (а пространство сеанса разделяется процессами в сеансе). Чтобы не допустить появления нескольких таблиц страниц, описывающих одну и ту же виртуальную память, при создании процесса PDE, описывающие системное пространство, инициализируются так, чтобы они указывали на существующие системные таблицы страниц. Если процесс является частью сеанса, таблицы страниц, описывающие пространство сеанса, тоже используются совместно. Для этого PDE пространства сеанса инициализируются так, чтобы они указывали на существующие сеансовые таблицы страниц.

Однако, как показано на рис. 7-18, не все процессы имеют одинаковое представление системного пространства. Так, если при расширении пула подкачиваемой памяти требуется создать новую системную таблицу страниц, диспетчер памяти — вместо того чтобы сразу записывать указатели на новую системную таблицу во все каталоги страниц процессов — обновляет эти каталоги только по мере обращения процессов по новому виртуальному адресу.

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

Страницы таблиц и PTE

Элементы каталога страниц (page directory entries, PDE), принадлежащего процессу, указывают на индивидуальные таблицы страниц, которые состоят из массива РТЕ. Поле индекса таблицы страницы в виртуальном адресе (как показано на рис. 7-17) определяет PTE нужной страницы данных. B x86-системах размер этого индекса равен 10 битам (в PAE — 9), что позволяет ссылаться на 1024 4-байтных PTE (в PAE — на 512 8-байтных PTE). Ho, поскольку 32-разрядная Windows предоставляет процессам 4-гигабайтное закрытое адресное пространство, для проецирования всего адресного пространства одной таблицы страниц мало. Чтобы подсчитать количество таблиц страниц, нужных для проецирования всех 4 Гб виртуального адресного пространства, поделите 4 Гб на объем виртуальной памяти, описываемой одной таблицей. Помните, что каждая таблица страниц в х86-системах определяет страницы данных суммарным размером в 4 Мб (в PAE — 2 Мб). Поэтому для проецирования всех 4 Гб адресного пространства требуется 1024 (4 Гб / 4 Мб) таблицы страниц, а в РАЕ-системах — 2048 (4 Гб / 2 Мб).

Для изучения PTE используйте команду !pte отладчика ядра (см. эксперимент «Трансляция адресов» далее в этой главе). Действительные PTE (здесь мы обсуждаем именно их — о недействительных PTE см. далее) состоят из двух основных полей (рис. 7-19): поля PFN физической страницы с данными (или физического адреса страницы в памяти) и поля флагов, описывающих состояние и атрибуты защиты страницы.

Как вы еще увидите, битовые флаги, помеченные как зарезервированные рис. 7-19), используются, только если PTE недействителен (флаги интерпретируются программно). Аппаратно определяемые битовые флаги действительного PTE перечислены в таблице 7-11.

B х86-системах аппаратный PTE содержит биты Dirty и Accessed. Бит Accessed равен 0, если данные физической страницы, представляемой РТЕ, не были считаны или записаны. Процессор устанавливает этот бит при первой операции чтения или записи страницы. Бит Dirty устанавливается только после первой записи на страницу. Кроме того, бит Write обеспечивает защиту страницы: если он сброшен, страница доступна только для чтения, а если он установлен, страница доступна как для чтения, так и для записи. Когда поток пытается что-то записать на страницу со сброшенным битом Write, возникает исключение управления памятью, и обработчик, принадлежащий диспетчеру памяти, решает, может ли поток записывать данные на эту страницу (если она, например, помечена как копируемая при записи) или следует сгенерировать нарушение доступа.

Для аппаратных PTE в многопроцессорных х86-системах предусматривается дополнительный бит Write, реализуемый программно и предотвращающий остановку системы при сбросе кэша PTE (также называемого ассоциативным буфером трансляции). Этот бит указывает, что страница была модифицирована другим процессором.

Адрес байта в пределах страницы

Как только диспетчер памяти находит искомую страницу, он переходит к поиску нужных данных на этой странице. Ha этом этапе используется поле индекса байта. Оно сообщает процессору, к какому байту данных на этой странице вы хотите обратиться. B х86-системах этот индекс состоит из 12 битов, что позволяет адресоваться максимум к 4096 байтам данных. Таким образом, добавление смещения байта к PFN, извлеченному из РТЕ, завершает трансляцию виртуального адреса в физический.

ЭКСПЕРИМЕНТ: трансляция адресов

Чтобы получше разобраться в том, как транслируются адреса, рассмотрим реальный пример трансляции виртуального адреса в х86-систе-ме без поддержки PAE и с помощью отладчика ядра исследуем каталоги страниц, таблицы страниц и PTE. B этом примере мы используем процесс с виртуальным адресом 0x50001, спроецированным на действительный физический адрес. Как наблюдать за трансляцией недействительных адресов, мы поясним в последующих примерах.

Сначала преобразуем 0x50001 в двоичное значение и разобьем его на три поля, используемых при трансляции адреса. B двоичной системе счисления 0x50001 соответствует значению 101.0000.0000.0000.0001, а его поля выглядят так:

Чтобы начать трансляцию, процессор должен знать физический адрес каталога страниц, который хранится в регистре CR3, пока выполняется поток соответствующего процесса. Этот адрес можно получить как из регистра CR3, так и из дампа блока KPROCESS интересующего вас процесса с помощью команды !process отладчика ядра.

B данном случае физический адрес каталога страниц — 0xl2F0000. Как видно на иллюстрации, поле индекса каталога страниц в этом примере равно 0. Поэтому физический адрес PDE — 0x12F0000.

Команда !pte отладчика ядра выводит PDE и РТЕ, описывающие виртуальный адрес:

B первой колонке отладчик ядра сообщает PDE₅ а во второй — РТЕ. Заметьте, что показывается виртуальный адрес PDE, а не физический. Как уже говорилось, каталог страниц процесса в х86-системах начинается с виртуального адреса 0xC0300000. Поскольку мы изучаем первый PDE каталога страниц, его адрес совпадает с адресом самого каталога.

Виртуальный адрес PTE равен 0xC0000140. Его можно вычислить, умножив индекс таблицы страниц (в данном случае — 0x50) на размер PTE (4), что дает 0x140. Поскольку диспетчер памяти проецирует таблицы страниц с адреса 0xC0000000, после добавления 140 получится виртуальный адрес, показанный на листинге: 0xC0000140. PFN страницы в каталоге страниц равен 0x700, a PFN страницы данных — 0xe63.

Флаги PTE показываются справа от PFN. Так, РТЕ, описывающий упомянутую выше страницу, имеет флаги D — UWV, где D обозначает dirty (данные страницы изменены), U — user-mode page (страница пользовательского режима), a V- valid (действительная страница).

Ассоциативный буфер трансляции

Как вы уже знаете, трансляция каждого адреса требует двух операций поиска: сначала нужно найти подходящую таблицу страниц в каталоге страниц, затем — элемент в этой таблице. Поскольку выполнение этих двух операций при каждом обращении по виртуальному адресу могло бы снизить быстродействие системы до неприемлемого уровня, большинство процессоров кэшируют транслируемые адреса, в результате чего необходимость в повторной трансляции при обращении к тем же адресам отпадает. Процессор поддерживает такой кэш в виде массива ассоциативной памяти, называемого ассоциативным буфером трансляции (translation look-aside buffer, TLB). Ассоциативная память вроде TLB представляет собой вектор, ячейки которого можно считывать и сразу сравнивать с целевым значением. B случае TLB вектор содержит сопоставления физических и виртуальных адресов для недавно использовавшихся страниц, а также атрибуты защиты каждой страницы, как показано на рис. 7-20. Каждый элемент TLB похож на элемент кэша, в метке которого хранятся компоненты виртуального адреса, а в поле данных — номер физической страницы, атрибуты защиты, битовый флаг Valid и, как правило, битовый флаг Dirty. Эти флаги отражают состояние страницы, которой соответствует кэшированный РТЕ. Если в PTE установлен битовый флаг Global (используется для страниц системного пространства, глобально видимых всем процессам), то при переключениях контекста элемент TLB не объявляется недействительным.

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

Диспетчер памяти по возможности обрабатывает аппаратные и программные PTE одинаково. Так, при объявлении недействительного PTE действительным диспетчер памяти вызывает функцию ядра, которая обеспечивает аппаратно-независимую загрузку в TLB нового PTE. B х86-системах эта функция заменяется командой NOP, поскольку процессоры типа x86 самостоятельно загружают данные в TLB.

Physical Address Extension (PAE)

Режим проецирования памяти Physical Address Extension (PAE) впервые появился в х86-процессорах Intel Pentium Pro. При наличии соответствующей поддержки со стороны чипсета в режиме PAE можно адресоваться максимум к 64 Гб физической памяти на текущих х86-процессорах Intel и к 1024 Гб на х64-процессорах (хотя в настоящее время Windows ограничивает этот показатель 128 Гб из-за размера базы данных PFN, которая понадобилась бы для проецирования такого большого объема памяти). При работе процессора в режиме PAE блок управления памятью (memory management unit, MMU) разделяет виртуальные адреса на 4 поля (рис. 7-21).

При этом MMU по-прежнему реализует каталоги и таблицы страниц, но создает над ними третий уровень — таблицу указателей на каталоги страниц. РАЕ-режим позволяет адресовать больше памяти, чем стандартный, — но не из-за дополнительного уровня трансляции, а из-за большего размера PDE и PTE (по 64 бита вместо 32). Внутренне система представляет физический адрес 25 битами, что позволяет поддерживать максимум 2²⁵⁺¹² байтов, или 128 Гб, памяти. Для 32-разрядных приложений один из способов использования конфигураций с такими большими объемами памяти был представлен в разделе «Address Windowing Extensions» ранее в этой главе. Ho, даже если приложения не обращаются к таким функциям, диспетчер памяти все равно задействует всю доступную физическую память под данные файлового кэша (см. раздел «База данных PFN» далее в этой главе).

Как мы поясняли в главе 2, существует специальная версия 32-разрядного ядра с поддержкой PAE — Ntkrnlpa.exe. Для загрузки этой версии ядра укажите в Boot.ini параметр /РАЕ. Заметьте, что она устанавливается во всех 32-разрядных системах Windows, даже в системах Windows 2000 Professional или Windows XP с малой памятью. Цель — упростить тестирование драйверов устройств. Поскольку в РАЕ-ядре драйверы устройств и другой системный код используют 64-разрядные адреса, загрузка с параметром /РАЕ позволяет разработчикам тестировать свои драйверы на совместимость с системами, имеющими большие объемы памяти. Кстати, в связи с этим Boot.ini поддерживает еще один параметр — /NOLOWMEM, который запрещает использовать первые 4 Гб памяти (предполагается, что на компьютере установлено минимум 5 Гб физической памяти) и модифицирует адреса драйверов устройств для размещения выше этой границы, что гарантирует выход физических адресов драйверов за пределы 32-разрядных значений.

Трансляция виртуальных адресов на платформе IA64

Виртуальное адресное пространство на платформе IA64 аппаратно делится на восемь регионов. У каждого региона свой набор таблиц страниц. Windows использует только пять регионов, закрепляя таблицы страниц за тремя из них. Все регионы перечислены в таблице 7-12.

При трансляции адресов 64-разряднои Windows на платформе IA64 используется трехуровневая схема таблиц страниц. Каждый процесс получает специальную структуру, содержащую 1024 указателя на каталоги страниц. Каждый каталог страниц содержит 1024 указателя на таблицы страниц, а те в свою очередь указывают на страницы физической памяти. Формат аппаратных PTE на платформе IA64 показан на рис. 7-22.

Трансляция виртуальных адресов на платформе x64

64-разрядная Windows на платформе х64 применяет четырехуровневую cxe-мутаблиц страниц. У каждого процесса имеется расширенный каталог страниц верхнего уровня (называемый картой страниц уровня 4), содержащий 512 указателей на структуру третьего уровня — родительский каталог страниц. Каждый родительский каталог страниц хранит 512 указателей на каталоги страниц второго уровня, а те содержат по 512 указателей на индивидуальные таблицы страниц. Наконец, таблицы страниц (в каждой из которых 512 PTE) указывают на страницы в памяти. B текущих реализациях архитектуры x64 размер виртуальных адресов ограничен 48 битами. Элементы 48-битного виртуального адреса представлены на рис. 7-23. Взаимосвязь между этими элементами показана на рис. 7-24, а формат аппаратного PTE на платформе x64 приведен на рис. 7-25.

Обработка ошибок страниц

Мы уже разобрались, как происходит трансляция адресов при действительных РТЕ. Если битовый флаг Valid в PTE сброшен, это значит, что нужная страница по какой-либо причине сейчас недоступна процессу. Здесь мы расскажем о типах недействительных PTE и о том, как разрешаются ссылки на такие РТЕ.

ПРИМЕЧАНИЕ B этой книге детально рассматриваются только PTE на 32-разрядной платформе x86. PTE для 64-разрядных систем содержат аналогичную информацию, но их подробную структуру мы не описываем.

При ссылке на недействительную страницу возникает ошибка страницы (page fault), и обработчик ловушки ядра (см. главу 3) перенаправляет ее обработчику MmAccessFault диспетчера памяти. Последняя функция, выполняемая в контексте вызвавшего ошибку потока, предпринимает попытку ее разрешения (если это возможно) или генерирует соответствующее исключение. Причины таких ошибок перечислены в таблице 7-13.

B следующем разделе описываются четыре базовых типа недействительных РТЕ. Затем мы рассмотрим особый случай недействительных PTE — прототипные РТЕ, используемые для поддержки разделяемых страниц.

Недействительные PTE

Ниже приведен список типов недействительных PTE с описанием их структуры. Некоторые их флаги идентичны флагам аппаратных PTE (см. таблицу 7-11).

• PTE для страницы в страничном файле (page file PTE) Нужная страница находится в страничном файле. Инициируется операция загрузки страницы.

• PTE для страницы, обнуляемой по требованию (demand zero PTE)

Нужная страница должна быть заполнена нулями. Сначала просматривается список обнуленных страниц (zero page list). Если он пуст, просматривается список свободных страниц (free list). Если в нем есть свободная страница, она заполняется нулями. Если этот список тоже пуст, используется список простаивающих страниц (stanby list). Формат этого PTE идентичен формату PTE для страницы в страничном файле, но номер страничного файла и смещение в нем равны 0.

• Переходный PTE (transition PTE) Нужная страница находится в памяти в списке простаивающих, модифицированных (modified list) или модифицированных, но не записываемых страниц (modified-no-write list). Страница будет удалена из списка и добавлена в рабочий набор, как только на нее будет ссылка.

• Неизвестный PTE (unknown PTE) PTE равен 0, либо таблицы страниц еще нет. B обоих случаях этот флаг означает, что определить, передана ли память по данному адресу, можно только через дескрипторы виртуальных адресов (VAD). Если передана, то формируются таблицы страниц, представляющие новую область адресного пространства, которому передана физическая память. (Описание VAD см. в разделе «Дескрипторы виртуальных адресов» далее в этой главе.)

Прототипные PTE

Если какая-то страница может разделяться двумя процессами, то при проецировании таких потенциально разделяемых страниц диспетчер памяти использует структуру, называемую прототипным PTE (prototype page table entry). B случае разделов, поддерживаемых страничными файлами (page file backed sections), массив прототипных PTE формируется при первом создании объекта «раздел», а в случае проецируемых файлов этот массив создается порциями при проецировании каждого представления. Прототипные PTE являются частью структуры сегмента, описываемой в конце этой главы.

ПРИМЕЧАНИЕ B Windows 2000 и Windows 2000 Service Pack 1 диспетчер памяти создает все прототипные РТЕ, нужные для проецирования всего файла, даже если приложение единовременно проецирует представления лишь на небольшие части файла. Поскольку эти структуры создаются в конечном ресурсе (в пуле подкачиваемой памяти), попытка спроецировать большие файлы может привести к истощению этого ресурса. B итоге предельный общий объем единовременно используемых проецируемых файлов составляет около 200 Гб.

Этот лимит снят в Windows 2000 Service Pack 2 и более поздних версиях за счет того, что диспетчер памяти теперь создает такие структуры только при создании проецируемых на файл представлений. Благодаря этому стало возможным резервное копирование огромных файлов даже на компьютерах с малым объемом памяти.

Когда процесс впервые ссылается на страницу, проецируемую на представление объекта «раздел» (вспомните, что VAD создаются только при проецировании представления), диспетчер памяти — на основе информации из прототипного PTE — заполняет реальный РТЕ, используемый для трансляции адресов в таблице страниц процесса. Когда разделяемая страница становится действительной, PTE процесса и прототипный PTE указывают на физическую страницу с данными. Для учета числа РТЕ, ссылающихся на действительные разделяемые страницы, в базе данных PFN увеличивается значение соответствующего счетчика (см. раздел «База данных PFN» далее в этой главе). Благодаря этому диспетчер памяти сможет определить тот момент, когда на разделяемую страницу больше не будет ссылок ни в одной таблице страниц, а затем объявить ее недействительной и поместить в список переходных страниц или выгрузить на диск.

Как только разделяемая страница объявлена недействительной, PTE в таблице страниц процесса заменяется особым РТЕ, указывающим на прототипный РТЕ, который описывает данную страницу (рис. 7-26).

Рис. 7-26. Структура недействительного РТЕ, указывающего на прототипный PTE

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

• Активная/действительная (active/valid) Страница находится в физической памяти в результате обращения к ней другого процесса.

• Переходная (transition) Страница находится в памяти в списке простаивающих или модифицированных страниц.

• Модифицированная, но не записываемая (modified-no-write) Страница находится в памяти в списке модифицированных, но не записываемых страниц (см. таблицу 7-20).

• Обнуляемая по требованию (demand zero) Страницу требуется обнулить (заполнить нулями).

• Выгруженная в страничный файл (page file) Страница находится в страничном файле.

• Содержащаяся в проецируемом файле (mapped file) Страница находится в проецируемом файле.

Хотя формат прототипных PTE идентичен формату реальных РТЕ, они используются не для трансляции адресов, а как уровень между таблицей страниц и базой данных PFN и никогда не записываются непосредственно в таблицы страниц.

Заставляя всех пользователей потенциально разделяемой страницы ссылаться на прототипный РТЕ, диспетчер памяти может управлять разделяемыми страницами, не обновляя таблицы страниц в каждом процессе. Допустим, в какой-то момент разделяемая страница выгружается в страничный файл на диске. При ее загрузке обратно в память диспетчеру памяти понадобится изменить только прототипный РТЕ, записав в него указатель на новый физический адрес страницы, a PTE в таблицах страниц всех процессов, совместно использующих эту страницу, останутся прежними (в этих PTE битовый флаг Valid сброшен, они ссылаются на прототипный РТЕ). Реальные PTE обновляются позднее, по мере обращения процессов к этой странице.

Ha рис. 7-27 показаны две виртуальные страницы в проецируемом представлении. Одна из них действительна, другая — нет. Как видите, на действительную страницу ссылаются PTE процесса и прототипный РТЕ. Недействительная страница находится в страничном файле, ее точный адрес определяется прототипным PTE. PTE данного процесса (как и любого другого процесса, проецирующего эту страницу) содержит указатель на прототипный РТЕ.

Операции ввода-вывода, связанные с подкачкой страниц

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

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

B ходе операции ввода-вывода, связанной с подкачкой, поток, который вызвал ошибку страницы, не владеет критичными синхронизирующими объектами, используемыми при управлении памятью. Другие потоки того же процесса могут вызывать функции управления виртуальной памятью и обрабатывать ошибки страниц в ходе операции ввода-вывода, связанной с подкачкой. Однако подсистема подкачки страниц должна уметь выходить из некоторых ситуаций, которые могут возникать на момент завершения такой операции:

• другой поток в том же или другом процессе вызывает ошибку той же страницы, из-за чего происходит конфликт ошибок страницы (см. следующий раздел);

• страница удалена из виртуального адресного пространства и перепроецирована;

• сменился атрибут защиты страницы;

• ошибка относится к прототипному РТЕ, а страница, которая проецирует этот РТЕ, отсутствует в рабочем наборе.

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

Конфликты ошибок страницы

Конфликт ошибок страницы (collided page fault) возникает, когда другой поток или процесс вызывает ошибку страницы, уже обрабатываемой в данный момент из-за предыдущей ошибки того же типа. Подсистема подкачки страниц распознает и оптимальным образом разрешает такие конфликты, поскольку они нередки в системах с поддержкой многопоточности. Если другой поток или процесс вызывает ошибку той же страницы, подсистема подкачки страниц обнаруживает конфликт ошибок страницы, отмечая при этом, что страница находится в переходном состоянии и что она сейчас считывается. (Эта информация извлекается из элемента базы данных PFN.) Далее подсистема подкачки страниц переходит в ожидание на событии, указанном в элементе базы данных PFN. Это событие было инициализировано потоком, вызвавшим первую ошибку страницы.

По завершении операции ввода-вывода событие переходит в свободное состояние. Первый поток, захвативший блокировку базы данных PFN, отвечает за заключительные операции, связанные с подкачкой. K ним относятся проверка статуса операции ввода-вывода (чтобы убедиться в ее успешном завершении), сброс бита «в процессе чтения» в базе данных PFN и обновление РТЕ.

Когда следующие потоки захватывают блокировку базы данных PFN для завершения обработки конфликтующих ошибок страницы, сброшенный бит «в процессе чтения» сообщает подсистеме подкачки страниц, что начальное обновление закончено, и она проверяет флаг ошибок в элементе базы данных PFN. Если этот флаг установлен, PTE не обновляется, и в потоке, вызвавшем ошибку страницы, генерируется исключение «in-page error» (ошибка в процессе загрузки страницы).

Страничные файлы

Страничные файлы (page files) предназначены для хранения модифицированных страниц, которые используются каким-то процессом, но должны быть выгружены из памяти на диск. Пространство в страничном файле резервируется, когда происходит начальная передача страниц, но реальные участки страничного файла не выбираются до тех пор, пока страницы не выгружаются на диск. Важно отметить, что система накладывает ограничение на число передаваемых закрытых страниц. Поэтому значение счетчика производительности Process: Page File Bytes на самом деле отражает суммарный объем закрытой памяти, переданной процессам. Соответствующие страницы могут находиться в страничном файле (частично или целиком) или, напротив, в физической памяти. (B сущности этот счетчик идентичен счетчику Process: Private Bytes.)

Диспетчер памяти отслеживает использование закрытой переданной памяти на глобальном уровне и по каждому процессу отдельно (в виде квоты страничного файла). И вновь эти данные отражают не размер использованного пространства в страничном файле, а объем переданной закрытой памяти. Соответствующие счетчики увеличиваются при передаче виртуальных адресов, требующих новых закрытых физических страниц. Как только система достигнет глобального лимита на переданную память (т. е. физическая память и страничные файлы заполнены), попытки выделения виртуальной памяти будут заканчиваться неудачно — пока какой-либо процесс не освободит переданную ему память (например, после завершения).

При загрузке системы процесс диспетчера сеансов (см. главу 4) считывает список страничных файлов, которые он должен открыть. Этот список хранится в параметре реестра HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PagingFiles. Этот многострочный параметр содержит имя, минимальный и максимальный размеры каждого страничного файла. Windows поддерживает до 16 страничных файлов. B х86-системах с обычным ядром каждый страничный файл может быть размером до 4095 Мб, в x64- и х86-системах с РАЕ-ядром — до 16 Тб, а в IА64-системах — до 32 Тб. Страничные файлы нельзя удалить во время работы системы, так как процесс System (см. главу 2) открывает описатель каждого страничного файла. Тот факт, что страничные файлы открываются системой, объясняет, почему встроенное средство дефрагментации не в состоянии дефрагментировать страничный файл в процессе работы системы. Для дефрагментации страничного файла используйте бесплатную утилиту Pagedefrag. B ней применяется тот же подход, что и в других сторонних утилитах дефрагментации: она запускает свой процесс дефрагментации на самом раннем этапе загрузки системы, еще до открытия страничных файлов диспетчером сеансов.

Поскольку страничный файл содержит части виртуальной памяти процессов и ядра, для большей безопасности его можно настроить на очистку при выключении системы. Для этого установите параметр реестра HKLM\SYSTEM \CurrentControlSet\Control\Session Manager\Memory Management\ClearPageFile-AtShutdown в 1. Иначе в страничном файле останутся те данные, которые были выгружены в него к моменту выключения системы. И к этим данным сможет обратиться любой, кто получит физический доступ к компьютеру.

Если не указано ни одного страничного файла, Windows 2000 создает в загрузочном разделе 20-мегабайтный страничный файл. Windows XP и Windows Server 2003 не создают этот временный страничный файл, и поэтому в такой ситуации объем системной виртуальной памяти будет ограничен доступной физической памятью. Windows XP и Windows Server 2003, если минимальный и максимальный размеры страничного файла заданы нулевыми, считают, что этот файл управляется системой, и его размер выбирается в соответствии с данными, показанными в таблице 7-14.

ЭКСПЕРИМЕНТ: просмотр страничных файлов

Как уже говорилось, список страничных файлов хранится в параметре реестра HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\ Memory Management\PagingFiles. Он содержит конфигурационные параметры страничных файлов, которые модифицируются через апплет System (Система) в Control Panel (Панель управления). B Windows 2000 щелкните кнопку Performance Options (Параметры быстродействия) на вкладке Advanced (Дополнительно) и нажмите кнопку Change (Изменить). B Windows XP и Windows Server 2003 откройте вкладку Advanced (Дополнительно), щелкните кнопку Settings (Параметры) в разделе Performance (Быстродействие), откройте еще одну вкладку Advanced (Дополнительно) и, наконец, нажмите кнопку Change (Изменить) в разделе Virtual Memory (Виртуальная память).

Создать новый страничный файл можно через Control Panel. При этом вызывается системный сервис NtCreatePagingFile, определенный в Ntdll.dll и предназначенный только для внутреннего использования. Страничные файлы всегда создаются несжатыми, даже если находятся в сжатом каталоге. Для защиты новых страничных файлов от удаления их описатели дублируются в процесс System.

B таблице 7-15 перечислены счетчики производительности, с помощью которых можно исследовать использование переданной закрытой памяти в рамках как всей системы, так и каждого страничного файла. K сожалению, определить соотношение резидентной и нерезидентной (находящейся в страничном файле) частей закрытой памяти, которая передана какому-либо процессу, нельзя.

Заметьте, что эти счетчики могут помочь в подборе размера страничного файла. Исходить из объема оперативной памяти (RAM) нет смысла: чем больше у вас памяти, тем меньше вероятность того, что вам понадобится выгрузка данных на диск. Чтобы определить, какой размер страничного файла действительно нужен в вашей системе с учетом используемых вами приложений, проверьте пиковое значение переданной памяти, которое отображается в разделе Commit Charge (Выделение памяти) на вкладке Performance

(Быстродействие) диспетчера задач, а также в окне System Information утилиты Process Explorer. Этот показатель отражает пиковый объем страничного файла с момента загрузки системы, который понадобился бы в том случае, если бы системе пришлось выгрузить всю закрытую переданную виртуальную память (что происходит крайне редко).

Если страничный файл в вашей системе слишком велик, Windows не будет использовать лишнее пространство; иначе говоря, увеличение размера страничного файла не изменит производительность системы — просто у нее будет больше неразделяемой (non-shareable) переданной виртуальной памяти. Ho если страничный файл слишком мал для запускаемого вами набора приложений, может появиться сообщение об ошибке «system running low on virtual memory» (в системе не хватает виртуальной памяти). B таком случае сначала проверьте, не дает ли какой-нибудь процесс утечки памяти. Для этого посмотрите на счетчики байтов закрытой памяти для процессов в столбце VM Size (Объем виртуальной памяти) на вкладке Processes (Процессы) диспетчера задач. Если ни один из процессов вроде бы не дает утечки памяти, проделайте операции, описанные в эксперименте «Анализ утечки памяти в пуле» ранее в этой главе.

ЭКСПЕРИМЕНТ: наблюдаем за использованием страничного файла через диспетчер задач

Вы можете узнать, как используется переданная память, и с помощью Task Manager (Диспетчер задач), открыв в нем вкладку Performance (Быстродействие). При этом вы увидите следующие счетчики, связанные со страничными файлами.

Заметьте, что график Mem Usage, который в Windows XP и Windows Server 2003 называется PF Usage (Файл подкачки), на самом деле соответствует общему объему переданной системной памяти (system commit total). Это значение отражает потенциально возможное, а не реальное использование страничного файла. Как мы уже говорили, столько места в страничном файле понадобилось бы в том случае, если бы системе вдруг пришлось выгрузить сразу всю закрытую переданную виртуальную память.

Дополнительную информацию вы найдете в окне System Information утилиты Process Explorer.

Дескрипторы виртуальных адресов

Момент загрузки страниц в память диспетчер памяти определяет, используя алгоритм подкачки по требованию (demand-paging algorithm). Страница загружается с диска, если поток, обращаясь к ней, вызывает ошибку страницы. Подобно копированию при записи подкачка по требованию является одной из форм отложенной оценки (lazy evaluation) — выполнения операции только при ее абсолютной необходимости.

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

При использовании алгоритма отложенной оценки выделение даже больших блоков памяти происходит очень быстро. Когда поток выделяет память, диспетчер памяти должен соответственно отреагировать. Для этого диспетчер памяти поддерживает набор структур данных, которые позволяют вести учет зарезервированных и свободных виртуальных адресов в адресном пространстве процесса. Эти структуры данных называются дескрипторами виртуальных адресов (virtual address descriptors, VAD). Для каждого процесса диспетчер памяти поддерживает свой набор VAD, описывающий состояние адресного пространства этого процесса. Для большей эффективности поиска VAD организованы в виде двоичного дерева с автоматической балансировкой. B Windows Server 2003 реализован алгоритм дерева AVL (это первые буквы фамилий его разработчиков — Adelson-Velskii и Landis), который обеспечивает более эффективную балансировку VAD-дерева, а это уменьшает среднее число операций сравнения при поиске VAD, соответствующего некоему виртуальному адресу. Схема дерева VAD показана на рис. 7-28.

Когда процесс резервирует адресное пространство или проецирует представление раздела, диспетчер памяти создает VAD для хранения информации из запроса на выделение — диапазона резервируемых адресов, его типа (разделяемый или закрытый), возможности наследования содержимого диапазона дочерними процессами, атрибутов защиты, установленных для страниц этого диапазона.

При первом обращении потока по какому-либо адресу диспетчер памяти должен создать PTE страницы, содержащей данный адрес. Для этого он находит VAD, чей диапазон включает нужный адрес, и использует его информацию для заполнения РТЕ. Если адрес выпадает из диапазонов VAD или находится в зарезервированном, но не переданном диапазоне адресов, диспетчер памяти узнает, что поток не выделил память до попытки ее использования, и генерирует нарушение доступа.

ЭКСПЕРИМЕНТ: просмотр дескрипторов виртуальных адресов

Чтобы просмотреть VAD для какого-либо процесса, используйте команду !vad отладчика ядра. Сначала найдите адрес корня VAD-дерева с помощью команды !process. Затем введите полученный адрес в команде !vad, как показано в примере для процесса, выполняющего Notepad.exe.

Объекты-разделы

Вероятно, вы помните, что объект «раздел» (section object), в подсистеме Windows называемый объектом «проекция файла» (file mapping object), представляет блок памяти, доступный двум и более процессам для совместного использования. Объект-раздел можно проецировать на страничный файл или другой файл на диске.

Исполнительная система использует разделы для загрузки исполняемых образов в память, а диспетчер кэша — для доступа к данным в кэшированном файле (подробнее на эту тему см. главу 11). Объекты «раздел» также позволяют проецировать файлы на адресные пространства процессов. При этом можно обращаться к файлу как к большому массиву, проецируя разные представления объекта-раздела и выполняя операции чтения-записи в памяти, а не в самом файле, — такие операции называются вводом-выводом в проецируемые файлы (mapped file I/O). Если программа обратится к недействительной странице (отсутствующей в физической памяти), возникнет ошибка страницы, и диспетчер памяти автоматически загрузит эту страницу в память из проецируемого файла. Если программа модифицирует страницу, диспетчер памяти сохранит изменения в файле в процессе обычных операций, связанных с подкачкой. (Приложение может самостоятельно сбросить представление файла на диск вызовом Windows-функции FlushViewOfFile)

Как и другие объекты, разделы создаются и уничтожаются диспетчером объектов. Он создает и инициализирует заголовок объекта «раздел», а диспетчер памяти определяет тело этого объекта. Диспетчер памяти также реализует сервисы, через которые потоки пользовательского режима могут получать и изменять атрибуты, хранящиеся в теле объекта «раздел». Структура объекта «раздел» показана на рис. 7-29.

Уникальные атрибуты, хранящиеся в объектах «раздел» перечислены в таблице 7-l6.

ЭКСПЕРИМЕНТ: просмотр объектов «раздел»

Утилита Object Viewer (Winobj.exe с сайта www.sysintemals.com или Winobj.exe из Platform SDK) позволяет просмотреть список разделов с глобальными именами. Вы можете перечислить открытые описатели объектов «раздел» с помощью любых утилит, описанных в разделе «Диспетчер объектов» главы 3 и способных перечислять содержимое таблицы открытых описателей. (Как уже говорилось в главе 3, эти имена хранятся в каталоге диспетчера объектов \BaseNamedObjects.)

Используя Process Explorer или Handles.exe (wwwsysintemats.com), либо утилиту Oh.exe (Open Handles) из ресурсов Windows, можно вывести список открытых описателей объектов «раздел». Например, следующая команда показывает все открытые описатели каждого объекта «раздел» независимо от того, есть ли у него имя. (Разделу должно быть присвоено имя, если другой процесс открывает его по имени.)

Для просмотра проецируемых файлов можно воспользоваться и утилитой Process Explorer. Выберите из меню View команду Lower Pane View, а затем DLLs. Файлы в колонке ММ, помеченные звездочкой, являются проецируемыми (в отличие от DLL и других файлов, загружаемых загрузчиком образов в виде модулей). Вот пример:

Структуры данных, поддерживаемые диспетчером памяти и описывающие проецируемые разделы, показаны на рис. 7-30. Эти структуры гарантируют согласованность данных, считанных из проецируемого файла, независимо от типа доступа.

Каждому открытому файлу, представленному объектом «файл», соответствует структура указателей объекта «раздел» (section object pointers structure). Эта структура является ключевой для поддержания согласованности данных при всех типах доступа к файлу; она же используется и при кэшировании файлов. Структура указателей объекта «раздел» ссылается на одну или две области управления (control areas). Одна из них используется для проецирования файла при обращении к нему как к файлу данных, а другая — для проецирования файла при запуске его как исполняемого образа.

Область управления в свою очередь указывает на структуры подраздела (subsection structures), содержащие информацию о проецировании каждого раздела файла (только для чтения, для чтения и записи, копирование при записи и т. д.). Область управления также ссылается на структуру сегмента (segment structure), которая создается в пуле подкачиваемой памяти и указывает на прототипные РТЕ, указывающие на реальные страницы, проецируемые объектом «раздел». Как уже говорилось, таблицы страниц процесса ссылаются на эти прототипные РТЕ, а те указывают на страницы, к которым происходит обращение.

Хотя Windows гарантирует, что любой процесс, обращающийся к файлу (для чтения или записи), всегда имеет дело с согласованными данными, возможна одна ситуация, при которой в физической памяти могут находиться две копии страниц файла (но и в этом случае предоставляется только самая последняя копия и поддерживается согласованность данных). Такое дублирование происходит из-за обращения к файлу образа как к файлу данных (для чтения или записи) с его последующим запуском как исполняемого файла. Например, при сборке и последующем запуске файла образа компоновщик открывает его для доступа к данным, а при запуске программы загрузчик образов проецирует этот файл как исполняемый. При этом выполняются следующие операции.

1. Если исполняемый образ был создан через API-функции проецирования файлов (или с помощью диспетчера кэша), создается и область управления для представления считываемых или записываемых страниц данных в этом файле.

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

3. Диспетчер памяти создает область управления кодом.

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

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

ЭКСПЕРИМЕНТ: просмотр областей управления

Чтобы найти адрес структур областей управления, вы должны сначала найти адрес нужного объекта «файл». Его можно получить с помощью отладчика ядра, создав командой !handle дамп таблицы описателей, принадлежащей процессу. Хотя команда !file отладчика ядра сообщает основные сведения об объекте «файл», она не дает указатель на структуру указателей объекта «раздел». Затем, используя команду dt, отформатируйте объект «файл», чтобы получить адрес структуры указателей объекта «раздел». Эта структура состоит из трех указателей: на область управления данными, на разделяемую проекцию кэша (см. главу 11) и на область управления кодом. Получив адрес нужной области управления (если она есть) из структуры указателей объекта «раздел», укажите его как аргумент в команде !ca.

Скажем, если вы откроете файл PowerPoint и выведете таблицу описателей для этого процесса командой !handle, то найдете открытый описатель файла PowerPoint, как показано ниже. (Об использовании команды !handle см. раздел «Диспетчер объектов» главы 3.)

Затем, сделав то же самое, но применительно к адресу структуры указателей объекта «раздел» (0x85512fec), вы получите:

Наконец, команда !ca покажет вам область управления по этому адресу:

Другой метод — применение команды !memusage. Ниже приведен фрагмент вывода этой команды.

Значения в колонке Control указывают на структуру области управления, описывающую проецируемый файл. Вы можете просмотреть области управления, сегменты и подразделы с помощью команды !ca отладчика ядра. Например, чтобы получить дамп области управления для проецируемого файла Winword.exe, введите команду !ca и укажите в ней число из колонки Control, как показано ниже.

Рабочие наборы

Здесь мы сосредоточимся на виртуальной части Windows-процесса — таблицах страниц, PTE и VAD. B оставшейся части главы мы расскажем, как Windows хранит в физической памяти подмножество виртуальных адресов.

Как вы помните, подмножество виртуальных страниц, резидентных в физической памяти, называется рабочим набором (working set). Существует три вида рабочих наборов:

• процесса — содержит страницы, на которые ссылаются его потоки;

• системы — содержит резидентное подмножество подкачиваемого системного кода (например, Ntoskrnl.exe и драйверов), пула подкачиваемой памяти и системного кэша;

• сеанса — в системах с включенной службой Terminal Services каждый сеанс получает свой рабочий набор. Он содержит резидентное подмножество специфичных для сеанса структур данных режима ядра, создаваемых частью подсистемы Windows, которая работает в режиме ядра (Win32k.sys), пула подкачиваемой памяти сеанса, представлений, проецируемых в сеансе, и других драйверов устройств, проецируемых на пространство сеанса. Прежде чем детально рассматривать каждый тип рабочего набора, обсудим общие правила выбора страниц, загружаемых в память, и определения срока их пребывания в физической памяти.

Подкачка по требованию

Диспетчер памяти Windows использует алгоритм подкачки по требованию с кластеризацией. Когда поток вызывает ошибку страницы, диспетчер памяти загружает не только страницу, при обращении к которой возникла ошибка, но и несколько предшествующих и/или последующих страниц. Эта стратегия обеспечивает минимизацию числа операций ввода-вывода, связанных с подкачкой. Поскольку программы (особенно большие) в любой момент времени обычно выполняются в небольших областях своего адресного пространства, загрузка виртуальных страниц кластерами уменьшает число операций чтения с диска. При ошибках, связанных со ссылками на страницы данных в образах, размер кластера равен 3, в остальных случаях — 7.

Однако политика подкачки по требованию может привести к тому, что какой-то процесс будет вызывать очень много ошибок страниц в момент начала выполнения его потоков или позднее при возобновлении их выполнения. Для оптимизации запуска процесса (и системы) в Windows XP и Windows Server 2003 введен механизм интеллектуальной предвыборки (intelligent prefetch engine), также называемый средством логической предвыборки (logical prefetcher); о нем мы рассказываем в следующем разделе.

Средство логической предвыборки

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

Средство предвыборки, впервые появившееся в Windows XP, пытается ускорить загрузку системы и запуск приложений, отслеживая данные и код, к которым происходит обращение при этих процессах, и используя полученную информацию при последующих загрузке системы и запуске приложений для заблаговременного считывания необходимых кода и данных. Когда средство предвыборки активно, диспетчер памяти уведомляет код средства предвыборки в ядре об ошибках страниц — как аппаратных (требующих чтения данных с диска), так и программных (требующих простого добавления данных, которые уже находятся в памяти, в рабочий набор процесса). Средство предвыборки ведет мониторинг первых 10 секунд процесса запуска приложения. B случае загрузки системы это средство по умолчанию ведет мониторинг в течение 30 секунд после запуска пользовательской оболочки (обычно Explorer), или 60 секунд по окончании инициализации всех Windows-сервисов, или просто в течение 120 секунд — в зависимости от того, какое из этих трех событий произойдет первым.

Собрав трассировочную информацию об ошибках страниц, организованную в виде списка обращений к файлу метаданных NTFS MFT (Master FiIe Table) (если приложение пыталось получить доступ к файлам или каталогам на NTFS-томах), а также списка ссылок на файлы и каталоги, код средства предвыборки, работающий в режиме ядра, уведомляет компонент предвыборки в службе Task Scheduler (Планировщик заданий) (\Windows\System32\Schedsvc.dll) и с этой целью переводит в свободное состояние объект-событие с именем PrefetchTracesReady.

ПРИМЕЧАНИЕ Включить или отключить предвыборку при загрузке системы и/или запуске приложений позволяет DWORD-параметр реестра HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnablePrefetcher: 0 — полное отключение предвыборки, 1 — предвыборка разрешена только при запуске приложений, 2 — предвыборка разрешена только при загрузке системы и 3 — предвыборка разрешена как при загрузке системы, так и при запуске приложений.

Когда событие PrefetchTracesReady переводится в свободное состояние, Task Scheduler вызывает внутрисистемную функцию NtQuerySystemInformation, запрашивая через нее трассировочные данные. После дополнительной обработки этих данных Task Scheduler записывает их в файл, помещаемый в каталог \Windows\Prefetch фис. 7-31). Файлу присваивается имя, формируемое из имени приложения, к которому относятся трассировочные данные, дефиса и шестнадцатеричного представления хэша, полученного из строки пути к файлу. Затем к имени добавляется расширение. pf. Например, для Notepad создается файл NOTEPAD.EXE-AF43252301.PF.

B этом правиле есть два исключения. Первое относится к образам, которые служат хостами других компонентов, в том числе к Microsoft Management Console (\Windows\System32\Mmc.exe) и Dllhost (\Windows\System32\ Dllhost.exe). Поскольку в командной строке запуска этих приложений указываются дополнительные компоненты, средство предвыборки включает командную строку в генерируемый хэш. Таким образом, запуск таких приложений с другими компонентами в командной строке даст другой набор трассировочных данных. Средство предвыборки считывает список исполняемых образов, которые оно должно обрабатывать таким способом, из параметра HostingAppList в разделе реестра HKLM\System\CurrentControlSet\ Control\Session Manager\Memory Management\PrefetchParameters.

Второе исключение составляет файл, в котором хранится трассировочная информация, полученная в процессе загрузки системы, — ему всегда присваивается имя NTOSBOOT-B00DFAAD.PF. Средство предвыборки собирает информацию об ошибках страниц для конкретных приложений только после того, как закончит мониторинг процесса загрузки системы.

ЭКСПЕРИМЕНТ: просмотр содержимого файла предвыборки

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

C: \Windows\Prefetch›Strings ntosboot-boodfaad.pf Strings v2.1

Copyright (C) 1999–2003 Mark Russinovich Systems Internals — www.sysinternals.com

NT0SB00T SCCA

\DEVICE\HARDDISKVOLUME2\$MFT

\DEVICE\HARDDISKVOLUME2\WIND0WS\PREFETCH\NT0SB00T-B00DFAAD.PF

\DEVICE\HARDDISKVOLUME2\SYSTEM VOLUME INF0RMATI0N\_REST0RE{

987E0331-0F01-427C-A58A-7A2E4AABF84D}\RP24\CHANGE.LOG

\DEVICE\HARDDISKVOLUME2\WIND0WS\SYSTEM32\DRIVERS\PROCESSR.SYS

\DEVICE\HARDDISKVOLUME2\WIND0WS\SYSTEM32\DRIVERS\FGLRYM.SYS

\DEVICE\HARDDISKVOLUME2\WIND0WS\SYSTEM32\DRIVERS\VIDE0PRT.SYS

\DEVICE\HARDDISKVOLUME2\WIND0WS\SYSTEM32\DRIVERS\E1000325.SYS

\DEVICE\HARDDISKVOLUME2\WIND0WS\SYSTEM32\DRIVERS\USBUHCI.SYS

\DEVICE\HARDDISKVOLUME2\WIND0WS\SYSTEM32\DRIVERS\USBPORT.SYS

\DEVICE\HARDDISKVOLUME2\WIND0WS\SYSTEM32\DRIVERS\USBEHCI.SYS

\DEVICE\HARDDISKVOLUME2\WIND0WS\SYSTEM32\DRIVERS\NIC1394.SYS

Средство предвыборки вызывается при загрузке системы или запуске приложения, чтобы оно могло выполнить предварительную выборку. Средство предвыборки просматривает каталог Prefetch и проверяет, есть ли в нем какой-нибудь файл с трассировочной информацией, необходимый для текущего варианта предварительной выборки. Если такой файл имеется, оно обращается к NTFS для предварительной выборки любых ссылок файла метаданных MFT, считывает содержимое каждого каталога, на который есть ссылка, а затем открывает все файлы в соответствии со списком ссылок. Далее вызывается функция MmPrefetchPages диспетчера памяти, чтобы загрузить в память любые данные и код, указанные в трассировочной информации, но пока отсутствующие в памяти. Диспетчер памяти инициирует все необходимые операции как асинхронные и ждет их завершения, прежде чем разрешить продолжение процесса запуска приложения.

ЭКСПЕРИМЕНТ: наблюдение за чтением и записью файла предвыборки

Если вы запишете трассировку запуска приложения с помощью Filemon (wwwsysinternals.com) в Windows XP, то заметите, что средство предвыборки проверяет наличие файла предвыборки и, если он есть, считывает его содержимое, а примерно через десять секунд от начала запуска приложения средство предвыборки записывает новую копию этого файла. Ниже показан пример для процесса запуска Notepad (фильтр Include был установлен как «prefetch», чтобы Filemon сообщал об обращениях только к каталогу \Windows\Prefetch).

Строки 1–3 показывают, что файл предвыборки Notepad считывался в контексте процесса Notepad в ходе его запуска. Строки 4-10 (с временными метками на 10 секунд позже, чем в первых трех строках) демонстрируют, что Task Scheduler, который выполняется в контексте процесса Svchost, записал обновленный файл предвыборки.

Чтобы еще больше уменьшить вероятность скачкообразного поиска, через каждые три дня (или около того) Task Scheduler в периоды простоя формирует список файлов и каталогов в том порядке, в каком на них были ссылки при загрузке системы или запуске приложения, и сохраняет его в файле \Windows\Prefetch\Layout.ini (рис. 7-32).

Далее он запускает системный дефрагментатор, указывая ему через командную строку выполнить дефрагментацию на основе содержимого файла Layout.ini. Дефрагментатор находит на каждом томе непрерывную область, достаточно большую, чтобы в ней уместились все файлы и каталоги, перечисленные для данного тома, а затем целиком перемещает их в эту область в указанном порядке. Благодаря этому будущие операции предварительной выборки окажутся еще эффективнее, поскольку все считываемые данные теперь физически хранятся на диске в нужной последовательности. Такая дефрагментация обычно затрагивает всего несколько сотен файлов и поэтому выполняется гораздо быстрее, чем полная дефрагментация диска. (Подробнее о дефрагментации см. в главе 12.)

Правила размещения

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

Если на момент появления ошибки страницы физическая память заполнена, выбирается страница, подлежащая выгрузке на диск для освобождения памяти под новую страницу. Этот выбор осуществляется по правилам замены (replacement policy). При этом действуют два общих правила замены: LRU (least recently used) и FIFO (first in, first out). Алгоритм LRU (также известный как алгоритм часов и реализованный в большинстве версий UNIX) требует от подсистемы виртуальной памяти следить за тем, когда используется страница в памяти. Страница, не использовавшаяся в течение самого длительного времени, удаляется из рабочего набора. Алгоритм FIFO работает проще: он выгружает из физической памяти страницу, которая находилась там дольше всего независимо от частоты ее использования.

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

B Windows реализована комбинация локальных и глобальных правил замены. Когда размер рабочего набора достигает своего лимита и/или появляется необходимость его усечения из-за нехватки физической памяти, диспетчер памяти удаляет из рабочих наборов ровно столько страниц, сколько ему нужно освободить.

Управление рабочими наборами

Все процессы начинают свой жизненный цикл с максимальным и минимальным размерами рабочего набора по умолчанию — 50 и 345 страниц соответственно. Хотя это мало что дает, эти значения по умолчанию можно изменить для конкретного процесса через Windows-функцию SetProcessWorkingSetSize, но для этого нужна привилегия Increase Scheduling Priority. Однако, если только вы не укажете процессу использовать жесткие лимиты на рабочий набор (новшество Windows Server 2003), эти лимиты игнорируются в том смысле, что диспетчер памяти разрешит процессу расширение за установленный максимум при наличии интенсивной подкачки страниц и достаточного объема свободной памяти (либо, напротив, уменьшит его рабочий набор ниже минимума при отсутствии подкачки страниц и при высокой потребности системы в физической памяти). Хотя в Windows 2000 степень расширения процесса за максимальную границу рабочего набора увязывалась с вероятностью его усечения, в Windows XP это решение принимается исключительно на основе того, к скольким страницам обращался процесс.

B Windows Server 2003 жесткие лимиты на размеры рабочего набора могут быть заданы вызовом функции SetProcessWorkingSetSizeEx с флагом QUOTA_LIMITS_HARDWS_ENABLE. Этой функцией пользуется, например, Windows System Resource Manager fWSRM), описанный в главе 6.

Максимальный размер рабочего набора не может превышать общесистемный максимум, вычисленный при инициализации системы и хранящийся в переменной ядра MmMaximumWorkingSetSize. Это значение представляет собой число страниц, доступных на момент вычислений (суммарный размер списков обнуленных, свободных и простаивающих страниц), за вычетом 512 страниц. Однако существуют жесткие верхние лимиты на размеры рабочих наборов — они перечислены в таблице 7-17.

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

Хотя Windows пытается поддерживать достаточный объем доступной памяти, записывая измененные страницы на диск, при слишком быстрой генерации модифицированных страниц понадобится больше свободной памяти. Поэтому, когда свободной физической памяти становится мало, вызывается диспетчер рабочих наборов (working set manager), который выполняется в контексте системного потока диспетчера настройки баланса (см. следующий раздел) и инициирует автоматическое усечение рабочего набора для увеличения объема доступной в системе свободной памяти. (Используя Windows-функцию SetProcessWorkingSetSize, вы можете вызвать усечение рабочего набора своего процесса, например после его инициализации.)

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

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

B однопроцессорных системах Windows 2000 и всех системах Windows XP или Windows Server 2003 диспетчер рабочих наборов старается удалять страницы, к которым не было обращений в последнее время. Такие страницы обнаруживаются проверкой битового флага Accessed в аппаратном РТЕ. Если этот флаг сброшен, страница считается устаревшей, и соответствующий счетчик увеличивается на 1, показывая, что с момента последнего сканирования данного рабочего набора к этой странице не было обращений. Впоследствии возраст страниц учитывается при поиске кандидатов на удаление из рабочего набора.

ПРИМЕЧАНИЕ B многопроцессорной системе Windows 2000 диспетчер рабочего набора ошибочно не проверял битовый флаг Accessed, что приводило к удалению страниц из рабочего набора без учета состояния этого флага.

Если битовый флаг Accessed в аппаратном PTE установлен, диспетчер рабочих наборов сбрасывает его и проверяет следующую страницу рабочего набора. Таким образом, если при следующем сканировании битовый флаг Accessed окажется сброшенным, диспетчер будет знать, что со времени последнего сканирования к этой странице не было обращений. Сканирование списка рабочего набора продолжается до удаления нужного числа страниц или до возврата к начальной точке. (B следующий раз сканирование начнется там, где оно остановилось в прошлый раз.)

ЭКСПЕРИМЕНТ: просмотр размеров рабочих наборов процессов

C этой целью можно использовать счетчики в оснастке Performance (Производительность), перечисленные в следующей таблице.

Несколько других утилит для просмотра сведений о процессах (Task Manager, Pview и Pviewer) тоже показывают размеры рабочих наборов.

Суммарный размер рабочих наборов всех процессов можно получить, выбрав процесс _Total в оснастке Performance. Этот несуществующий процесс просто представляет суммарные значения счетчиков всех процессов, выполняемых в системе в данный момент. Однако суммарный размер не соответствует истине, так как при подсчете размера рабочего набора процесса учитываются его разделяемые страницы. B итоге страница, разделяемая двумя или более процессами, засчитывается в размер рабочего набора каждого из таких процессов.

ЭКСПЕРИМЕНТ: просмотр списка рабочего набора

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

Заметьте, что одни элементы списка рабочего набора представляют собой страницы, содержащие таблицы страниц (элементы с адресами выше OxCOOOOOOO), другие — страницы системных DLL (в диапазоне 0x7nnnnnnn), третьи — страницы кода самой LiveKd.exe (в диапазоне 0x004nnnnn).

Диспетчер настройки баланса и подсистема загрузки-выгрузки

Расширение и усечение рабочего набора выполняется в контексте системного потока диспетчера настройки баланса (balance set manager) (процедура KeBalanceSetManagef). Его поток создается при инициализации системы. Хотя с технической точки зрения диспетчер настройки баланса входит в состав ядра, для анализа и регулировки рабочих наборов он обращается к диспетчеру рабочих наборов.

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

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

1. При каждом четвертом пробуждении из-за срабатывания таймера освобождает событие, которое активизирует системный поток, выполняющий процедуру KeSwapProcessOrStack — подсистему загрузки-выгрузки (swapper).

2. Проверяет ассоциативные списки и регулирует глубину их вложения, если это необходимо (для ускорения доступа, снижения нагрузки на пул и уменьшения его фрагментации).

3. Ищет потоки, чей приоритет может быть повышен из-за нехватки процессорного времени (см. раздел «Динамическое повышение приоритета при нехватке процессорного времени» главы 6).

4. Вызывает диспетчер рабочих наборов (имеющий собственные внутренние счетчики, которые определяют, когда и насколько агрессивно следует проводить усечение рабочих наборов).

Подсистема загрузки-выгрузки пробуждается и планировщиком, если стек ядра потока, подлежащего выполнению, или весь процесс выгружен в страничный файл. Подсистема загрузки-выгрузки ищет потоки, которые находились в состоянии ожидания в течение 7 секунд fWindows 2000) или 15 секунд (Windows XP и Windows Server 2003). Если такой поток есть, подсистема загрузки-выгрузки переводит его стек ядра в переходное состояние (перемещая соответствующие страницы в список модифицированных или простаивающих страниц). Здесь действует принцип «если поток столько времени ждал, подождет и еще». Когда из памяти удаляется стек ядра последнего потока процесса, этот процесс помечается как полностью выгруженный. Вот почему у долго простаивавших процессов (например, у Winlogon после вашего входа в систему) может быть нулевой размер рабочих наборов.

Системный рабочий набор

Подкачиваемый код и данные операционной системы тоже управляются как единый системный рабочий набор (system working set). B системный рабочий набор могут входить страницы пяти видов:

• системного кэша;

• пула подкачиваемой памяти;

• подкачиваемого кода и данных Ntoskrnl.exe;

• подкачиваемого кода и данных драйверов устройств;

• проецируемых системой представлений.

Выяснить размер системного рабочего набора и пяти его элементов можно с помощью счетчиков производительности или системных переменных, перечисленных в таблице 7-18. Учтите, что значения счетчиков выражаются в байтах, а значения системных переменных — в страницах.

Узнать интенсивность подкачки страниц в системном рабочем наборе позволяет счетчик Memory: Cache Faults/Sec (Память: Ошибок кэш-памяти/ сек), который сообщает число ошибок страниц, генерируемых в системном рабочем наборе (как аппаратных, так и программных).

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

Минимальный и максимальный размеры системного рабочего набора вычисляются при инициализации системы, исходя из объема физической памяти компьютера и выпуска Windows — клиентского или серверного.

Вычисленные значения максимального и минимального размеров хранятся в системных переменных, показанных в таблице 7-19 (их значения недоступны через счетчики производительности, но вы можете просмотреть их в отладчике ядра).

Вы можете отдать приоритет системному рабочему набору (в противоположность рабочим наборам процессов), изменив параметр реестра HKLM\ SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache. B системах Windows 2000 Server это значение можно было косвенно модифицировать заданием свойств для службы файлового сервера; Windows XP и Windows Server 2003 позволяют сделать это явно: щелкните My Computer (Мой компьютер) правой кнопкой мыши, выберите Properties (Свойства), откройте вкладку Advanced (Дополнительно), нажмите кнопку Settings (Параметры) в разделе Performance (Быстродействие) и перейдите на очередную вкладку Advanced (детали см. в главе 11).

База данных PFN

Если рабочие наборы описывают резидентные страницы, принадлежащие процессу или системе, то база daHHbixPFN (номеров фреймов страниц) определяет состояние каждой страницы в физической памяти. Состояния страниц перечислены в таблице 7-20.

База данных PFN состоит из массива структур, представляющих каждую страницу физической памяти в системе. Как показано на рис. 7-33, действительные PTE ссылаются на записи базы данных PFN, а эти записи (если они не относятся к прототипным PFN) — на таблицу страниц, которая их использует. Прототипные PFN ссылаются на прототипные РТЕ.

Страницы, находящиеся в некоторых из перечисленных в таблице 7-20 состояний, организуются в связанные списки, что помогает диспетчеру памяти быстро находить страницы определенного типа. (Активные и переходные страницы не включаются ни в один общесистемный список.) Пример взаимосвязей элементов таких списков в базе данных PFN показан на рис. 7-34.

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

ЭКСПЕРИМЕНТ: просмотр базы данных PFN

Команда !memusage отладчика ядра позволяет получить информацию о размерах различных списков страниц. Вот пример вывода этой команды.

Динамика списков страниц

Ha рис. 7-35 показана схема состояний фрейма страниц. Для упрощения на ней отсутствует список модифицированных, но не записываемых страниц.

Фреймы страниц перемещаются между различными списками следующим образом.

• Когда диспетчеру памяти нужна обнуленная страница для обслуживания ошибки страницы, обнуляемой по требованию (demand-zero page fault) (ссылки на страницу, которая должна быть заполнена нулями, или на закрытую переданную страницу пользовательского режима, к которой еще не было обращений), он прежде всего пытается получить ее из списка обнуленных страниц. Если этот список пуст, он берет ее из списка свободных страниц и заполняет нулями. Если и этот список пуст, диспетчер памяти извлекает страницу из списка простаивающих страниц и обнуляет ее.

Одна из причин необходимости обнуления страниц — соответствие требованиям защиты уровня C2: процессам пользовательского режима должны передаваться фреймы обнуленных страниц, чтобы не допустить чтения содержимого памяти предыдущих процессов. Поэтому диспетчер памяти передает процессам пользовательского режима фреймы обнуленных страниц, если только страница не считывается из проецируемого файла. B последнем случае диспетчер памяти использует фреймы необнуленных страниц, инициализируя их данными с диска.

Список обнуленных страниц заполняется страницами из списка свободных страниц системным потоком обнуления страниц (zero page thread) — это поток 0 процесса System. Он ждет на объекте-событии, который переходит в свободное состояние при наличии в списке свободных страниц восьми и более страниц. Однако этот поток выполняется, только если не работают другие потоки, поскольку он имеет нулевой приоритет, а наименьший приоритет пользовательского потока — 1.

ПРИМЕЧАНИЕ B Windows Server 2003 и более новых версиях, когда возникает необходимость в обнулении памяти из-за выделения физической страницы драйвером, вызвавшим MmAllocatePagesForMdl, или Windows-приложением, вызвавшими AllocateUserPhysicalPages, либо когда приложение выделяет большие страницы, диспетчер памяти обнуляет память через более эффективную функцию MiZeroInParallel Она проецирует регионы большего размера, чем поток обнуления страниц, который выполняет свою операцию только над одной страницей единовременно. Кроме того, в многопроцессорных системах эта функция создает дополнительные системные потоки для параллельного выполнения операций обнуления (с поддержкой специфических оптимизаций на NUMA-платформах).

• Если диспетчеру памяти не нужны обнуленные станицы, он сначала обращается к списку свободных страниц и, если тот пуст, переходит к списку простаивающих страниц. Прежде чем диспетчер сможет воспользоваться фреймом страниц из списка простаивающих страниц, он должен проследить ссылку из недействительного PTE (или прототипного РТЕ), который еще ссылается на этот фрейм, и удалить ее. Поскольку элементы (записи) базы данных PFN содержат обратные указатели на таблицу страниц предыдущего пользователя (или на прототипный РТЕ, если страницы разделяемые), диспетчер памяти может быстро найти PTE и внести требуемые изменения.

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

ЭКСПЕРИМЕНТ: наблюдаем за ошибками страниц

Утилита Pfmon из ресурсов Windows 2000 и 2003, а также из Windows XP Support Tools позволяет наблюдать за ошибками страниц по мере их возникновения. Ниже показан фрагмент вывода Pfmon при запуске Notepad и его последующем закрытии. Слово SOFT означает, что ошибка страницы была устранена с помощью одного из переходных списков, а слово HARD — что ошибка страницы потребовала чтения с диска. Обратите внимание на итоговые сведения о подкачке страниц в конце листинга.

Подсистема записи модифицированных страниц

При чрезмерном увеличении списка модифицированных страниц либо при уменьшении размера списков обнуленных или простаивающих страниц ниже определенного порогового значения, вычисляемого в ходе загрузки системы и хранящегося в переменной ядра MmMinimumFreePages, пробуждается один из двух системных потоков, который записывает страницы на диск и переводит их в список простаивающих. Один из системных потоков (MiModifiedPageWriter) записывает модифицированные страницы в страничный файл, а другой (MiMappedPageWriter) — в проецируемые файлы. Два потока нужны для того, чтобы избежать тупиковой ситуации, возможной при ошибке страницы в момент записи страниц проецируемых файлов. Эта ошибка потребовала бы свободной страницы в отсутствие таковых, что в свою очередь потребовало бы от подсистемы записи модифицированных страниц создания новых свободных страниц. Поскольку операции ввода-вывода с проецируемыми файлами выполняет второй поток этой подсистемы, он может переходить в состояние ожидания, не блокируя обычные операции ввода-вывода со страничным файлом.

Оба потока выполняются с приоритетом 17, и после инициализации каждый из них ждет на своем объекте-событии. Этот объект переходит в свободное состояние по одной из двух причин.

• Число модифицированных страниц превышает максимум, рассчитанный при инициализации системы (MmModifiedPageMaximum) (в настоящее время — 800 страниц для всех систем).

• Число доступных страниц (MmAvailablePages) меньше значения MmMini-mumFreePages.

Подсистема записи модифицированных страниц ждет еще на одном событии (MiMappedPagesTooOldEvent), которое устанавливается по истечении предопределенного числа секунд (MmModtfiedPageLifeInSeconds), указывая, что проецируемые (а не просто измененные) страницы должны быть записаны на диск. (По умолчанию этот интервал равен 300 секундам. Вы можете изменить его, добавив в раздел реестра HKLM\SYSTEM\CurrentControlSet\ Control\Session Manager\Memory Management параметр ModifiedPageLife типа DWORD.) Дополнительное событие используется для того, чтобы снизить риск потери данных при крахе системы или отказе электропитания путем сохранения модифицированных проецируемых страниц, даже если размер списка модифицированных страниц не достиг порогового значения в 800 страниц.

При активизации подсистема записи модифицированных страниц пытается записать на диск как можно больше страниц одним пакетом. Для этого она анализирует поле исходного содержимого PTE в элементах базы данных PFN, которые относятся к страницам, входящим в список модифицированных страниц, и ищет страницы, хранящиеся в непрерывных областях на диске. Подобрав пакет страниц для записи, она выдает запрос на ввод-вывод и после успешного завершения операции ввода-вывода перемещает их в конец списка простаивающих страниц.

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

Структуры данных PFN

Хотя записи базы данных PFN имеют фиксированную длину, они могут находиться в нескольких состояниях в зависимости от состояния страницы. Таким образом, отдельные поля могут иметь разный смысл. Состояния записи базы данных PFN иллюстрирует рис. 7-36.

Некоторые поля одинаковы для нескольких типов PFN, другие специфичны для конкретного типа PFN. Следующие поля встречаются в PFN нескольких типов.

• Адрес PTE Виртуальный адрес РТЕ, указывающего на данную страницу.

• Счетчик ссылок Число ссылок на данную страницу. Этот счетчик увеличивается на 1, когда страница впервые добавляется в рабочий набор и/ или когда она блокируется в памяти для операции ввода-вывода (например драйвером устройства). Счетчик ссылок уменьшается на 1, когда обнуляется счетчик числа пользователей страницы или когда снимается блокировка страницы в памяти. Когда счетчик числа пользователей становится равным 0, страница больше не принадлежит рабочему набору. Далее, если счетчик ссылок тоже равен 0, страница перемещается в список свободных, простаивающих или модифицированных страниц, и запись базы данных PFN, описывающая эту страницу, соответственно обновляется.

• Тип Тип страницы, представленной этим PFN (активная/действительная, переходная, простаивающая, модифицированная, модифицированная, но не записываемая, свободная, обнуленная, только для чтения или аварийная).

• Флаги Информация, содержащаяся в поле флагов, поясняется в таблице 7-21.

• Исходное содержимое PTE Все записи базы данных PFN включают исходное содержимое РТЕ, указывающего на страницу (который может быть прототипным РТЕ). Сохранение исходного содержимого PTE позволяет восстанавливать его, когда физическая страница больше не резидентна.

• PFN элемента PTE Номер физической страницы для виртуальной страницы с таблицей страниц, включающей PTE страницы, к которой относится данный PFN.

Остальные поля специфичны для PFN конкретных типов. Так, первый PFN на рис. 7-36 представляет активную страницу, входящую в рабочий набор. Поле счетчика числа пользователей (share count) сообщает количество РТЕ, ссылающихся на данную страницу. (Страницы с атрибутом «только для чтения», «копирование при записи» или «разделяемая, для чтения и записи» могут использоваться сразу несколькими процессами.) B случае страниц с таблицами страниц это поле содержит количество действительных PTE в таблице страниц. Пока счетчик числа пользователей страницы больше 0, она не удаляется из памяти.

Поле индекса рабочего набора — это индекс в списке рабочего набора (процесса, системы или сеанса), включающем виртуальный адрес, по которому проецируется данная физическая страница. Если страница не входит ни в один рабочий набор, это поле равно 0. Если страница является закрытой, индекс рабочего набора ссылается непосредственно на элемент списка рабочего набора, поскольку страница проецируется только по одному виртуальному адресу. B случае разделяемой страницы индекс рабочего набора представляет собой ссылку, корректность которой гарантируется лишь для первого процесса, объявившего эту страницу действительной. (Остальные процессы будут пытаться по возможности использовать тот же индекс.) Процесс, первым настроивший это поле, обязательно получит корректную ссылку, и ему не надо добавлять в дерево хэшей своего рабочего набора элемент хэша списка рабочего набора, на который указывает виртуальный адрес. Это позволяет уменьшить размер дерева хэшей рабочего набора и ускорить поиск его элементов.

Второй PFN на рис. 7-36 соответствует странице из списка простаивающих или модифицированных страниц. B этом случае элементы списка связаны полями прямых и обратных связей. Эти связи позволяют легко манипулировать страницами при обработке ошибок страниц. Когда страница находится в одном из списков, ее счетчик числа пользователей по определению равен 0 (поскольку она не используется ни в одном рабочем наборе) и поэтому может быть перекрыта обратной связью. Счетчик ссылок также равен 0, если страница находится в одном из списков. Если же он отличен от 0 (из-за выполнения над данной страницей операции ввода-вывода, например записи на диск), страница сначала удаляется из списка.

Третий PFN на рис. 7-36 соответствует странице из списка свободных или обнуленных страниц. Эти записи базы данных PFN связывают не только страницы внутри двух списков, но и — с помощью дополнительного поля — физические страницы «по цвету», т. е. по их местонахождению в кэш-памяти процессора. Windows пытается свести к минимуму лишнюю нагрузку на кэшпамять процессора из-за наличия в ней разных физических страниц. Эта оптимизация реализуется за счет того, что Windows по возможности избегает использования одного и того же элемента кэша для двух разных страниц. Для систем с прямым проецированием кэшей оптимальное использование аппаратных возможностей дает существенный выигрыш в производительности.

Четвертый PFN на рис. 7-36 соответствует странице, над которой выполняется операция ввода-вывода (например, чтение). Пока идет такая операция, первое поле указывает на объект «событие», который освобождается по окончании операции ввода-вывода. Если при этом произойдет ошибка, в данное поле будет записан код статуса ошибки Windows, представляющий ошибку ввода-вывода. PFN этого типа используются в разрешении конфликтов ошибок страницы.

ЭКСПЕРИМЕНТ: просмотр записей PFN

Отдельные записи PFN можно исследовать с помощью команды !pfn отладчика ядра, указывая PFN как аргумент. (Так, !pfn 0 сообщает информацию о первой записи, !pfn 1 — о второй и т. д.) B следующем примере показывается PTE для виртуального адреса 0x50000, PFN страницы с каталогом страниц и сама страница.

Общее состояние физической памяти описывается не только базой данных PFN, но и системными переменными, перечисленными в таблице 7-22.

Уведомление о малом или большом объеме памяти

Windows XP и Windows Server 2003 позволяют процессам пользовательского режима получать уведомления, когда памяти мало и/или много. Ha основе этой информации можно определять характер использования памяти. Например, если свободной памяти мало, приложение может уменьшить потребление памяти, а если ее много — увеличить.

Для уведомления о малом или большом объеме памяти вызовите функцию CreateMemoryResourceNotification, указав, какое именно уведомление вас интересует. Описатель полученного объекта может быть передан любой функции ожидания. Как только памяти становится мало (или много), ожидание прекращается, тем самым уведомляя соответствующий поток о нужном событии. B качестве альтернативы можно использовать QueryMemoryResourceNotiflcation для запроса о состоянии системной памяти в любой момент.

Уведомление реализуется диспетчером памяти, который переводит в свободное состояние глобально именованный объект «событие» LowMemory-Condition или HighMemoryCondition. Эти именованные объекты находятся не в обычном каталоге \BaseNamedObjects диспетчера объектов, а в специальном каталоге \KernelObjects. Как только обнаруживается малый или большой объем свободной памяти, соответствующее событие освобождается, и любые ждущие его потоки пробуждаются.

По умолчанию уведомление о малом объеме памяти срабатывает при наличии свободной памяти размером около 32 Мб на 4 Гб (максимум 64 Мб), а уведомление о большом объеме — при наличии в три раза большего количества свободной памяти. Эти значения (в мегабайтах) можно переопределить, добавив DWORD-параметр LowMemoryThreshold или HighMemory-Threshold в раздел реестра HKEY_LOCAL_MACHINE\System\CurrentControl-Set\Session Manager\Memory Management.

ЭКСПЕРИМЕНТ: просмотр событий уведомления ресурса памяти

Для просмотра событий уведомления ресурса памяти (memory resource notification events) запустите Winobj (wwwsysintemals.com) и щелкните каталог KernelObjects. B правой секции окна вы увидите события LowMemoryCondition и HighMemoryCondition.

Если вы дважды щелкнете любое из событий, то узнаете, сколько описателей и/или ссылок открыто на эти объекты.

Чтобы выяснить, есть ли в системе процессы, запросившие уведомления о ресурсе памяти, ищите в таблице описателей ссылки на «LowMemoryCondition» или «HighMemoryCondition». Это можно сделать в Process Explorer (команда Handle в меню Find) или в утилите Oh.exe из ресурсов Windows. (O том, что такое таблица описателей, см. раздел «Диспетчер объектов» главы 3.)

Оптимизаторы памяти — миф или реальность?

При серфинге по Web вы наверняка нередко видели всплывающие окна в браузере с рекламой наподобие «Дефрагментируйте память и повысьте производительность» или «Избавьтесь от сбоев приложений и системы и освободите неиспользуемую память». Такие ссылки обычно ведут к утилитам, авторы которых обещают сделать все и даже больше. A работают ли они на самом деле?

Оптимизаторы памяти обычно предоставляют UI, где выводятся график под названием «доступная память» и линия, отражающая нижнее пороговое значение, начиная с которого утилита вступает в действие. Еще одна линия, как правило, показывает объем памяти, который оптимизатор попытается освободить. Вы можете настроить один или оба уровня, а также запускать оптимизацию вручную или по расписанию. Некоторые утилиты также показывают список процессов, выполняемых в системе. Когда начинается оптимизация, счетчик доступной памяти в утилите увеличивается, иногда весьма резко, сообщая тем самым, что утилита действительно освобождает память для ваших приложений. Ho на самом деле подобные утилиты просто вызывают обнуление полезной памяти, искусственно увеличивая объем свободной памяти.

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

Полоска «до оптимизации» отражает рабочие наборы и свободную память до оптимизации. Ha полоске «при оптимизации» видно, что оптимизатор создает высокую потребность в памяти, вызывая массу ошибок страниц в течение короткого времени. B ответ диспетчер памяти увеличивает рабочий набор оптимизатора памяти. Это расширение рабочего набора происходит за счет свободной памяти, а когда свободная память заканчивается, то и за счет рабочих наборов других процессов. Полоска «после оптимизации» демонстрирует, что после освобождения своей памяти оптимизатором диспетчер памяти переводит все страницы, которые были закреплены за оптимизатором, в список свободных страниц. Там они в конечном счете заполняются нулями потоком обнуления страниц, а затем перемещаются в список обнуленных страниц, что и дает вклад в увеличение счетчика доступной памяти. Большинство оптимизаторов скрывают резкое уменьшение свободной памяти на первом этапе, но, запустив диспетчер задач при оптимизации, вы легко заметите, что такое падение объема свободной памяти действительно имеет место.

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

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

Авторы оптимизаторов памяти также утверждают, что их утилиты дефрагментируют память. Действительно, выделение и последующее освобождение большого объема виртуальной памяти может в качестве побочного эффекта привести к появлению больших блоков непрерывной свободной памяти. Однако, так как виртуальная память скрывает реальную структуру физической памяти от процессов, они не могут получить прямой выигрыш от виртуальной памяти, спроецированной на непрерывную область физической памяти. По мере выполнения процессов и периодического расширения-усечения их рабочих наборов физическая память, сопоставленная с занимаемой ими виртуальной памятью, может стать фрагментированной несмотря на наличие больших непрерывных областей. K тому же, любой незначительный выигрыш от дефрагментации свободной физической памяти с лихвой перекрывается негативным эффектом от выгрузки из памяти используемого кода и данных.

Наконец, можно услышать, что оптимизаторы возвращают память, потерянную в результате утечек. Это, наверное, самое ложное утверждение. Диспетчеру памяти всегда известно, какая физическая и виртуальная память принадлежит тому или иному процессу. Однако, если процесс выделяет память, а потом не освобождает ее из-за какой-то ошибки (это событие и называется утечкой), диспетчер памяти не в состоянии распознать, что выделенная память больше не будет использоваться, и поэтому вынужден ждать завершения процесса, чтобы отобрать эту память. Даже у процессов, которые вызывают утечку памяти и не завершаются, диспетчер памяти в конечном счете, в результате усечения рабочего набора отберет все физические страницы, связанные с утекающей виртуальной памятью. Страницы последней будут отправлены в страничный файл, а физическая память будет освобождена для использования в других целях. Таким образом, утечка памяти лишь ограниченно влияет на доступную физическую память. По-настоящему она влияет на потребление виртуальной памяти, которое хорошо заметно по счетчикам PF Usage и Commit Charge в диспетчере задач. Никакая утилита ничего не сможет сделать с пустым расходом виртуальной памяти, если только не «убьет» процессы, поглощающие эту память.

Короче говоря, если бы от оптимизаторов памяти был хоть какой-нибудь толк, разработчики Microsoft давно интегрировали бы такую технологию в ядро Windows.

Резюме

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

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

B этой главе мы не затронули такой аспект, как тесная интеграция диспетчера памяти с диспетчером кэша, — об этом будет рассказано в главе 11. A теперь давайте перейдем к детальному рассмотрению механизмов защиты Windows.