Mark Russinovich по-русски

Миф о дублировании SID компьютера

abeshkov — Sun, 15 Nov 2009 18:35:01 GMT

3 ноября 2009 года Sysinternals закрыла проект NewSID - утилиты, которая предназначалась для изменения идентификатора защиты компьютера (machine SID). Я написал NewSID в 1997 году (первоначально она называлась NTSID), поскольку в то время единственным...(read more)

Преодолевая границы Windows: процессы и потоки

abeshkov — Mon, 02 Nov 2009 13:47:12 GMT

Это четвертая статья из серии "Преодолевая границы Windows", в рамках которой я рассказываю об ограничениях, существующих для фундаментальных ресурсов в Windows. На сей раз, я собираюсь обсудить с вами ограничение на максимальное количество...(read more)

Преодолевая ограничения Windows: дескрипторы

abeshkov — Wed, 21 Oct 2009 06:52:38 GMT

Это уже пятая статья из моей серии публикаций "Преодолевая границы Windows", в которых я рассказываю о максимальном значении и объеме ресурсов, которыми управляет Windows, таких как физическая память, виртуальная память, процессы и потоки: Преодолевая...(read more)

Дело о временных профилях реестра

abeshkov — Thu, 15 Oct 2009 02:58:09 GMT

Служба поддержки клиентов корпорации Microsoft является одним из крупнейших пользователей утилит Sysinternals и они часто посылают мне письма с рассказами о проблемах, которые они решили с помощью наших утилит. Случай, о котором я расскажу в этой статье,...(read more)

Дело о медленной демонстрации

abeshkov — Tue, 26 May 2009 09:41:00 GMT

Несколько недель назад я впервые участвовал в презентации на конференции Microsoft Teched перед аудиторией в 5000 человек. Билл Вегте (Bill Veghte), старший вице-президент Microsoft по продажам Windows, вел эту презентацию и делал обзор новых возможностей...(read more)

Преодолевая ограничения Windows: выгружаемый и невыгружаемый пулы

abeshkov — Thu, 07 May 2009 01:00:00 GMT

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

Дело о таинственных файлах на рабочем столе

abeshkov — Tue, 03 Feb 2009 16:16:00 GMT

Несколько недель назад моя жена сказала мне, что иногда в папке Desktop ее компьютера появлялись файлы, которые не отображались на самом рабочем столе. Она заговорила об этом не только потому, что была удивлена несоответствием, но так как она хотела переместить...(read more)

Дело о прервавшемся телефонном звонке

abeshkov — Wed, 31 Dec 2008 01:48:00 GMT

У Дэвида Соломона (David Solomon), моего соавтора по книгам Windows Internals, недавно был очень важный разговор в VoIP-сети Skype, когда звук неожиданно исказился. Через секунду привычный рабочий стол сменил BSOD. После того, как он перезагрузил компьютер,...(read more)

Преодолевая ограничения Windows: виртуальная память

abeshkov — Tue, 18 Nov 2008 01:48:00 GMT

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

Дело о мееееедленной системе

abeshkov — Wed, 24 Sep 2008 14:24:00 GMT

Несколько недель назад моя жена пожаловалась мне, что Vista на ее настольном компьютере не реагирует на движение мышкой или ввод с клавиатуры. Принимая во внимание важность этого клиента, я тут же сел за компьютер, чтобы решить эту проблему. Система,...(read more)

Преодолевая ограничения Windows: физическая память

abeshkov — Mon, 21 Jul 2008 14:42:00 GMT

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

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

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

Ограничения памяти в ОС Windows Server
Особенности поддержки физической памяти в ОС Windows продиктованы ограничениями оборудования, условиями лицензирования, характеристиками структур данных операционной системы и вопросами совместимости драйверов. На странице "Ограничения памяти в различных выпусках ОС Windows" (на английском языке) веб-узла MSDN изложены ограничения памяти, характерные для различных версий Windows и номеров SKU в рамках каждой версии.

Как видите, во всех серверных версиях ОС Windows разным номерам SKU соответствуют разные формы поддержки физической памяти, обусловленные условиями лицензионных соглашений. К примеру, 32-разрядная версия ОС Windows Server 2008 Standard поддерживает лишь 4 ГБ физической памяти, в то время как 32-разрядная версия Windows Server 2008 Datacenter – 64 ГБ. С другой стороны, 64-разрядная версия ОС Windows Server 2008 Standard поддерживает всего 32 ГБ физической памяти, а 64-разрядная версия Windows Server 2008 Datacenter – целых 2 ТБ. Систем с физической памятью объемом 2 ТБ не так уж много – участники рабочей группы по вопросам производительности ОС Windows Server знают пару таких, одна из которых в какой-то момент была собрана в их собственной лаборатории. Вот как выглядит диспетчер задач в такой системе.

Максимальный для 32-разрядных систем объем памяти – 128 ГБ – поддерживается версией Windows Server 2003 Datacenter Edition. Такое ограничение связано с тем, что в более мощных системах структуры, применяемые диспетчером памяти для отслеживания физической памяти, потребляли бы слишком большую часть пространства виртуальных адресов. Диспетчер памяти отслеживает страницы памяти при помощи массива, называемого базой данных PFN, и в целях оптимизации производительности отображает все содержимое этой базы в виртуальную память. Так как каждая страница памяти представлена структурой данных объемом 28 байт, в системе с физической памятью емкостью 128 ГБ для размещения базы данных PFN потребуется 930 МБ. В 32-разрядных ОС Windows предусмотрено пространство виртуальных адресов объемом 4 ГБ, зависящее от оборудования и по умолчанию распределяемое между текущим процессом пользовательского режима (например, блокнотом) и системой. В таких условиях база данных PFN объемом 980 МБ занимает почти половину из доступных 2 ГБ системной части пространства виртуальных адресов, а значит, на отображение ядра, драйверов устройств, системного кэша и других структур данных системы остается всего 1 ГБ (см. иллюстрацию).

По той же причине в таблице ограничений объема памяти указаны пониженные лимиты для SKU при загрузке в режиме настройки систем с объемом памяти 4 ГБ (иначе называемом 4GT и включаемом параметрами загрузки /3GB или /USERVA файла Boot.ini и параметром /Set IncreaseUserVa программы Bcdedit). Дело в том, что для этого режима характерна такая схема разделения физической памяти, при которой процессам пользовательского режима достается 3 ГБ, а системе – всего 1 ГБ. В целях повышения производительности в ОС Windows Server 2008 для системных нужд резервируется более значимая доля адресного пространства. Для этого максимальный объем физической памяти, поддерживаемый в 32-разрядных версиях ОС, сокращается до 64 ГБ.

Диспетчер памяти мог бы высвободить память путем выборочного отображения фрагментов базы данных PFN в системные адреса по мере необходимости, однако этот вариант слишком сложен и имеет потенциал снижения производительности, связанного с дополнительными операциями отображения и отмены отображения. Лишь недавно стали появляться системы настолько производительные, чтобы такой вариант можно было рассматривать как реалистичный. Впрочем, так как размер системной части адресного пространства не является ограничением для отображения всей базы данных PFN в 64-разрядных версиях ОС Windows, поддержка большего объема памяти реализована именно в них.

Версия ОС Windows Server 2008 Datacenter поддерживает до 2 ТБ физической памяти. Такое ограничение не связано ни с особенностями реализации, ни с возможностями оборудования – все дело в том, что корпорация Майкрософт не объявляет о поддержке конфигураций, которые мы не в состоянии протестировать. На момент выпуска ОС Windows Server 2008 «рекорд» по объему памяти находился на отметке 2 ТБ – на этом и остановились.

Ограничения памяти в клиентских версиях ОС Windows
64-разрядные клиентские версии ОС Windows поддерживают разные объемы памяти – от 512 МБ в Windows XP Starter до 128 ГБ в Vista Ultimate. В то же время, все 32-разрядные клиентские версии ОС Windows, в том числе Windows Vista, Windows XP и Windows 2000 Professional, поддерживают физическую память в объеме до 4 ГБ. 4 ГБ – это максимальный физический адрес, доступный в стандартном режиме управления памятью x86. Некоторое время назад поддержка памяти в объеме свыше 4 ГБ была бессмысленна – системы с таким объемом памяти, даже серверные, встречались чрезвычайно редко.

К моменту разработки пакета обновления 2 (SP2) для ОС Windows XP появление клиентских систем с объемом памяти свыше 4 ГБ уже прогнозировалось, что заставило разработчиков приступить к интенсивному тестированию Windows XP на подобных системах. Кроме того, в пакете обновления 2 (SP2) для ОС Windows XP была реализована поддержка расширений физических адресов (PAE) по умолчанию для устройств, поддерживающих технологию No Execute, что, во-первых, необходимо для предотвращения исполнения данных (DEP), а во-вторых, обеспечивает возможность поддержки памяти в объеме более 4 ГБ.

В ходе тестирования выяснилось, что многие системы аварийно завершают работу, зависают и отказываются загружаться. Происходит это из-за того, что некоторые драйверы устройств, в особенности аудио- и видеоустройств, которые, в основном, встречаются в клиентских системах, а не в серверах, запрограммированы на работу с физическими адресами в пределах 4 ГБ. Эти драйверы, оказываются, обрубают адреса свыше 4 ГБ, что приводит к повреждению содержимого памяти со всеми вытекающими последствиями. В серверных же системах, которые, как правило, оснащаются менее специфичными устройствами с относительно простыми и надежными драйверами, подобные проблемы обнаружены не были. Выявленные недостатки экосистемы драйверов заставили применительно к клиентским версиям ОС отказаться от работы с памятью в объеме свыше 4 ГБ, несмотря на то, что теоретически её адресация возможна.

Фактические ограничения памяти в 32-разрядных клиентских системах
Согласно официальным условиям лицензии, в 32-разрядных клиентских версиях ОС допускается установка памяти в объеме до 4 ГБ. Фактически же лимит поддержки объема памяти ниже – кроме того, он зависит от набора микросхем и характеристик подключенных устройств. Дело в том, что в таблицу физических адресов включается не только оперативная память, но и память устройств. При этом для совместимости с 32-разрядными операционными системами, которые не способны обрабатывать адреса свыше 4 ГБ, в системах x86 и x64 память устройств отображается ниже границы адресации 4 ГБ. Предположим, если в системе установлено 4 ГБ оперативной памяти, а окна в память сетевых адаптеров, аудио- и видеоустройств в сумме составляют 500 МБ, то 500 МБ из 4 ГБ оперативной памяти окажутся за границей адресации (см. рисунок).

Следовательно, оснащение 32-разрядной системы с клиентской версией ОС Windows памятью объемом 3 ГБ и выше, вполне возможно, не принесет желаемого эффекта. В ОС Windows 2000, Windows XP и Windows Vista RTM с объемом доступной памяти можно ознакомиться в диалоговом окне System Properties (Свойства системы), на странице Performance (Быстродействие) диспетчера задач. В ОС Windows XP и Windows Vista (в том числе с пакетом обновления 1 (SP1)) эти сведения можно также получить с помощью служебных программ Msinfo32 и Winver. С выходом пакета обновления 1 (SP1) для ОС Windows Vista некоторые из этих инструментов стали указывать объем установленной, а не доступной, памяти, о чем сказано в специальной статье базы знаний Майкрософт.

Как свидетельствует утилита Msinfo32, при загрузке моего ноутбука под управлением 32-разрядной версии Vista доступно 3,5 ГБ памяти из четырех установленных.

Схему распределения физической памяти можно узнать с помощью служебной программы Meminfo, написанной Алексом Ионеску (Alex Ionescu – он, кстати сказать, принимает участие в подготовке пятого издания нашей с Дэвидом Соломоном (David Solomon) книги «Внутреннее устройство Windows»). Вот как выглядят выходные данные программы Meminfo, запущенной с параметром –r, который позволяет вывести на консоль диапазоны физической памяти.

Обратите внимание на два разрыва между страницами: от 9F0000 до 100000 и от DFE6D000 до FFFFFFFF (4 ГБ). Характерно, что при загрузке того же компьютера с 64-разрядной версией Vista все 4 ГБ памяти отмечаются как доступные, а 500 МБ ОЗУ, оставшиеся выше отметки 4 ГБ, задействуются следующим образом.

Так почему же эти разрывы возникают ниже границы 4 ГБ? Ответить на этот вопрос нам поможет диспетчер устройств. Запустите оснастку "devmgmt.msc", выберите в меню View (Вид) команду Resources by Connection (Ресурсы по подключению) и раскройте узел Memory (Память). На моем ноутбуке основным потребителем отображаемой памяти устройств, что не удивительно, является видеоадаптер, на долю которого приходится 256 МБ в диапазоне E0000000-EFFFFFFF:

Оставшийся объем распределяется между другими устройствами. Кроме того, согласно консервативной оценке микропрограммы в период загрузки, шина PCI резервирует для устройств дополнительные диапазоны.

Потребление адресов памяти ниже 4 ГБ особенно заметно в мощных игровых системах с высокопроизводительными видеоадаптерами. Я как-то купил в магазине, специализирующемся на игровых компьютерах, систему с 4 ГБ ОЗУ и двумя видеоадаптерами по 1 ГБ каждый. Я не стал специально указывать свои предпочтения по части ОС, предполагая, что установлена 64-разрядная версия Vista. Вопреки моим ожиданиям, выяснилось, что они установили 32-разрядную версию, а значит, операционной системе доступно лишь 2,2 ГБ из установленной памяти. После установки 64-разрядной версии, по данным программы Meminfo, в диапазоне памяти между 8FEF0000 и FFFFFFFF образовался громадный разрыв.

Диспетчер устройств сообщает о том, что 512 МБ в этом разрыве, составляющем в общей сложности свыше 2 ГБ, отводится видеоадаптерам (по 256 МБ каждому). Кроме того, похоже, микропрограмма зарезервировала дополнительный объем памяти – либо для динамического отображения, либо в силу консервативности оценки.

Даже если система оснащена всего 2 ГБ физической памяти, может случиться так, что часть её окажется недоступной под управлением 32-разрядной версии Windows. Причиной тому – наборы микросхем, практикующие агрессивное резервирование областей памяти для устройств. На нашем общем семейном компьютере, купленном несколько месяцев назад у крупного изготовителя оборудования, доступно 1,97 ГБ из установленных 2 ГБ физической памяти.

Диапазон физических адресов от 7E700000 до FFFFFFFF зарезервирован шиной PCI и устройствами. Таким образом, даже теоретически пространство физических адресов не может превышать 7E700000 байт (1,976 ГБ), но поскольку часть этого диапазона резервируется для памяти устройств, Windows сообщает о том, что общий объем памяти составляет 1,97 ГБ.

Так как теперь для получения сертификата о подписывании драйверов изготовители оборудования должны предоставлять в лаборатории WHQL драйверы как для 32-разрядных, так и для 64-разрядных версий Windows, большинство современных драйверов вполне справляются с физическим адресами свыше 4 ГБ. 32-разрядные версии Windows в силу наличия риска, который очень трудно оценить, будут по-прежнему игнорировать память выше границы 4 ГБ. При этом изготовители оборудования в тех случаях, когда этому ничто не препятствуют, переходят (или, по крайней мере, должны переходить) на 64-разрядные версии.
Вывод прост: потребление памяти в полном объеме, каким бы существенным он ни был (конечно, в рамках ограничений версии), возможно только в 64-разрядных версиях Windows. При покупке специализированного игрового компьютера обязательно попросите изготовителя оборудования сразу установить 64-разрядную версию операционной системы.

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

Дефицит доступной памяти свидетельствует о том, что к физической памяти активно обращаются процессы или система. Если же объем доступной памяти оказывается близким к нулю в течение длительного времени, значит, имеет смысл установить дополнительную память. Существует несколько способов мониторинга доступной памяти. В ОС Windows Vista опосредованно отслеживать объем доступной памяти помогает индикатор Physical Memory Usage History (Хронология использования физической памяти) диспетчера задач. Его значение должно быть постоянно приближено к 100%. Вот как выглядит диспетчер задач в моей настольной системе с объемом памяти 8 ГБ (кстати, не много ли у меня памяти?!).

Во всех версиях ОС Windows график доступной памяти можно вывести при помощи системного монитора. Для этого нужно активировать счетчик Available Bytes (Доступно байт) из группы счетчиков Memory performance (Производительность памяти).

С текущей величиной доступной памяти можно ознакомиться в диалоговом окне System Information (System Information) программы Process Explorer или (в предшествующих Vista версиях ОС Windows) на странице Performance (Быстродействие) диспетчера задач.

Как преодолеть ограничения
Из трех основных ресурсов – процессора, памяти и дисковой подсистемы – характеристики памяти, как правило, оказывают наибольшее влияние на общую производительность системы. Чем памяти больше, тем лучше. Быть уверенными в том, что весь потенциал установленной памяти реализован, вам помогут 64-разрядные версии ОС Windows. Они, между прочим, предоставляют ряд других преимуществ по части производительности, о которых я расскажу в одном из предстоящих выпусков серии «Преодолевая ограничения Windows», посвященном виртуальной памяти и её ограничениям.

Оригинал записи

Дело о случайных сбоях Internet Explorer и Windows Media Player

abeshkov — Mon, 02 Jun 2008 14:34:00 GMT

Когда я впервые столкнулся со сбоями Internet Explorer (IE) на моей домашней 64-битной игровой системе, то изначально списал всю вину на повреждение памяти стороннего плагина. Я продолжил свою работу, но через несколько дней я снова столкнулся со сбоем...(read more)

Дело о случайных сбоях Internet Explorer и Windows Media Player

abeshkov — Mon, 02 Jun 2008 14:34:00 GMT

Дело об ошибке FrontPage

abeshkov — Wed, 14 May 2008 18:15:00 GMT

В очередной статье из серии "Дело об..." от Марка Руссиновича (Mark Russinovich) мы поговорим об ошибке, вызванной некорректным наследованием прав в Windows. Представляем вам первую публикацию из серии "Дело об" от стороннего автора....(read more)

Дело о пиках загрузки ЦП системным процессом

abeshkov — Mon, 07 Apr 2008 14:46:00 GMT

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

Главным для меня способом контроля за происходящим является автоматический запуск программы Process Explorer при входе в систему. При настройке каждого нового компьютера я добавляю в папку автозапуска в профиле своей учетной записи ярлык на программу Process Explorer с параметром /t, который свертывает ее окно. В результате работу программы Process Explorer выдает лишь значок на панели задач с графиком уровня загрузки ЦП. Так как мне нужен доступ к детальной информации о системных и моих собственных процессах, при работе в ОС Windows Vista я также указываю параметр /e. Каждый раз при входе в систему он заставляет Windows выводить запрос системы контроля учетных записей, который, в свою очередь, позволяет мне предоставить программе Process Explorer права администратора.

Я постоянно слежу за пиками загрузки ЦП с помощью значка программы Process Explorer на панели задач, где на зеленом и красном графиках указывается загрузка ЦП процессами пользовательского режима (приложениями) и режима ядра (операционной системой и драйверами), соответственно. Благодаря этому за последние несколько месяцев я обнаружил ряд ошибок в приложениях. Сегодня я расскажу, как с помощью программ Process Explorer и Kernrate мне удалось обнаружить проблему с драйвером стороннего разработчика и добиться устранения этой проблемы изготовителем.

Однажды я обнаружил, что работа моего нового портативного компьютера, купленного всего несколько месяцев назад, слегка замедляется. Значок программы Process Explorer на панели задачи подтверждал мои ощущения красными мини-графиками загрузки ЦП. При наведении курсора мыши на этот значок выводится название процесса, который больше всего загружает ЦП. В данном случае им оказался процесс System (системный процесс).

Первые несколько раз я замечал эту проблему, но она довольно быстро пропадала сама собой, и я не успевал найти ее причину. Тем не менее, в диалоговом окне System Information (Сведения о системе) программы Process Explorer я мог наблюдать, что пики загрузки ЦП были довольно длительными.

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

Я подозревал, что источником проблемы является какой-то драйвер устройства стороннего производителя, поэтому первым делом мне нужно было выяснить, какой именно поток загружает ЦП. Зная это, я смог бы найти виновника. Я неусыпно ждал появления признаков проблемы при переходе из одной сети в другую, а они не заставили себя ждать слишком долго. Потоки, исполняемые в рамках процесса, показаны в программе Process Explorer на странице Threads (Потоки) диалогового окна Process Properties (Свойства процесса), поэтому в следующий же раз, столкнувшись с пиком загрузки ЦП, я дважды щелкнул на процессе System и открыл страницу Threads (Потоки).

Префикс “ntkrnlpa.exe”, предваряющий начальные адреса потоков, выведенных в верхней части списка потребителей ресурсов ЦП, свидетельствует о том, что они относятся к операционной системе. Ntkrnlpa.exe - это версия ядра, загружаемая в 32-разрядных клиентских системах, поддерживающих технологию защиты No Execute, а также в серверных системах, в которых необходима адресация памяти в объеме свыше 4 ГБ. Поскольку ранее я настроил в программе Process Explorer получение символов, относящихся к образам операционной системы, с общедоступного сервера символов Майкрософт, в списке потоков, помимо прочего, были указаны имена запускавших эти потоки функций. Наиболее активные потоки оказались запущены функцией ExpWorkerThread, что свидетельствовало о том, что это рабочие потоки, действующие от имени системы и драйверов устройств. Вместо того чтобы создавать специальные потоки, потребляющие ресурсы памяти, система и драйверы могут делегировать исполнение задач рабочим потокам операционной системы из общего пула.

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

Дело в том, что в ОС Windows Vista процесс System относится к числу «защищенных процессов», которые блокируют любой доступ к своим потокам и к занимаемой ими памяти. Защищенные процессы были реализованы с целью подкрепления технологии управления цифровыми правами (DRM). Они позволяют поставщикам видео высокой четкости сохранять ключи шифрования этих материалов так, что вероятность исполнения администратором средств снятия защиты цифровых прав, доступа к процессу и считывания ключей сводится к минимуму.

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

Подумав, что если программа Kernrate справится с задачей идентификацией драйвера устройства, символы мне не понадобятся, я запустил ее без аргументов. Несмотря на то, что версии программы Kernrate, официально поддерживающей ОС Windows Vista, на данный момент не существует, в 32-разрядных выпусках Windows Vista работает версия этой программы для ОС Windows XP - Kernrate_i386_XP.exe. Кстати сказать, аналогичные задачи профилирования позволяет решать недавно выпущенная служебная программа xperf - она работает в средах Windows Vista и Windows Server 2008, в том числе в 64-разрядных версиях этих ОС. Я запустил профилирование в период заметного увеличения нагрузки на ЦП, а затем, нажав сочетание клавиш CTRL+C, вывел результат на консоль.

В первой позиции списка были указаны обращения к ядру, а вот на втором месте оказался неопознанный драйвер b57nd60x. Поскольку большинство файлов драйверов находится в каталоге %systemroot%\system32\drivers, можно было открыть этот каталог и просмотреть свойства файла с помощью проводника. Но поскольку передо мной была программа Process Explorer, я решил воспользоваться более оперативным способом узнать производителя и версию драйвера. Для этого я открыл процесс System в представлении библиотек DLL. В этом представлении перечисляются библиотеки DLL и файлы, отображенные на адресное пространство процессов пользовательского режима, но применительно к процессу System выводится список модулей ядра, в том числе драйверов, загруженных в системе. Это представление помогло мне установить, что искомый драйвер относится к сетевой карте моего портативного компьютера. Как выяснилось, производитель драйвера - компания Broadcom, а версия - 10.10.

Итак, я знал, что повышенное потребление ресурсов ЦП вызывает драйвер производства компании Broadcom. Теперь нужно было узнать, доступна ли его обновленная версия. Я зашел на веб-узел компании Dell, ознакомился со списком доступных файлов для своей системы, но ничего путного не обнаружил. Подозревая, что производитель не знает о проблеме, я решил обратиться непосредственно к нему. С помощью рабочей группы Майкрософт по взаимодействию с экосистемой оборудования я связался с ответственным специалистом компании Broadcom по драйвером, отравил ему по электронной почте подробное описание симптомов и изложил свои выводы. Он переслал мое письмо разработчику драйвера, который, в свою очередь, подтвердил, что причина описанного мною поведения неизвестна, а через несколько дней отправил мне отладочную версию драйвера с открытыми именами символов с тем, чтобы я выполнил профилирование программой Kernrate и, просмотрев журнал, сообщил, какие функции драйвера активны в периоды пиковой загрузки процессора. Через несколько дней проблема проявилась вновь, и я отправил разработчику выходные данные программы kernrate с информацией об активных функциях.

По словам разработчика, судя по предоставленной мною трассировке, драйвер недостаточно эффективно взаимодействовал с шиной PCIe при обработке определенных запросов, причем проблема, по всей видимости, усугубилась в условиях специфической конфигурации оборудования. Он предоставил мне для испытаний новый драйвер, и по прошествии нескольких недель подробного мониторинга я сообщил ему, что проблема, по всей видимости, решена. Обновленный драйвер пока что не опубликован на веб-узле службы поддержки компании Dell, но я полагаю, что это случится в ближайшем будущем. Так мне удалось раскрыть очередное дело, на этот раз с помощью программ Process Explorer и Kernrate, а также отзывчивого разработчика драйверов из компании Broadcom.

Если вам нравятся записи в моем блоге, посвященные устранению неполадок, рекомендую ознакомиться с веб-трансляцией моего выступления на конференции TechEd/ITforum из серии «Дело о необъяснимом». На протяжении 75-минутной трансляции я привожу примеры устранения неполадок из своего опыта, в том числе пример, который рассмотрен в сегодняшней записи, и многие другие, среди которых и те, которые я еще не описывал. В завершающей части своего сообщения я обращаюсь к аудитории с предложением отправлять мне снимки экрана, журналы и описания успешных случаев устранения неполадок, обещая взамен отправить каждому автору экземпляр своей книги «Внутреннее устройство Windows» с автографом. Предложение еще в силе, так что если у вас есть успешный опыт расследований, зафиксируйте его документально, пришлите мне, и получите бесплатную книгу. Я уже получил немало разного рода историй, и в следующей записи поделюсь с вами одной из них, которую мне прислал один из зрителей веб-трансляции. При непосредственной помощи программы Process Monitor ему удалось решить проблему, связанную с веб-сервером.

Наконец, если вы хотите увидеть мои выступления вживую, приезжайте на конференцию TechEd US/IT Pro, которая пройдет в июне в Орландо. Там я буду выступать с докладами из серий «Дело о необъяснимом», «Изменения в ядре ОС Windows Server 2008» и «Границы системы безопасности Windows». Надеюсь, увидимся!

Оригинал записи