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

Как вы уже, наверное, догадались, читая мой блог и другие публикации, мне всегда нужно знать наверняка, что происходит на моих компьютерах. Когда какой-то процесс сильно загружает ЦП, вызывает нехватку оперативной памяти или снижает производительность работы жесткого диска - все это для меня важно. Своей бдительностью я не только добиваюсь нормальной работы своих компьютеров - порой она позволяет мне замечать проблемы с производительностью и надежностью в коде ОС 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». Надеюсь, увидимся!

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