Windows performance toolkit windows 10 как пользоваться - Доктор Windows

Вы тут: Главная → Windows → Этапы загрузки Windows под микроскопом Windows Performance Toolkit

Составить полное представление о загрузке Windows можно с помощью набора Windows Performance Toolkit. Утилиты командной строки xbootmgr и xperf позволяют создать подробный отчет о запуске системы и представить его в графическом и текстовом виде для всестороннего анализа загрузки.

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

Однако эти простые способы не позволяют выявить скрытые факторы или проблемы, замедляющие загрузку Windows. Теперь настало время познакомиться поближе со всеми этапами загрузки Windows и провести их детальный анализ с помощью Windows Performance Toolkit (WPT).

[+] Сегодня в программе

Загрузка и установка WPT

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

Посмотреть устаревшие инструкции по установке WPT для Windows 7

Подготовка к работе

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

Прежде чем выполнить первую команду, создайте точку восстановления системы и убедитесь, что у вас есть под рукой установочный диск / флэшка или диск восстановления. Предупреждение вовсе не дежурное, ибо случаи неадекватного поведения WPT были отмечены у нас на форуме, да и сам я их видел.
Включите автоматический вход в систему, чтобы задержка на ввод пароля не влияла на измерения.
Убедитесь, что на разделе есть несколько гигабайт свободного пространства, поскольку при анализе могут создаваться файлы большого размера.

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

Сбор данных

Все логи загрузки лучше хранить в одной папке, допустим, C:Trace. Откройте командную строку с полными правами и введите:

md c:Trace

Здесь и далее я буду использовать пути применительно к этой папке и стандартной установке WPT в 32-разрядной Windows 7. При необходимости изменяйте пути на свои.

Закройте все программы и сохраните все документы. Процесс сбора данных о загрузке системы запускается одной командой:

xbootmgr -trace boot -traceFlags BASE+CSWITCH+DRIVERS+POWER -resultPath C:Trace

Аналогичные команды можно использовать для диагностики

гибернации:

xbootmgr -trace hibernate -traceFlags BASE+CSWITCH+DRIVERS+POWER -resultPath C:Trace

сна:

xbootmgr -trace standby -traceFlags BASE+CSWITCH+DRIVERS+POWER -resultPath C:Trace

выключения:

xbootmgr -trace shutdown -noPrepReboot -traceFlags BASE+CSWITCH+DRIVERS+POWER -resultPath C:Trace

Примечание. Если при выполнении команд вы видите сообщение «xbootmgr не является внутренней или внешней командой», установка была неудачной. Вы найдете решение в этой теме форума.

Вернемся к загрузке, однако. Компьютер будет перезагружен. Если после входа в систему вы увидите запрос UAC от xbootmgr, разрешите утилите продолжить работу. Через две минуты вы увидите примерно такое окно.

Когда оно исчезнет, в папке C:Trace должно быть три файла, как показано на рисунке ниже.

Если вы вместо файла boot_BASE+CSWITCH+DRIVERS+POWER_1.etl видите там два других файла с расширением ETL, это может означать, что утилита еще работает, над их объединением в один – подождите несколько минут. При отсутствии изменений выполните в командной строке

xperf –stop

и перезагрузите систему. После чего попробуйте заново запустить сбор данных.

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

xbootmgr -remove

Анализируемые файлы и первый взгляд на этапы загрузки

Для анализа используются два файла: ETL и создаваемый из него XML.

ETL

Я думаю, что вы уже успели дважды щелкнуть файл boot_BASE+CSWITCH+DRIVERS+POWER_1.etl и полюбоваться красивыми графиками и диаграммами. В левой панели графики можно отображать и скрывать, а также переходить к ним двойным щелчком мыши.

В WPA из ADK для Windows 10 сводку этапов загрузки можно получить так. Из меню Profiles — Apply — Browse Catalog выберите FullBoot.Boot.wpaprofile. При этом автоматически открывается несколько вкладок с подборками сведений. Для отображения информации на отдельной вкладке из левой панели выберите Regions of interest — FullBoot. Получите такую диаграмму и таблицу.

В ADK для Windows 7 базовый график Boot Phases был доступен сразу

XML

Для удаленной диагностики по почте или в форуме можно создать текстовый отчет в виде XML-файла. Выполните команды:

cd c:trace
xperf /tti -i boot_BASE+CSWITCH+DRIVERS+POWER_1.etl -o summary_boot.xml -a boot

Первая переходит в папку с логами, а вторая — создает требуемый XML-файл. Для его просмотра отлично подойдет Internet Explorer!

Увеличить рисунок

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

bootDoneViaExplorer – время загрузки операционной системы вплоть до появления рабочего стола, в данном примере 37 секунд
bootDoneViaPostBoot – полное время загрузки системы, рабочего стола и всех программ в автозагрузке, в данном примере 64 секунды (из этой цифры следует вычесть 10 секунд, в течение которых определяется полное бездействие системы)

Время первой части складывается из основных этапов загрузки операционной системы (обведены синим), вплоть до начала загрузки рабочего стола. В уже знакомом вам событии 100 журнала Diagnostics-Performance длительность этого этапа записывается в параметре MainPathBootTime.

Разница между этими двумя частями – это время от начала загрузки рабочего стола, до его полной готовности. В событии 100 журнала Diagnostics-Performance — это BootPostBootTime.

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

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

Увеличить рисунок

Давайте рассмотрим все этапы подробно.

Этап OSLoader

Этап OSLoader следует сразу после инициализации BIOS. Визуально он начинается после заставки и диагностических экранов BIOS, а заканчивается примерно с появлением экрана «Загрузка Windows».

На этапе OSLoader:

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

Длительность этапа отражает значение параметра osLoaderDuration в узле timing XML-файла. Обычно, она в находится в пределах 2-3 секунд.

Этап MainPathBoot

Визуально этап MainPathBoot начинается с экрана «Загрузка Windows» и завершается при появлении рабочего стола. Если не настроен автоматический вход в систему, длительность этого этапа увеличивается за счет времени, которое требуется для ввода пароля.

Во время этапа MainPathBoot происходит основная работа по загрузке операционной системы:

инициализируется ядро
происходит определение устройств Plug and Play (PnP)
запускаются службы
выполняется вход в систему
инициализируется Explorer, т.е. система готовится к загрузке рабочего стола

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

Фаза PreSMSS

Визуально фаза PreSMSS начинается примерно с экрана «Загрузка Windows», но ее окончание невозможно определить на глаз.

Фаза PreSMSS (в графическом представлении WPT она обозначена как Pre Session Init) начинается с инициализации ядра. Во время нее:

ядро инициализирует структуры данных и компоненты, а затем запускает диспетчер PnP
диспетчер PnP в свою очередь инициализирует драйверы BOOT_START, которые были загружены с помощью winload.exe на этапе OSLoader
когда диспетчер PnP обнаруживает устройство, он загружает необходимый драйвер и выполняет его инициализацию

Диагностика

Если фаза занимает много времени, ищите в XML-файле в узле <PNP> драйвер, который долго загружается. Диагностику в графическом режиме я покажу на примере следующей фазы.

Фаза SMSSInit

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

Фаза SMSSInit (в графическом представлении WPT она обозначена как Session Init) начинается с того, что ядро передает контроль диспетчеру сессий (smss.exe). Во время этой фазы система:

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

Фаза завершается с передачей контроля процессу winlogon.exe.

Диагностика

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

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

Более точную диагностику можно провести с помощью summary_boot.xml, где в узле PNP есть длительность запуска каждого драйвера. Впрочем, в Windows 10 он иногда отсутствует, и я не знаю, от чего это зависит и как это форсировать.

⚠ Показанного ниже графика Driver Delays в WPT больше нет, но во времена Windows 7 его можно было анализировать примерно так:

На графике Boot Phases выделите фазу Session Init и выберите из контекстного меню команду Clone Selection. Выбранный период будет выделен на всех активных графиках.
На графике Driver Delays щелкните правой кнопкой мыши и выберите из меню команду Set Delay Threshold. Она позволяет отфильтровать драйверы по времени задержки. Введите, например 2000, чтобы отобразить драйверы, загружавшиеся дольше двух секунд.

Увеличить рисунок

Вы увидите все драйверы, загружавшиеся в фазе Session Init дольше заданного времени. У меня вся фаза занимает 6 секунд, и двухсекундная задержка драйверов является нормальной. Но если у вас проблемы в этой фазе, с помощью фильтра вы сразу увидите, какой драйвер их вызывает.

Фаза WinLogonInit

Визуально фаза WinLogonInit начинается перед появлением экрана приветствия, а завершается перед появлением рабочего стола.

Фаза WinLogonInit начинается сразу после запуска winlogon.exe. Во время этой фазы:

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

Фаза завершается запуском оболочки Windows — процесса explorer.exe.

Диагностика

Во время фазы WinLogonInit выполняется множество параллельных операций. На многих системах она характеризуется нагрузкой на процессор и большим количеством операций ввода-вывода (I/O). Длительность фазы во многом зависит от поведения служб.

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

Для выявления проблемной службы удобнее всего использовать графические возможности WPT. Откройте ETL-файл двойным щелчком мыши и прокрутите отчеты вниз до графика запуска служб.

Увеличить рисунок

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

Apache 2.2
MySQL
TeamViewer

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

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

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

Wsearch все равно запускается дольше других служб, но уже всего 8 секунд вместо 30, что не дает мне достаточно оснований к ней придираться.

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

Фаза ExplorerInit

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

В фазе ExplorerInit:

сначала запускается процесс explorer.exe
затем система создает процесс диспетчера окон рабочего стола (DWM)
DWM инициализирует рабочий стол и отображает его

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

Диагностика

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

Этап PostBoot

Этап PostBoot начинается после появления рабочего стола и завершается после того, как будет определено бездействие системы.

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

Средства WPT определяют бездействие системы по следующему алгоритму. Каждые 100 мс проверяется наличие активности в системе. Если бездействие системы составляет не менее 80% (за исключением низкоприоритетных процессов и дисковой активности), считается, что в этом интервале система бездействует. Проверка продолжается до тех пор, пока не наберется 10 секунд бездействия. Поэтому, определяя общее время загрузки системы, вычитайте из значения bootDoneViaPostBoot 10000 мс, т.е. 10 секунд.

Диагностика

На этапе PostBoot запускаются приложения, находящиеся в автозагрузке. Чтобы сократить длительность этого этапа, нужно навести там порядок. В графическом представлении WPT используйте график Process Lifetimes, чтобы увидеть все процессы, которые запускаются или продолжают запуск на данном этапе.

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

Источник

Модернизация приложений

Windows Performance Toolkit: базовые сведения

Основы использования утилиты XPerf

Получение информации о системе

XPerf и визуализация стека

В предыдущих частях данной статьи мы познакомились с техникой, позволяющей избежать утечек памяти, предотвратить зависание приложений, обсудили использование механизмов Application Restart and Recovery и Windows Error Reporting, а также узнали о возможностях утилиты Application Verifier.

В этой и последующих частях мы рассмотрим, как проводить анализ производительности системы и приложений с помощью средств, включенных в состав Windows Performance Toolkit. Эти средства позволяют получить детальную информацию об использовании ресурсов системы — процессора, диска, памяти, сети и т.п., которую можно применять для выявления проблем с повышенной утилизацией ресурсов, их «утечками», задержками в реакции системы, сервисов, процессов и приложений на системные запросы и проблемы, влияющие на эффективное использование подсистемы питания.

Windows Performance Toolkit доступен на клиентских и серверных операционных системах — Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2 — и поддерживается для платформ x86, x64 и ia64. Набор утилит Windows Performance Toolkit распространяется в составе Windows SDK — после установки SDK из каталога BIN необходимо установить версию Windows Performance Toolkit, подходящую для вашей платформы, — wpt_x86.msi, wpt_x64.msi или wpt_ia64.msi соответственно.

Дополнительную информацию по Windows Performance Toolkit можно получить на сайте, посвященном производительности, — он располагается адресу: http://msdn.microsoft.com/en-us/performance/default.aspx.

Windows Performance Toolkit: базовые сведения

В основе Windows Performance Toolkit лежат две утилиты: XPerf, которая служит для активации сбора информации, и XPerfView, используемая для визуального анализа информации о производительности. Взаимодействие XPerf и XPerfView с системными компонентами — в первую очередь с подсистемой Event Tracing for Windows (ETW) — показано на рис. 1.

Рис. 1. Взаимодействие утилит XPerf и XPerfView с системными компонентами

В общем случае работа с утилитами XPerf и XPerfView происходит следующим образом:

с помощью утилиты XPerf включаем протоколирование событий на уровне ETW;
выполняем интересующие нас операции, процессы и т.п.;
с помощью утилиты XPerf завершаем сессию протоколирования;
выполняем обработку информации — добавление к ETL-файлу, создаваемому подсистемой ETW, системной информации и символов;
просматриваем и анализируем результат с помощью утилиты XPerfView (рис. 1).

Основы использования утилиты XPerf

Базовые операции по сбору информации используют подсистему протоколирования событий на уровне ядра операционной системы. Для того чтобы узнать, какие провайдеры (поставщики информации) доступны для данной версии операционной системы, можно выполнить следующую команду (здесь и далее применяется интерфейс командной строки с повышенными привилегиями: при вызове CMD. EXE необходимо нажать правую кнопку мыши и выполнить команду Run as Administrator):

C:>xperf –providers

Сокращенный результат выполнения данной команды показан на рис. 2.

Рис. 2. Получение списка провайдеров

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

Для получения списка провайдеров информации только на уровне ядра (Kernel Mode Providers) можно выполнить следующую команду:

C:>xperf –providers K

Результат выполнения данной команды показан на рис. 3.

Рис. 3. Получение списка Kernel Mode Providers

Флаги (Kernel Flags) отвечают за сбор информации об отдельных группах операций — например создание и удаление процессов, операции вводавывода и т.п. Группы (Kernel Groups) включают комбинации флагов и используются для анализа работы определенных подсистем. Для нашего первого эксперимента с утилитой XPerf мы выберем группу DiagEasy, которая содержит следующие флаги:

PROC_THREAD+LOADER+DISK_IO+HARD_FAULTS+DPC+INTERRUPT+CSWITCH+PERF_COUNTER

Описание этих флагов показано в таблице.

Выполним следующую команду для протоколирования событий на уровне ETW:

C:>xperf –on DiagEasy

Эта команда начинает сбор данных в файл с именем “kernel.etl”, который по умолчанию располагается в корне диска С:. Можно изменить имя файла с помощью опции -f <filename> — это необходимо, например, при анализе операций вводавывода, чтобы создание и заполнение файла трассировки не вносило дополнительных помех (в таком случае нужно указать другой диск для хранения создаваемого файла). Подсистема протоколирования использует буфер с размером по умолчанию 64 Кбайт — минимально применяется 64 буфера, максимальное число одновременно используемых буферов — 320.

Запустим, например, Internet Explorer и откроем в нем какойнибудь сайт. После этого завершим протоколирование с помощью команды:

C:>xperf –d trace.etl

Выполнение данной команды займет некоторое время (порядка 1-2 мин), так как системе требуется объединить данные, собранные ETW, с метаданными и другой информацией и сформировать соответствующий файл — в нашем примере это trace.etl. Теперь выполним команду:

C:>xperf trace.etl

В результате откроется окно Windows Performance Analyzer — утилиты для визуального анализа результатов, собранных с помощью утилиты XPerf. Аналогичный результат можно получить, выполнив команду:

C:>xperfview trace.etl

Утилита Windows Performance Analyzer графически отображает собранную информацию в виде ряда экранов: CPU Usage by Process, Disk I/O, Disk Utilization, Process Lifetimes, DPC CPU Usage, Interrupt CPU Usage, Hard Faults, Generic Events и других, включением или отключением которых можно управлять из меню (рис. 4).

Рис. 4. Графический анализ информации

Выбор типов графиков осуществляется с помощью всплывающего меню Frame List, которое вызывается при нажатии кнопки в левой части экрана.

Если мы хотим получить информацию только по интересующему нас процессу, то на графике CPU Usage by Process необходимо выбрать кнопку Processes (в правой части графика) и процесс — в нашем примере это IEXPLORE.EXE.

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

Рис. 5. График загрузки центрального процессора

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

Давайте обсудим, что мы узнали из приведенного выше примера:

сбор данных о событиях уровня ядра можно включать и отключать в любое время. Нет необходимости в перезагрузке системы, повторном подключении к ней, перезапуске процессов и т.п. — события уровня ядра, а также любые ETW-события могут использоваться динамически, по мере необходимости;
в отличие от утилит, которые динамически отображают состояние системы, XPerf служит для сбора информации о событиях, произошедших на определенном отрезке времени, и ее последующего анализа;
возможность сбора данных для их последующего анализа позволяет собирать данные на одном компьютере, а анализировать их — на другом, например в тестовой лаборатории или для сбора данных на Windows XP и их анализа на Windows Vista или Windows 7; это необходимо, так как обработка результатов не поддерживается в Windows XP;

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

Получение информации о системе

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

C:> xperf –i trace.etl –a sysconfig

Вывод будет произведен в консоль. Если необходимо сохранить данные в файле, выполняется операция перенаправления вывода:

C:> xperf –i trace.etl –a sysconfig >c:analysissysconfig.txt

Пример фрагмента отображаемой информации показан на рис. 6.

Рис. 6. Получение информации о конфигурации системы

Используя Windows Performance Analyzer, информацию о конфигурации системы можно получить с помощью команды Trace → System Configuration (рис. 7).

Рис. 7. Информация о конфигурации системы

XPerf и визуализация стека

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

Для того чтобы воспользоваться функцией визуализации стека, необходимо загрузить отладочные символы для операционной системы (PDB-файлы), на которой проводится сбор информации о приложениях, процессах и т.п. Их можно либо загрузить с сайта по адресу: http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx и самостоятельно установить на локальном компьютере (по умолчанию символы устанавливаются в каталог c:windowssymbols), либо использовать онлайновую загрузку со специального сервера компании Microsoft. И в том, и в другом случае необходимо указать местоположение отладочных символов с помощью переменной среды _NT_SYMBOL_PATH. Вот пример команды, устанавливающей значение этой переменной (команда должна быть введена одной строкой):

C:>set _NT_SYMBOL_PATH=

srv*C:symbols*http://msdl.microsoft.com/downloads/symbols

Адрес сайта, указанный в приведенной выше команде, — это «сервер символов» компании Microsoft. Адрес локальной папки, помещенный между символами «*», указывает на локальное хранилище символов, куда будут помещены загруженные с сервера символы.

При анализе собственных приложений также необходимо указать местоположение PDB-файлов для конкретного приложения. Адрес локальной/удаленной папки добавляется к приведенной выше команде set через разделитель «;»:

C:>set _NT_SYMBOL_PATH=

srv*C:symbols*http://msdl.microsoft.com/downloads/symbols;

c:ProductsVersions1.0

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

C:>xperf –on PROC_THREAD+LOADER+INTERRUPT+DPC+PROFILE

–stackwalk profile

Затем запустим интересующее нас приложение, выполним в нем необходимые операции и завершим сессию сбора информации командой:

C:>xperf –d test.etl

После этого, как и в предыдущем примере, запустим Windows Performance Analyzer для визуального анализа собранной информации:

C:>xperf test.etl

Визуализация стека включается на графике CPU Sampling by Process. Первая операция — это выполнение команды Load Symbols (в случае загрузки символьной информации с сервера выполнение этой команды может занять некоторое время), затем — команды Summary Table. В отдельном окне будут показаны результаты вызова функций — в данной версии XPerf поддерживается до 16 уровней вложенности.

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

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

Рис. 8. Визуализация стека

Еще одна интересная возможность — это анализ не всего стека вызовов, а только той его части, которая, например, занимала больше всего ресурсов. Для этого на графике CPU Sampling by Process необходимо выбрать интересующий нас временной период и перестроить для него таблицу вызовов с помощью команды Summary Table. Также отметим, что для сравнения можно выбрать несколько интервалов и анализировать их в одновременно открытых окнах.

Использование символьной информации для визуализации стека вызовов является мощным средством анализа работы процессов и приложения. Вот несколько рекомендаций по успешному применению этой возможности:

для загрузки символов необходимо использовать либо команду Load Symbols в Windows Performance Analyzer, либо параметр -symbols при вызове утилиты XPerf;

для получения информации о параметре -symbols применяйте команду:

C:>xperf –help symbols

убедитесь в том, что правильно установлено значение переменной среды:_NT_SYMBOL_PATH;

файл трассировки должен быть либо создан с помощью опции -d, либо объединен с другими файлами трассировки на том же компьютере с помощью опции -merge;

важно, чтобы символы для компонентов операционной системы и приложения относились именно к установленной на компьютере версии. Для проверки используйте утилиту symchk.exe из набора утилит Debugging Tools for Windows:

C:> symchk /v <локальный файл > /s <символы.pdb>

для проверки соответствия двоичных файлов установленным на компьютере символам применяйте утилиту fc:

C:> fc /b <локальный файл> <файл символов>

всегда указывайте, как минимум, флаги PROC_THREAD+LOADER — они позволяют собрать базовую информацию о жизненном цикле процесса и виртуальных адресах загрузки образов в память. Это нужно для того, чтобы убедиться в том, что события, связанные с процессами: Create, Delete, Start Rundown, End Rundown и образами Load, Unload, Start Rundown, End Rundown, присутствуют в таблице, получаемой с помощью следующей команды:

C:> xperf -i имя_файла.etl -a tracestats -detail

Результат выполнения данной команды показан на рис. 9.

Рис. 9. События, связанные с процессами

КомпьютерПресс 05’2012

Источник

WPTx64 — что это?
Можно ли удалить?
Заключение

Приветствую друзья! Иногда можно посмотреть список установленного софта на ПК и удивиться наличию неизвестных программ. Откуда они? Ответ прост — при установке софта часто вместе с ним ставятся и дополнительные компоненты. Особенно это касается тяжелого софта, например Microsoft Office, ПО Adobe.

Набор средств для оценки производительности Windows.

Данный компонент необходим для работы софта SOLIDWORKS (подробности здесь).

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

Официальная информация от Microsoft.

Возможно компонент имеет отношение к таким встроенным инструментам Windows как Системный монитор и Монитор ресурсов.

Разберем название:

WPT — Windows Performance Toolkit, переводится как инструмент производительности Windows.
x64 — разрядность системы, вероятно для 32-битной операционки было бы название WPTx86.

WPTx64 является частью пакета SDK и комплекта средств оценки и развертывания Windows. Инфа взята с офф сайта, как понимаю — это часть операционки, поэтому удалять не стоит.

Инструмент Windows Software Development Kit, при помощи которого и можно установить данный компонент:

Устанавливается в эту папку:

C:Program Files (x86)Windows Kits8.1Windows Performance Toolkit

Или просто в Program Files, без x86. Полное название установщика может быть таким — WPTx64-x86_en-us.

WPTx64 — можно ли удалить?

Важно: при установленном ПО SOLIDWORKS удалять WPTx64 не рекомендуется!

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

Откройте панель управления. Например так: зажмите Win + R и напишите просто команду control или control panel. Нажмите ОК.
Найдите значок Система, запустите.
Выберите Защита системы.
Выберите системный диск и нажмите кнопку Создать.
Укажите название точки, например До удаления WPTx64. Нажмите создать.

Точка восстановления позволит в случае проблем после удаления — вернуть ПК к прежнему состоянию, когда программа WPTx64 еще не была удалена.

После — можно удалять WPTx64:

Зажмите Win + R, вставьте команду appwiz.cpl, нажмите ОК.
Откроется окно установленного софта.
Найдите WPTx64, нажмите правой кнопкой и выберите Удалить.
Следуйте инструкциям на экране, обычно нужно нажимать Далее/Next/Удалить/Uninstall.

Окно Программы и компоненты — здесь ищем WPTx64, выбираем и удаляем. Кстати здесь в списке видим также и софт SOLIDWORKS.

Заключение

WPTx64 — системный компонент оценки производительности Windows.
Можно попробовать удалить (но сперва создайте точку восстановления).
При наличии программы SOLIDWORKS — удалять компонент не нужно.

Удачи.

Источник

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

С чем мы работаем:

> Windows
Описанная здесь оптимизация запуска подходит для версий 7, 8/8.1 и 10.
> Software Development Kit
Нужная нам утилита Xbootmgr входит в состав Windows Performance Analyzer, компонента Windows SDK.
> Магнитный жесткий диск
Оптимизация с помощью функции Prefetching работает только на компьютерах с магнитными дисками.

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

Предварительная выборка в качестве ускорителя системы

Предвыборка (Prefetching) отвечает за то, чтобы Windows уже при запуске компьютера загружала важные файлы в гораздо более быструю оперативную память еще до того, как они понадобятся. Для оптимизации, однако, следует «втолковать» системе, какие файлы она должна пометить как «важные». Как именно это сделать с помощью утилиты Microsoft Xbootmgr, мы расскажем в данной статье.

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

Windows Performance Analyzer
На пересечении строчки «Post Boot» и колонки «End Time (s)» этой программы для анализа вы узнаете, сколько времени занимает загрузка вашего компьютера. На нашей системе она длилась 24,3 секунды

Xbootmgr входит в состав набора Windows Performance Toolkit, который, в свою очередь, является частью официального комплекта Software Development Kit (SDK). Впрочем, от вас не требуется устанавливать SDK целиком. Достаточно при установке выбрать необходимые опции.

Результаты, достигнутые с помощью Xbootmgr, зависят от того, насколько хорошо Windows уже оптимизировала ваш ПК. Компьютеры с магнитными дисками после этого способны запускаться за 30 секунд — имеется в виду интервал между включением и тем моментом, когда вы действительно можете работать в системе. Но даже если загрузка занимает меньше минуты, Xbootmgr все равно дает ощутимое ускорение: так, наш тестовый компьютер сначала запускался за 24,3 секунд, после — за 20,9.

Подготовка к оптимизации системы

Подготовка Windows
Чтобы Xbootmgr смогла ускорить компьютер, функции Prefetcher и Superfetch должны быть задействованы как в реестре , так и в Службах Windows

Для начала проверьте в реестре, активна ли предварительная выборка и запущена ли соответствующая служба Windows. Для этого нажмите на клавиши «Win+R» и введите «regedit». Теперь в реестре перейдите к ключу «HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSessionManagerMemory ManagementPrefetchParameters». В правой части окна дважды щелкните по DWORD-параметру «EnablePrefetcher» и установите его на «3». Повторите процедуру для параметра «EnableSuperfetch».
После этого убедитесь, что включена служба Windows «Superfetch». Нажмите на «Win+R», но теперь введите «services.msc». После вопроса «Контроля учетных записей» откроется окно «Службы». Найдите строчку «Superfetch» и дважды щелкните по ней. Вы увидите «Свойства: Superfetch». Убедитесь, что на вкладке «Общие» для «Типа запуска» выбран вариант «Автоматически». Под «Состоянием» также должно стоять «Выполняется». В противном случае нажмите на «Запустить». После внесения изменений перезагрузите компьютер.

Загрузка Windows SDK

Из комплекта Windows SDK объемом в несколько гигабайт требуется загрузить лишь легкий набор Windows Performance Toolkit (130 Мбайт)

Для установки Windows Performance Toolkit и Xbootmgr вам понадобится подходящий для вашей Windows пакет Software Development Kit. Пользователи Windows 10 могут скачать его по адресу https://developer.microsoft.com/ru-ru/windows/downloads/windows-10-sdk. Если у вас стоит Windows 7 или 8, зайдите на страницу https://developer.microsoft.com/ru-ru/windows/downloads/windows-8-sdk. В обоих случаях у вас скачается файл объемом примерно 1 Мбайт. Запустите его двойным щелчком мыши, чтобы вызвать «Мастера установки». Теперь нажимайте на «Next», пока не дойдете до «Условий лицензионного соглашения». Подтвердите свое согласие и в следующем окне под заголовком «Select the features you want to install» снимите все флажки, оставив только «Windows Performance Toolkit». По нажатию на «Install» программа скачает все необходимые файлы и установит их на ваш компьютер.

Замеряем точное время запуска

Утилита Xbootmgr по запросу из командной строки точно замеряет время загрузки компьютера. После отправки вышеуказанной команды компьютер перезагружается. Заранее закройте все открытые файлы.

Xbootmgr — это мощная утилита для создания детальных протоколов с указанием времени загрузки компьютера. Папки, в которые будет сохраняться эта информация, вам придется заранее создать вручную в Проводнике. В нашем случае мы сделали на диске «C:» папку «temp», в ней сохранили еще две подпапки, «Before» и «After». Для того чтобы программа Xbootmgr действительно смогла измерить точное время, необходимо активировать автоматический вход в Windows — но только на время! Для этого нажмите «Win + R» и введите «netplwiz». В новом окне снимите флажок рядом с записью «Требовать ввод имени пользователя и пароля». Подтвердите свое решение нажатием на «ОК» и введите свое имя пользователя и дважды пароль.

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

Оптимизация автозагрузки

Проблема, с которой не может справиться Xbootmgr, — слишком большое количество записей автозагрузки, которые накапливаются со временем. Для ее решения вам потребуется отдельная утилита, например, бесплатная Autoruns от Microsoft, которая составляет список всех записей и позволяет удобно их отключить.
> Запустите Autoruns с правами администратора и скройте все строчки, связанные с Microsoft. Для этого откройте «Options» и поставьте флажок рядом с записью «Hide Microsoft Entries».
> Перейдите к вкладке «Logons» и снимите все флажки с лишних строчек. Правой кнопкой мыши щелкните по программе, в чьем предназначении вы не уверены, и выберите «Search Online …». После отключения всех ненужных строчек автозагрузки закройте утилиту и перезагрузите компьютер.

Ускоряем запуск Windows

Предназначенная для измерения времени запуска утилита Xbootmgr не располагает графическим интерфейсом, из-за чего не особо удобна в использовании: управление осуществляется с правами администратора через окно командной строки. Полученные от утилиты протоколы вы затем сможете открыть и с комфортом проанализировать в Windows Performance Analyzer. Чтобы запустить Xbootmgr в Windows 10, кликните правой кнопкой мыши по иконке меню «Пуск» в левом нижнем углу и выберите «Командная строка (администратор)». Для Windows 7 вызовите «Пуск | Программы | Стандартные» и щелкните правой кнопкой мыши по «Командной строке». Выберите «Запуск от имени администратора». В обоих случаях положительно ответьте на запрос «Контроля учетных записей».

Завершите все задачи на ПК и сохраните открытые файлы. Затем введите команду «xbootmgr -trace boot -resultPath C:tempBefore». Спустя несколько секунд компьютер перезагрузится без дополнительных вопросов. Параметры, расположенные после названия программы, задают, что она должна делать. Например, «trace boot» отвечает за то, чтобы Xbootmgr измеряла время загрузки. «-resultPath» и следующий за ним путь к папке — в какую директорию программа сохранит файл протокола.

После перезагрузки Windows автоматически откроется небольшое окно с обратным отсчетом на 120 секунд. Не нажимайте здесь кнопку «Finish», а подождите, пока окно не закроется само. Также не запускайте никаких других программ, поскольку это может исказить результаты измерений. По завершении всего процесса вы найдете файл протокола в папке «C:tempBefore». Он имеет расширение «.ETL». Теперь запустите Проводник Windows, перейдите к папке «C:tempBefore» и двойным щелчком по файлу ETL откройте его в Windows Performance Analyzer.

Детальный анализ результатов измерений

Нажмите на маленький треугольник рядом с пунктом «Other», а затем произведите двойной щелчок по «Boot Phases». В верхней части экрана вы увидите различные фазы, которые проходит система Windows при загрузке. Каждая из них представлена в виде цветной полоски. Чем она длиннее, тем дольше длилась данная фаза. Таблица ниже сообщит более подробные значения. Общее время, которое занял процесс загрузки, вы увидите в строке «Post Boot» колонки «End Time (s)». Нашему компьютеру понадобилось чуть более 24 секунд для прохождения пяти фаз запуска.

В дальнейшем Xbootmgr перезагрузит ваш компьютер еще пять раз. В это время вы не сможете давать ему другие поручения. После каждого запуска даст о себе знать «Контроль учетных записей» и потребует подтверждения. Если это покажется вам слишком утомительным, на время измерений отключите защитный механизм. Для этого правой кнопкой мыши щелкните по значку меню «Пуск» и откройте Панель управления. Перейдите к «Учетным записям пользователей» и в следующем окне снова к «Учетным записям пользователей». Выберите пункт «Изменить параметры контроля учетных записей» и перетяните ползунок до конца вниз. Запомните первоначальную позицию, чтобы после оптимизации вернуть на нее ползунок.

Переход на SSD

Если время загрузки компьютера так и не сократилось, перенесите Windows на SSD и используйте его в качестве загрузочного накопителя.
> Программа EaseUS Partition Master Professional оснащена легким в управлении Мастером, который скопирует вашу Windows на SSD. Если у вас ноутбук, рекомендуем переходник с USB на SATA, который сейчас стоит не больше 700 рублей. К ПК вы можете подключить SSD напрямую через SATA-порт.
> Запуск переноса в EaseUS Partition Master Professional осуществляется из пункта «Миграция OS на SSD/HDD». Следуйте указаниям Мастера, а затем поменяйте в компьютере старый жесткий диск на новый SSD. Наш компьютер после оптимизации с помощью Xbootmgr и автозагрузки, а также переноса системы на SSD стал загружаться довольно быстро — за 36 секунд.

Оптимизация процесса загрузки

Чтобы начать оптимизацию, снова откройте окно командной строки с правами администратора и введите здесь команду «xbootmgr -trace boot -prepSystem -verboseReadyBoot -resultPath C:temp». Оба этих параметра («-prepSystem» и «-verboseReadyBoot») перемещают загрузочные файлы Windows на край жесткого диска и оптимизируют предварительную выборку. И в этом случае компьютер практически сразу же после отправки команды перезагрузится. Подождите, пока Xbootmgr не закончит шестую перезагрузку. При первой ядро анализирует поведение компьютера при запуске. При второй происходит дефрагментация загрузочных файлов и перемещение их на крайние дорожки жесткого диска. Следующие перезагрузки служат оптимизации порядка загрузки. Весь процесс, как правило, занимает от одного до двух часов. Не прерывайте его, даже если после сообщения «Preparing system …» кажется, что ничего не происходит уже вечность. Особенно долго длятся две первые перезагрузки.

Это окно появляется во время измерений времени запуска программой Xbootmgr. Не закрывайте его и не нажимайте
на «Finish»

После проведения оптимизации компьютера повторно измерьте время, которое потребовалось Windows для запуска. Для этого снова откройте окно командной строки с правами администратора и введите команду «xbootmgr -trace boot -resultPath C:tempAfter». Тем самым результат измерения сохранится в подпапку «After». После проведения замеров дважды щелкните по новому файлу ETL и посмотрите, сколько времени понадобилось для загрузки системы. Наш компьютер стал запускаться за 20,9 секунды. Дополнительного ускорения можно добиться очисткой автозагрузки, а также благодаря установке твердотельного накопителя. Если вы по нашей рекомендации отключили «Контроль учетных записей» и активировали автоматический вход в Windows, по завершении оптимизации не забудьте вернуть их в исходное состояние.

После оптимизации повторно замерьте время запуска с помощью Xbootmgr. Наш тестовый компьютер стал загружаться ощутимо быстрее

Не стоит забывать и про то, что при старте системы вместе с ней запускается масса совсем не нужных пользователю программ и процессов. Это могут быть, например, сервисы справки от Adobe, программы автоматической проверки наличия обновлений, а также утилиты, которые «тихо» установились с другими программами. Отключить их загрузку можно с помощью бесплатной, но мощной программы для очистки и оптимизации — CCleaner. Установите программу, запустите ее и перейдите в раздел «Сервис | Автозагрузка». Выделите программу, которую вы хотите исключить из автозагрузки, и нажмите справа на «Выключить». Запуск отключенных программ при необходимости можно вновь включить.

В антивирусном пакете Kaspersky Internet Security 2017 интегрирован «Менеджер программ», который проконтролирует установку скрытых программ, а также выявит давно установленные ненужные приложения и предложит их удалить.

ФОТО: компании-производители; 3dsculptor/Fotolia.com

Источник

Время от времени в своей работе технический специалист сталкивается с проблемами различных этапов функционирования операционной системы Windows: проблемами загрузки, завершения, гибернации, сна и прч. В подавляющем большинстве случаев подобные инциденты проявляются в том, что операционная система долго стартует, либо долго завершается, визуально это может выражаться как непривычно долго «висящие» на экране надписи Загрузка Windows, Завершение работы либо черный экран с курсором или без при загрузке/завершении. Иногда подобные этапы могут затянуться очень уж надолго, переходя все грани приличия. К решению подобного рода проблем существует множество подходов, одни состоят в использовании проверенного временем “метода тыка”, когда отключаются стоящие в автозапуске программы, сервисы этапа загрузки, другие же являются более продвинутыми и заключаются в применении специализированного диагностического инструментария от команды Microsoft, который позволяет получить о проблеме достаточно подробную информацию. В данной статье мы будем рассматривать, пожалуй, один из самых результативных способов диагностики проблем загрузки и завершения Windows — использование утилит комплекта Windows Performance Toolkit, таких как xbootmgr, xperf, xperfview.

Сделаем небольшое отступление и поговорим об общих причинах подобного поведения системы. В общем случае, медленная загрузка/завершение Windows может быть вызвана проблемами в работе драйверов устройств (обычно сторонних), сервисов либо приложений этапа загрузки, стартующих на различных этапах загрузки ОС. Теоретически, любой компонент операционной системы, стартующий на этапах загрузки/завершения ОС, может являться источником существенного увеличения времени, требующегося для выполнения всех фаз процесса загрузки/завершения. Причиной может быть как некорректное проектирование данного программного обеспечения, так и неисправность аппаратной части компьютера. К примеру, программа может выполнять многочисленные (избыточные) обращения к реестру, что, в свою очередь, так же может являться причиной общего падения производительности.
Для того, чтобы локализовать проблему с точностью до участка кода проблемного компонента, Microsoft предлагает широкому кругу специалистов набор специализированных утилит для диагностики различных аспектов быстродействия системы, который носит название Windows Performance Toolkit. Инструментарий Windows Performance Toolkit использует технологию Трассировки Событий (Event Tracing for Windows, ETW). На самом деле, ETW это довольно обширная область знаний, изучение которой представляет особый интерес для специалиста и описание которой может развернуться на добрую серию статей, однако здесь я приведу лишь основные термины.

Event Tracing for Windows — Средство трассировки событий. Технология, предоставляющая возможность генерации (при помощи специального API) сообщений состояния для широкого спектра событий, возникающих в операционной системе Windows.

Сказать иначе, это своеобразный расширяемый механизм логирования, встроенный в систему Windows. Реализован на уровне ядра, позволяет по запросу собирать события от приложений пользовательского режима, драйверов режима ядра и непосредственно кода самого ядра. Дело в том, что во многие компоненты ядра Windows, да и некоторые драйверы устройств включена возможность отслеживания операций с целью дальнейшего использования накопленной статистики при поиске причин системных сбоев. ETW предоставляет обширнейшую информацию по функционированию, как то, переключение контекста, статистика по прерываниям, отложенные вызовы процедур (DPC), процедуры обработки прерываний (ISR), создание и уничтожение процессов и потоков, дисковый ввод-вывод, ошибки страниц, переходы процессора между режимами в рабочем состоянии (p-state), операции с реестром, и многое другое. Предоставляется возможность включать запись событий «на лету», без необходимости перезагрузки системы либо приложения. События трассировки содержат заголовок события и зависящие от поставщика (провайдера) данные, описывающие текущее состояние приложения или операции.

Провайдер (поставщик) — любой компонент системы (приложение, библиотека, ядро, драйвер, сервис), использующий API Event Trace for Windows, предоставляющий события по запросу. Определяет глобальные идентификаторы (GUID) для классов событий, данные по трассировке которых он предоставляет.

Сам по себе инструментарий Windows Performance Toolkit содержит достаточно большое количество средств диагностики, из которых, в свете решения проблем различных этапов работы операционной системы, нас будет интересовать лишь несколько приложений, это утилиты xbootmgr, xperf и xperfview.

xperf — контроллер провайдеров и сессий трассировки. Утилита командной строки, имеющая широкий функционал: контроль процесса трассировки, обработка данных трассировки (поддержка анализаторов, называемых действиями, которые генерируют отчет об отдельных составляющих трассировки), старт/останов сессий трассировки, фильтрация собираемых событий, постобработка данных трассировки (конвертация из ETL в XML, объединение данных трассировки, добавление мета-данных в трассировку). В дополнение к основному функционалу, утилита может использоваться как анализатор результатов, однако, поскольку запускается только из командной строки, для визуализации вывода все-равно использует xperfview. Интересная особенность утилиты заключается в том, что она может использоваться как отдельный трассировщик событий уровня ядра прямо в процессе работы операционной системы.
xbootmgr — контроллер провайдеров и сессий трассировки. По сути тот же xperf, предназначенный для автоматизации определенных сценариев: по заданным условиям запускает/останавливает сеансы регистрации, автоматизирует процедуры изменения состояний операционной системы, выполняет автоматическую перезагрузку системы заданное количество раз, контролирует трассировку на всем протяжении переключений состояний, позволяет коллекционировать статистику по строго определенным системным событиям (загрузка, завершение, переход в/из режим сна, ожидание).
xperfview — потребитель, получатель или визуализатор результатов производительности с графическим интерфейсом. Основное назначение — извлечение данных трассировки из файлов протоколов сессий ETW и представление их в графическом виде в форме графиков и таблиц. По моему мнению, наиболее удобный инструмент для анализа результатов трассировки.

В дальнейшем, накопленные данные трассировки могут быть использованы для отладки приложения и диагностирования проблем быстродействия. Контроллеры xbootmgr/xperf коллекционируют данные событий трассировки в специальные регистрационные файлы формата .etl.

ETL — Event Trace Logs, собственный формат данных, хранящихся в виде набора записей, содержащих ETW-заголовок отслеживаемого события, который состоит из отметки времени, идентификатора процесса и потока и класса событий. Классы представляют дополнительные данные, характерные для своих событий.

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

Установка и настройка

На более-менее живой системе установить набор Windows Performance Toolkit может посредством полного инсталлятора Windows SDK. Я уже подробно описывал процесс установки Debugging Tools for Windows, по ней можно с легкостью установить и Windows Performance Toolkit. Просто во время установки не забудьте отметить пункт «Windows Performance Toolkit». Помните, что лучше было бы установить дистрибутив, соответствующий разрядности Вашей платформы. По окончании установки рабочий каталог инструментария при установке из пакета: C:Program FilesMicrosoft Windows Performance Toolkit, при установке посредством онлайн-инсталлятора: C:Program Files (x86)Windows KitsXXWindows Performance Toolkit, хотя пути могут в будущих дистрибутивах и измениться.
Несколько сложнее дела обстоят с системой, в которой имеются проблемы загрузки в нормальном режиме. Дело в том, что ..

WPT невозможно установить в безопасном режиме, по той причине что Служба установщика Windows недоступна в безопасном режиме, и это при том что WPT поставляются в виде .msi-файла. Теперь представьте распространенную ситуацию: система не грузится в нормальном режиме, и в то же время Вы не можете поставить средство диагностики в безопасном

Для выхода из подобных обстоятельств имеется три решения:

компоненты WPT могут работать в качестве переносных приложений, достаточно скопировать с рабочей системы каталог Microsoft Windows Performance Toolkit и использовать его в качестве портабельной версии. Единственное, учитывайте разрядность систем!!
можно использовать хитрый твик реестра для установки .msi в безопасном режиме.
можно использовать альтернативное решение — утилиту Process Monitor в режиме протоколирования этапа загрузки.

Запуск трассировки

Непосредственно перед запуском процедуры трассировки, желательно соблюсти следующие простые требования:

Все нижеописанные действия рекомендуется производить не просто из командной строки, запущенной из-под учетной записи, входящей в группу «Пользователи журналов производительности» либо «Администраторы», а непосредственно из сеанса любой административной учетной записи во избежание проблем с доступом к провайдерам ядра в ходе многочисленных перезагрузок.
Во всех случаях трассировки проблем этапов загрузки операционной системы Windows рекомендуется настроить автоматический вход пользователя в систему, дабы время, затраченное на ввод пароля пользователем, не повлияло существенно на измерения. Хотя я этого не делал.

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

xbootmgr -trace boot -traceflags BASE+CSWITCH+DRIVERS+POWER -numruns 1 –stackwalk Profile+CSwitch -resultpath C:TEMP

Для трассировки этапа завершения выполняем команду:

xbootmgr -trace shutdown -traceflags BASE+CSWITCH+DRIVERS+POWER -numruns 1 –stackwalk Profile+CSwitch -resultpath C:TEMP -noprepreboot

После выполнения данной команды, контроллер xbootmgr передает ETW-коду в ядре информацию о классах событий, к отслеживанию которых необходимо приступить.
Небольшая ремарка: для хранения результатов я использую директорию для временных файлов системы, описанную в переменной %TEMP%, у меня обычно это традиционно C:TEMP. Соглашусь, что порой достаточно проблематично найти требуемый файл результатов в нагромождении временных файлов, однако это мой личный выбор, Ваше же право использовать произвольную целевую директорию.
Думаю, опции командной строки утилиты xbootmgr требуют дополнительного пояснения:

Опция	Описание
-trace	Режим трассировки. boot — трассировка этапа загрузки ОС; hibernate — трассировка режима гибернации и выхода из него; standby — трассировка спящего режима и выхода из него; shutdown — трассировка этапа завершения работы ОС; rebootCycle — трассировка полного цикла перезагрузки: этапов загрузки и завершения работы ОС;
-traceFlags	Флаги трассировки. Так называемые «флаги» представляют собой провайдеры событий, с помощью которых можно получить доступ к тем или иным событиям. Более подробную информацию о провайдерах можно получить командой `xperf -help providers`. По-умолчанию используются опции BASE+CSWITCH. Описаны ниже.
-numRuns	Количество повторений заданной стадии.
-resultPath	Целевой каталог для формирования файла отчета. Опция задает режим мониторинга контроллера — запись результатов в файл. По-умолчанию логи сохраняются в директории %WINDIR%System32.
-stackWalk	Фильтр прохода по стеку. Используются для углубленного анализа событий с помощью логирования участков кода момента событий и их последующего анализа. В данной статье мы не будем рассматривать этот функционал. Вероятно, по-умолчанию используется комбинация ProcessCreate+CSwitch, однако данный факт не подтвержден.
-noPrepReboot	Отключить предварительную подготовительную перезагрузку. Применяю эту опцию в случае трассировки этапа перезагрузки, поскольку она позволяет отлавливать некоторые баги.
-prepSystem	Проводит подготовку системы перед началом очередного этапа трассировки. Подготовка, в зависимости от ситуации, может быть разной, но основная польза данного ключа состоит в запуске процесса дефрагментации диска.

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

Флаг	Описание
BASE	Базовая информация. Какая именно?
PROC_THREAD	Создание/удаление процесса или потока.
LOADER	Загрузчик образов исполняемых файлов. События загрузки/выгрузки образа (библиотек, драйверов, программ) пользовательского режима или режима ядра.
PROFILE	Профилирование процессора. Дискретное событие, происходящее каждую 1 миллисекунду. Во время работы xbootmgr профилировщик прерывает процессор с интервалом в 1 миллисекунду и записывает стек вызова выполняющихся потоков. Помогает исследовать расход процессорного времени и выявить медленный код.
CSWITCH	Переключение контекста. Процедура сохранения контекста одной задачи и восстановления контекста другой. Количество переключений контекста в заданный промежуток времени?
COMPACT_CSWITCH	Компактное переключение контекста. Чем отличается от обычного?
DISPATCHER	Планировщик. Диспетчер, процесс, выполняющий принятие решений по переключению управления между задачами.
DPC	События вызовов отложенных процедур.
INTERRUPT	Прерывания. События возникновения программных и аппаратных прерываний.
SYSCALL	Системные вызовы. Обращения кода пользовательского режима к функциям ядра для выполнения каких-либо задач. Фиксируется количество вызовов?
PRIORITY	События по смене приоритета процесса/потока?
ALPC	Усовершенствованных вызов локальной процедуры, Advanced Local Procedure Call. Средство межпроцессового взаимодействия для быстрого обмена сообщениями. Механизм доступен только для внутренних системных процессов и не доступен для пользовательского кода.
PERF_COUNTER	Счетчики производительности процессов. Что имеется в виду?
DISK_IO	Дисковый ввод-вывод.
DISK_IO_INIT	Дисковый ввод-вывод. Инициализация.
FILE_IO	Файловый ввод-вывод. Время и результат выполнения операций файловой системы.
FILE_IO_INIT	Начало файлового ввода-вывода. Создание/Открытие.
HARD_FAULTS	Ошибки обращения к странице (Hard Pagefaults, ошибки страниц), требующие ее считывания с диска, соответственно, требующие иногда существенного времени для завершения. Прерывание, генерируемое в случае попытки доступа программы к странице памяти, которая отображена на виртуальное адресное пространство процесса, но фактически не загружена в оперативную память. Отличаются от Pagefaults тем, что это не просто событие ошибки обращения к странице, но требует её фактической загрузки в память.
FILENAME	Операции с файлами (создание / удаление / сводка).
SPLIT_IO	Раздробленный (разделенный) ввод-вывод. Частота разделений операций ввода-вывода физического диска на несколько составных более низкоуровневых операций. Указывает на то, что запросы ввода-вывода были расщеплены на множественные запросы ввода-вывода физического диска из-за более низкоуровневых аппаратных средств работы с диском. Позволяет диагностировать время отклика диска. Помогает определить концепцию дефрагментации диска.
REGISTRY	Активность системного реестра. Трассировка операций реестра.
DRIVERS	Событий драйверов. Задержки.
POWER	События электропитания.
NETWORKTRACE	События сетевого уровня (такие как прием и передача TCP/UDP пакетов).
VIRT_ALLOC	Операции с виртуальной памятью. Резервирование, передача, изменение, освобождение региона страниц в виртуальном адресном пространстве.
MEMINFO	Информация об использовании памяти.
ALL_FAULTS	Все ошибки страниц. Вероятно, отличаются от HARD_FAULTS тем, что включают еще и события Page_faults, то есть обычные ошибки обращения к странице, не требующие подгрузки с носителя.

Особенное внимание еще уделяется так называемым флагам прохода по стеку (Stack Walking Flags). Вероятно, это атомарные события, при которых код трассировки лезет в стек вызовов текущего потока для записи данных при наступлении конкретного события. Перечислю в виде списка, поскольку пока что нет глубокого понимания ситуации:

ProcessCreate, ProcessDelete, ImageLoad, ImageUnload, ThreadCreate, ThreadDelete, CSwitch, ReadyThread, ThreadSetPriority, ThreadSetBasePriority, Mark, SyscallEnter, SyscallExit, Profile, ProfileSetInterval, DiskReadInit, DiskWriteInit, DiskFlushInit, FileCreate, FileCleanup, FileClose, FileRead, FileWrite, FileSetInformation, FileDelete, FileRename, FileDirEnum, FileFlush, FileQueryInformation, FileFSCTL, FileDirNotify, FileOpEnd, SplitIO, RegQueryKey, RegEnumerateKey, RegEnumerateValueKey, RegDeleteKey, RegCreateKey, RegOpenKey, RegSetValue, RegDeleteValue, RegQueryValue, RegQueryMultipleValue, RegSetInformation, RegFlush, RegKcbCreate, RegKcbDelete, RegVirtualize, RegCloseKey, HardFault, PagefaultTransition, PagefaultTransition, PagefaultDemandZero, PagefaultCopyOnWrite, PagefaultGuard, PagefaultHard, PagefaultAV, VirtualAlloc, VirtualFree, PagefileBackedImageMapping, HeapRangeCreate, HeapRangeReserve, HeapRangeRelease, HeapRangeDestroy, HeapCreate, HeapAlloc, HeapRealloc, HeapFree, HeapDestroy, AlpcSendMessage, AlpcReceiveMessage, AlpcWaitForReply, AlpcWaitForNewMessage, AlpcUnwait, ThreadPoolCallbackEnqueue, ThreadPoolCallbackDequeue, ThreadPoolCallbackStart, ThreadPoolCallbackStop, ThreadPoolCallbackCancel, ThreadPoolCreate, ThreadPoolClose, ThreadPoolSetMinThreads, ThreadPoolSetMaxThreads, PowerSetPowerAction, PowerSetPowerActionReturn, PowerSetDevicesState, PowerSetDevicesStateReturn, PowerDeviceNotify, PowerDeviceNotifyComplete, PowerSessionCallout, PowerSessionCalloutReturn, PowerPreSleep, PowerPostSleep, PowerPerfStateChange, PowerIdleStateChange, PowerThermalConstraint, ExecutiveResource, PoolAlloc, PoolAllocSession, PoolFree, PoolFreeSession.

Вернемся к процедуре трассировки. После запуска вышеописанной команды, xbootmgr создает сессии (буфера в памяти) и начинает собирать информацию, поступающую через программные интерфейсы ETW от провайдеров, указанных пользователем (в нашем случае это BASE, CSWITCH, DRIVERS, POWER). Параллельно, в зависимости от режима работы xbootmgr, выполняются те или иные ключевые этапы (загрузка, завершение, сон, гибернация). Запомните, что в зависимости от опций утилиты, Вы должны быть готовы к мгновенной перезагрузке операционной системы, поэтому не забудьте предварительно сохранить рабочие данные!

В нашем случае будет выполнена одна перезагрузка, потому как задана опция -noprepreboot, если бы опции не было, то было бы две перезагрузки, первая подготовительная, вторая трассировочная.

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

После того, как оно исчезнет с экрана, можно быть уверенным, что целевой файл отчетов консолидирован и процесс (или один из этапов) трассировки завершен, а в целевом каталоге у нас появится файл shutdown_BASE+CSWITCH+DRIVERS+POWER_1.etl (имя которого зависит от указанных в командной строке провайдеров).

Анализ результатов трассировки

Непосредственно перед началом анализирования результатов трассировки необходимо обратить внимание вот на что:

Если в целевом каталоге имеется несколько файлов с расширением .etl, содержащих в названии суффикс premerge (например boot_BASE+CSWITCH+DRIVERS+POWER_1_km_premerge.etl), то это означает, что процесс трассировки не завершен и идет сборка отчета.

В этом случае необходимо дождаться окончания процесса и склеивания файлов отчетов в один. Интервал сбора данных утилитой xbootmgr после загрузки системы на финальном этапе задается при помощью опции командной строки –PostBootDelay и по-умолчанию равен 120 секундам.

Просмотр отчета

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

Открыть файл результатов через просмотрщик xperfview. Сделать это можно либо непосредственно запустив утилиту и выбрав пункты File -> Open, либо запустив xperfview с параметром командной строки, эквивалентным имени файла результатов трассировки.
Сконвертировать .etl файл в .xml файл командой: xperf -i shutdown_BASE+CSWITCH+DRIVERS+POWER_1.etl -o shutdown_analysis.xml -a shutdown Затем открыть получившийся файл shutdown_analysis.xml в веб-браузере. Обратите внимание на опцию -a, которая задает фильтр вывода, она должна соответствовать конкретному режиму, в котором создавалась трасса, либо можно эту опцию просто убрать совсем.
Открыть файл .etl утилитой xperf. Для этого выполняем команду: xperf shutdown_BASE+CSWITCH+DRIVERS+POWER_1.etl –a shutdown

Если Вы выбрали второй способ, то не забывайте запустить утилиту xperf в директории, где располагаются отчеты, либо указывать в командной строке полный путь к файлу .etl

А я бы на Вашем месте, не мудрствуя лукаво, выбрал бы первый способ с использованием утилиты xperfview, как наиболее простой. Потому как далее мы будем рассматривать как раз этот способ изучения результатов трассировки.

Общий алгоритм

При анализе проблем загрузки, определить на каком из этапов происходит основная задержка:

Pre Session Init (PreSMSS);
Session Init (SMSSInit);
Winlogon Init
Explorer Init
Post Boot

При анализе проблем завершения, определить, какой именно компонент завершается дольше обычного;
На графике, на котором виден проблемный компонент, выделить интересующий интервал, на нем по правой кнопке мыши вызвать меню и выбрать пункт Summary Table;
В открывшемся окне по столбцам времени выполнения (содержащем слова Time), определить, какой из модулей (или процедур/функций) тратит изрядное время на свой функционал;

Пример

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

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

CPU Sampling — Замеры используемого процессорного времени (в процентах).
CPU Frequency — Отслеживание изменения частоты процессора.
CPU Idle States — Состояния процессора.
Disk I/O — Дисковый ввод-вывод. Количество операций ввода-вывода.
Disk Utilization — Использование диска (в процентах).
Driver Delays >=100ms — Драйвера с задержкой, превышающей порог в 100 миллисекунд.
Process Lifetimes — Карта времени завершения процессов.
Hard Faults — Количество «тяжелых» ошибок страниц, требующих считывания информации с диска.
Services — Карта сервисов. Обращайте внимание на ключевое слово (у нас «stop») после имени сервиса. В нашем случае говорит о том, что мы трассировали этап завершения.
Winlogon — Основные контрольные точки этапа Winlogon.
Generic Events — Карта всех событий.

Из всех, представленных на сриншотах, результатов интерес вызывают, пожалуй всего два раздела, а именно Services и Driver Delays >=100ms. Тут мы можем воочию наблюдать существенные отклонения от типовых диапазонов быстродействия. Три драйвера csc.sys, mup.sys, fltmgr.sys по какой-то необъяснимой причине очень долго выгружались. Так же и сервисы gpsvc и wuauserv завершались довольно продолжительное время.

%SystemRoot%System32Driverscsc.sys — это драйвер удаленной файловой системы, мини-редиректор, поддерживающий функционал системного механизма автономных файлов и отвечающий за то, куда именно перенаправляются запросы ввода-вывода, к удаленной файловой системе или к локальному кешу (%SystemRoot%CSC). Драйвер поддерживает локальный кеш и обновляет кешированные данные при запросах ввода-вывода.
%SystemRoot%System32Driversmup.sys — Многосетевой UNC-поставщик, драйвер удаленной файловой системы, непосредственно показывающий (отображающий) системным драйверам файловых систем удаленную файловую систему. Является эдаким центральным хабом самого низкого уровня, обрабатывающим запросы ввода-вывода для доступа к удаленным файловым системам через UNC-пути (\ServerUserPath) и маршрутизирующим ввод-вывод определенному редиректору.
%SystemRoot%System32Driversfltmgr.sys — диспетчер фильтров файловых систем или высокоуровневый обработчик запросов к файловой системе, отвечает за функционирование всех драйверов фильтров в системе, которые могут представлять из себя модули различного назначения: антивирусные файловые сканеры, репликаторы файлов, шифровщики файлов, резервное копирование файлов и прч.

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

Источник

Пожалуй, начну с того, что если перегружаться 15 раз в год, то любой «тюнинг» процесса загрузки отнимает больше времени, чем будет выиграно на перезагрузках за все время жизни системы. Однако, спортивный интерес берет свое, тем более, что люди интересуется процессом оптимизации быстродействия. А загрузка оказалась самым очевидным кандидатом в примеры того, как на мой взгляд должен выглядеть этот самый процесс. Сразу скажу, что грузиться будем с 5400 rpm винта, грузиться будем в «рабочую» систему: помимо недобитой вендорской крапвари там стоит еще куча всякого типа вижуал студии, антивируса, скайпа, стима, гуглапдейтера и пр…

Про то, почему отключение pagefile-а скорее вредно, чем полезно — как нибудь в другой раз, а пока…

Конкретных и общеприменимых советов по оптимизации работы ОС быть не может точно так же как не может быть конкретных советов по ускорению работы любой случайно взятой программы. Точно так же как и в отдельных программах, работа всей системы может быть серьезно замедлена из-за одного-двух на первый взгляд незначительных мест. Для нахождения подобных «бутылочных горлышек» в программах существуют инструменты, называемые профайлерами. Нет ничего странного, что для нахождения «бутылочных горлышек» в операционной системе мы тоже будем использовать профайлер (никаких кавычек — это действительно профайлер причем одновременно и sampled и instrumented). С недавних пор WPA Tools распространяются в составе Windows SDK. Ставить полный SDK совершенно необязательно. Можно установить только «Windows Performance Toolkit»:

Собирать трейсы будем при помощи xbootmgr. Из магии используется только автологгер, включающий сбор ETW трейсов начиная с самого winload. Для вызова справки можно ввести xbootmgr -help — приводить ее здесь я не буду. Для желающих оценить масштаб можно ввести xperf -providers (или logman providers). Каждый провайдер имеет несколько «ключевых слов» (keywords), каждое «ключевое слово» включает/выключает несколько типов событий (event).

Итак начнем. Осторожно, следующая команда автоматически перегружает компьютер: xbootmgr -trace boot

После перезагрузки в каталоге, в котором эта команда была выполнена останется файл «boot_BASE+CSWITCH_1.etl» (BASE+CSWITCH это те самые «ключевые слова»): xperf boot_BASE+CSWITCH_1.etl

И можно начинать просмотр. Увиденное навевает печаль:

Explorer готов к 36-й секунде, но из-за 100% загрузки единственного (не особо быстрого) диска, система еще 2 минуты будет не очень отзывчивой (меню пуск будет открываться мгновенно, а вот с запуском программ придется подождать). ReadyBoot пытается чего то сделать и сначала у него даже получается (оранжевое и зеленое), но постепенно накапливающиеся отклонения от бутплана сводят его попытки на нет.
Что еще печальнее, так это то, что вместо собственно чтения данных, большую часть своей стопроцентной занятости диск проводит в метаниях головки к центру диска и обратно:

Небольшая справка: ReadyBoot собирает профиль использования диска при каждой загрузке и потом сервис SysMain строит бутплан на основании пяти последних загрузок. Соответственно, чем чаще загружаетесь, тем лучше будет «угадан» бутплан на следующую загрузку и тем быстрее она будет. Помимо этого, префетчер собирает статистику о том, какие файлы и в каком порядке были использованы во время загрузки и складывает эту информацию в %SystemRoot%PrefetchLayout.ini

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

Соответственно первой «оптимизацией» будет многократная перезагрузка и дефрагментация. Очень удобно, что xbootmgr может сделать это за нас.

xbootmgr -trace boot -prepSystem
По умолчанию выполняется шесть перезагрузок:

После второй начинается дефрагментация:

Когда все закончится, в каталоге, из которого был запущен xbootmgr останется 6 файлов с трейсами каждой из подготовительных перезагрузок а также все тот же boot_BASE+CSWITCH_1.etl

Смотрим, изменилось ли чего нибудь. А все изменилось довольно заметно:

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

Мы все еще ходим в центр диска и этим мы займемся позже, но disk seek-ов уже заметно меньше, и это уже какой никакой, а успех. Пока же, обратим внимание на такой график:

Это же безобразие. Пока кто то выкладывается на 100%, некоторые отдыхают. Будем исправлять. Как обычно разменивают процессоное время на размер читаемых данных? Правильно, компрессией. Исправлять будем сжатием папок Windows и обоих Program Files-ов. Попытку сделать это из загруженной системы нельзя назвать успешной — какие то файлы пакуются, какие то нет. В общем так жить нельзя:

Перегружаемся в System Recovery и выполняем оттуда compact /c /a /i /s: каталог для наших трех каталогов. Скриншотов не будет, так как мне было сильно лень делать скриншотилку для WinPE — придется поверить на слово (а лучше перепроверить экспериментально). prepSystem придется провести еще раз, так как layout диска после сжатия сильно поменялся.

Ну и проверяем, чего у нас вышло-то:

Эксплорер готов к 20-й секунде, еще чуть меньше минуты идет дисковая активность, но уже чуть меньше 100%.

И да, мы все еще ходим в центр диска:

Тултипы подсказывают нам виновника. Перепроверям

Заодно под раздачу попадают скайп и стим. И правильно — нечего им делать в автозагрузке с такими аппетитами. Их всегда можно запустить из супербара/старт меню.

Последние штрихи:

Совершенно невменяемое время загрузки одного сервиса:

И второго:

Мы договорились не отказываться от функционала, даже если он нам на фиг не уперся. Поэтому отключать сервисы мы не будем. Мы просто переключим их в «Automatic (Delayed start)»:

В случае с Microsoft Antimalware все несколько сложнее:

Достаточно быстро выясняем, что дело в том, что сервис относится к группе «COM Infrastructure» и не может быть загружен позже этой группы. Идем в реестр и вытаскиваем его из этой группы, после чего спокойно доделываем дело:

На всякий случай еще один prepSystem и вот финал:

Эксплорер загрузился на 17-й секунде, на 18-й фактически прекращается дисковая активность.

Можно полюбоваться на строго упорядоченный доступ к диску:

Быстрый SSD и/или тотальное вырезание функционала могло бы сократить время загрузки до десяти секунд и меньше.

А вывод из всего этого такой: прежде чем что либо «оптимизировать», стоит определить те минимальные изменения, которые возымеют максимальный результат.

Источник

Содержание

Using the Windows Performance Toolkit (WPT) with WDF
How can the Windows Driver Frameworks (WDF) extensions for WPT help?
Getting started
Analyzing the trace
UMDF I/O Request Graph and summary table
KMDF I/O Request Graph and summary table
PnP Power callback graph and summary table
Which calls are instrumented?
Resources and Troubleshooting
Windows Performance Toolkit
Windows компоненты набор средств производительности
Windows Средство записи производительности
Windows Performance Analyzer
Windows Performance Toolkit Technical Reference
Windows Performance Xperf Command-Line
Contents
Windows Performance Toolkit
Windows Performance Toolkit components
Windows Performance Recorder
Windows Performance Analyzer
Как ускорить загрузку Windows
Предварительная выборка в качестве ускорителя системы
Подготовка к оптимизации системы
Загрузка Windows SDK
Замеряем точное время запуска
Оптимизация автозагрузки
Ускоряем запуск Windows
Детальный анализ результатов измерений
Переход на SSD
Оптимизация процесса загрузки

Starting in Windows 10, you can use the Windows Performance Toolkit (WPT) to view performance data for a given Kernel-Mode Driver Framework (KMDF) or User-Mode Driver Framework (UMDF) 2 driver.

How can the Windows Driver Frameworks (WDF) extensions for WPT help?

You can use WPT to obtain performance insights or troubleshoot performance issues. For example:

Getting started

The WPT is part of the Windows Assessment and Deployment Kit (ADK). You can install the ADK from the Windows hardware tools site.

The WPT consists of two separate tools: Windows Performance Recorder and Windows Performance Analyzer (WPA). In this topic, we use WPR to record a trace, and then WPA to view the trace in a configurable GUI format.

To learn how to use the Windows Performance Toolkit to measure the performance of a WDF driver, either watch the following video, or read the steps below the video. The video and the steps cover the same procedure.

Recording and viewing an event log for a WDF driver

Install your driver, if it’s not already installed.

In an elevated command prompt, enter the following command.

WdfPerfEnhancedVerifier.cmd

Note WdfPerfEnhancedVerifier.cmd should be copied from the location you installed WPT. If you installed WPT on a development machine, you’ll need to copy the script from the WPT installation directory to the target machine.

This script sets registry entries for the specified driver so that the framework logs the events required to enable performance analysis when the ETW provider is enabled in step 4.

Reboot the computer.

In an elevated command prompt, enter the following command.

This command enables the ETW provider for WDF. The computer starts recording a trace.

NoteВ В As in step 2, Wpr.exe should be copied from the location you installed WPT. If you installed WPT on a development machine, copy these files from the WPT installation directory to the target machine.

On WindowsВ 10 for desktop editions (Home, Pro, Enterprise, and Education), you can also start the trace with Wprui.exe, which provides a GUI for recording traces. Under more options, expand Resource Analysis and select WDF Driver Activity.

Exercise your scenario of interest.

Open the event trace log in the Windows Performance Analyzer viewer:

Wpa.exe MyPerfTrace.etl

To capture another trace for the same driver, use Wpr.exe to start and stop a new trace. To capture a trace for a different driver, first rerun WdfPerfEnhancedVerifier.cmd for the new driver.

Analyzing the trace

To start analyzing the driver’s performance, find the Graph Explorer on the left, open the Computation category, and then drag the UMDF or KMDF graph to the main work area, under the Analysis tab. This screenshot shows the Graph Explorer pane:

There is a dedicated table for UMDF and another for KMDF drivers.

UMDF I/O Request Graph and summary table

WPT can display WDF I/O request completion throughput in two ways:

The following screenshot shows sample summary graphs and tables for CPU and UMDF I/O request performance. In the UMDF I/O Request Completion Rate graph, the number of requests per second is shown on the y axis.

In the summary table, most columns are self-explanatory, but there are a couple things to note. The WdfDevice column contains the WDFDEVICE handle associated with the I/O request. The ActivityID contains a unique identifier for the I/O request. The framework creates this identifier when it delivers an I/O request to the driver. If an activity identifier is already associated with the corresponding IRP, the framework uses that identifier. For more information, see Using Activity Identifiers.

Entry time is the trace timestamp when the framework delivered the request to the driver, and exit time is the timestamp when the driver called WdfRequestComplete or a related method to complete the request.

KMDF I/O Request Graph and summary table

Here’s a similar screenshot showing I/O request info for a KMDF driver.

PnP Power callback graph and summary table

WPT can also display the processing time of each PnP and power callback. The following screenshot shows EvtDeviceD0Entry, EvtDeviceD0Exit and EvtDevicePrepareHardware callback duration for a sample KMDF driver and a sample UMDF driver.

The WdfDevice column contains the WDFDEVICE handle associated with the callback. The ActivityID contains a unique identifier for the callback instance.

Which calls are instrumented?

This section describes which events are used to build the graphs and tables shown above.

After you run WdfPerfEnhancedVerifier.cmd for a specific driver, the framework records events in the ETL trace log when the system calls some of the specified driver’s callbacks, and also when the specified driver calls some framework methods.

To determine when I/O requests start, the framework records events when it calls the following callbacks:

The framework also records I/O request start events when the driver calls the following methods:

To determine when I/O requests complete, the framework tracks when the driver calls:

Finally, to determine callback duration for PnP/Power callbacks, the framework records when it calls the following driver-supplied callback routines, and when they finish:

Resources and Troubleshooting

Be sure to reboot after you run the WdfPerfEnhancedVerifier.cmd script.

To determine if your driver is configured to record an event log, use the !WdfKd.wdfdriverinfo kernel debugger command. If the driver is configured for performance tracing, you will see output like this:

For development and testing purposes only, enforcement of the driver code signing policy can be temporarily disabled. For more information, see Installing an Unsigned Driver Package during Development and Test.

Источник

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

Windows компоненты набор средств производительности

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

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

Windows средство записи производительности (звч): Windows 8 или более поздней версии.

Windows Средство записи производительности

Основные процедуры и подробное пошаговое руководство см. в быстрое Началое по ЗВЧ. Полную документацию по пользовательскому интерфейсу ЗВЧ см. в разделе функции ЗВЧ. Справочные сведения о параметрах командной строки см. в разделе параметры Command-Line ЗВЧ. Пошаговые инструкции см. в разделах Практическое руководство по ЗВЧ. Дополнительные сведения о ключевых сценариях см. в статье сценарии ЗВЧ. Полный справочный материал, включая XML-ссылку профиля записи и устаревший Справочник по XPerf, см. в справочнике по ЗВЧ.

Windows Performance Analyzer

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

Основные процедуры и подробное пошаговое руководство см. в Краткое руководство по началу работы WPA. Полную документацию по пользовательскому интерфейсу ЗВЧ см. в разделе функции WPA. Пошаговые инструкции см. в разделах Практическое руководство по WPA. Дополнительные сведения о ключевых сценариях см. в статье сценарии WPA.

Источник

Included in the Windows Assessment and Deployment Kit, the Windows Performance Toolkit consists of performance monitoring tools that produce in-depth performance profiles of Windows operating systems and applications. This documentation discusses both Windows Performance Recorder (WPR) and Windows Performance Analyzer (WPA).

Windows Performance Xperf Command-Line

The Windows Performance Toolkit consists of two independent tools: WindowsВ Performance Recorder (WPR) and WindowsВ Performance Analyzer (WPA). In addition, support is maintained for the previous command-line tool, Xperf. However, Xperfview is no longer supported. All recordings must be opened and analyzed by using WPA.

The following are the system requirements for running Windows Performance Toolkit:

WindowsВ Performance Recorder (WPR): Windows 8 or later.

You can download the Windows Performance Toolkit by visiting the Windows Assessment and Deployment Kit site.

Gives a general overview of both WPR and WPA.

Describes the new features available in this release.

Provides complete documentation for WPR. On MSDN, this includes a complete command-line and Extensible Markup Language (XML) reference.

Gives complete reference material for Xperf.

Covers the Kernel Trace Control API, an extension of the ETA Event Tracing API that is supported for backward compatibility with existing scripts and profiles.

Provides complete documentation for WPA to enable you to analyze recordings created with WPR or from the Assessment Platform.

Источник

The following are the system requirements for running Windows Performance Toolkit:

WindowsВ Performance Recorder (WPR): Windows 8 or later.

Windows Performance Recorder

WPR is a powerful recording tool that creates Event Tracing for Windows (ETW) recordings. You can run WPR from the user interface (UI) or from the command line. WPR provides built-in profiles that you can use to select the events that are to be recorded. Alternatively, you can author custom profiles in XML. WPR can also be invoked and controlled by using the WPRControl application programming interface (API). For more information about the WPRControl API, see WPRControl API Reference.

For basic procedures and a detailed walkthrough, see the WPR Quick Start. For complete documentation of the WPR UI, see WPR Features. For reference of command-line options, see WPR Command-Line Options. For step-by-step procedures, see WPR How-to Topics. For discussion of key scenarios, see WPR Scenarios. For complete reference material, including a recording profile XML reference and a legacy Xperf reference, see WPR Reference.

Windows Performance Analyzer

WPA is a powerful analysis tool that combines a very flexible UI with extensive graphing capabilities and data tables that can be pivoted and that have full text search capabilities. WPA provides an Issues window to explore the root cause of any identified.

For basic procedures and a detailed walkthrough, see the WPA Quick Start Guide. For complete documentation of the WPR UI, see WPA Features. For step-by-step procedures, see WPA How-to topics. For extended discussion of key scenarios, see WPA Scenarios.

Источник

Как ускорить загрузку Windows

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

> Windows
Описанная здесь оптимизация запуска подходит для версий 7, 8/8.1 и 10.
> Software Development Kit
Нужная нам утилита Xbootmgr входит в состав Windows Performance Analyzer, компонента Windows SDK.
> Магнитный жесткий диск
Оптимизация с помощью функции Prefetching работает только на компьютерах с магнитными дисками.

Предварительная выборка в качестве ускорителя системы

Подготовка к оптимизации системы

Загрузка Windows SDK

Замеряем точное время запуска

Оптимизация автозагрузки

Проблема, с которой не может справиться Xbootmgr, — слишком большое количество записей автозагрузки, которые накапливаются со временем. Для ее решения вам потребуется отдельная утилита, например, бесплатная Autoruns от Microsoft, которая составляет список всех записей и позволяет удобно их отключить.
> Запустите Autoruns с правами администратора и скройте все строчки, связанные с Microsoft. Для этого откройте «Options» и поставьте флажок рядом с записью «Hide Microsoft Entries».
> Перейдите к вкладке «Logons» и снимите все флажки с лишних строчек. Правой кнопкой мыши щелкните по программе, в чьем предназначении вы не уверены, и выберите «Search Online …». После отключения всех ненужных строчек автозагрузки закройте утилиту и перезагрузите компьютер.

Ускоряем запуск Windows

Детальный анализ результатов измерений

Переход на SSD

Если время загрузки компьютера так и не сократилось, перенесите Windows на SSD и используйте его в качестве загрузочного накопителя.
> Программа EaseUS Partition Master Professional оснащена легким в управлении Мастером, который скопирует вашу Windows на SSD. Если у вас ноутбук, рекомендуем переходник с USB на SATA, который сейчас стоит не больше 700 рублей. К ПК вы можете подключить SSD напрямую через SATA-порт.
> Запуск переноса в EaseUS Partition Master Professional осуществляется из пункта «Миграция OS на SSD/HDD». Следуйте указаниям Мастера, а затем поменяйте в компьютере старый жесткий диск на новый SSD. Наш компьютер после оптимизации с помощью Xbootmgr и автозагрузки, а также переноса системы на SSD стал загружаться довольно быстро — за 36 секунд.

Оптимизация процесса загрузки

Msg Это окно появляется во время измерений времени запуска программой Xbootmgr. Не закрывайте его и не нажимайте
на «Finish»

Источник

[+] Сегодня в программе

Загрузка и установка WPT

Подготовка к работе

Сбор данных

Анализируемые файлы и первый взгляд на этапы загрузки

ETL

XML

Этап OSLoader

Этап MainPathBoot

Фаза PreSMSS

Фаза SMSSInit

Фаза WinLogonInit

Фаза ExplorerInit

Этап PostBoot

Модернизация приложений

Windows Performance Toolkit: базовые сведения

Основы использования утилиты XPerf

Получение информации о системе

XPerf и визуализация стека

WPTx64 — можно ли удалить?

Заключение

Предварительная выборка в качестве ускорителя системы

Подготовка к оптимизации системы

Загрузка Windows SDK

Замеряем точное время запуска

Оптимизация автозагрузки

Ускоряем запуск Windows

Детальный анализ результатов измерений

Переход на SSD

Оптимизация процесса загрузки

Установка и настройка

Запуск трассировки

Анализ результатов трассировки

Просмотр отчета

Общий алгоритм

Пример

How can the Windows Driver Frameworks (WDF) extensions for WPT help?

Getting started

Analyzing the trace

UMDF I/O Request Graph and summary table

KMDF I/O Request Graph and summary table

PnP Power callback graph and summary table

Which calls are instrumented?

Resources and Troubleshooting

Windows компоненты набор средств производительности

Windows Средство записи производительности

Windows Performance Analyzer

Windows Performance Xperf Command-Line

Contents

Windows Performance Recorder

Windows Performance Analyzer

Как ускорить загрузку Windows

Предварительная выборка в качестве ускорителя системы

Подготовка к оптимизации системы

Загрузка Windows SDK

Замеряем точное время запуска

Оптимизация автозагрузки

Ускоряем запуск Windows

Детальный анализ результатов измерений

Переход на SSD

Оптимизация процесса загрузки