Вы тут: Главная → 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, а также насколько ускорилась загрузка системы в результате.
Slow pages lose users: research from Bing and Google indicates that delays as small as half a second can impact business metrics. To build fast sites, developers need powerful tools to analyze the performance of their sites and debug issues. In-browser tools like the F12 Developer Tools are a great start and the primary tools for analyzing what’s happening behind the scenes when a page slows down. However, some scenarios require measuring performance characteristics in the context of other applications and the operating system itself. For these scenarios, we use the Windows Performance Toolkit.
https://channel9.msdn.com/Events/WebPlatformSummit/edgesummit2016/ES1606/
The Windows Performance Toolkit (WPT) is a powerful tool to analyze both app and operating system performance, and is used extensively by the Microsoft Edge performance team for in-depth analysis. The toolkit includes the Windows Performance Recorder, a tool for recording traces, and the Windows Performance Analyzer, a tool for analyzing traces. It uses a fast, non-impactful trace logging system called Event Logging for Windows (ETW) to sample stacks and collect app or OS-specific events.
Since WPT can record and analyze CPU and memory usage for all Windows applications, WPT can be used for tasks that in-browser developer tools can’t, like analyzing GPU usage, disk usage, and system wide memory usage. In addition, WPT can be used to analyze performance in context of the system – for example, identifying the impact of virus scanners or performing cross-window analysis or measuring across multiple tabs in multiple processes.
In this post, we’ll introduce you to WPT with a very basic step-by-step example, in which we’ll use WPT to debug a simple performance issue. This example and analysis technique can be used with the in-browser F12 Developer Tools as well, but serve as a simple introduction to WPA. In later posts, we plan to explore more sophisticated analysis techniques using the capabilities described above.
Installing the Windows Performance Toolkit
The WPT is available as a component of the Windows Assessment and Deployment Kit, available for free from the Microsoft Dev Center. This kit includes a number of additional tools, however we’ll be focusing on just the Windows Performance Toolkit for the purposes of this post.
Gathering a performance trace
The first step to analysis using WPT is gathering a performance trace. In this step, we’re recording the performance characteristics of activity across the system to identify potential culprits inside and outside of the browser. For the purposes of this tutorial, we built a simple demo page with some artificial performance problems. We’ll use this page for the trace and analysis below.
Prepare Windows Performance Recorder
To minimize noise in the recording, you should close all applications besides the browser tabs you intend to analyze for this step. Launch the Windows Performance Recorder application (installed with the Windows Performance Toolkit”) and select the “Edge Browser” and “HTML Responsiveness analysis” profiles under “More options” (as seen in the screenshot below). These settings will configure Windows Performance Recorder to gather the metrics most useful for Edge performance analysis, including subsystem stack attribution, JavaScript symbols and networking, and frame-by-frame information.
Identify scenarios
Before starting the trace, it’s best to identify the scenarios you’re analyzing and try to keep them as atomic as possible. Imagine a site with performance problems when loading the page (from start of navigation to page load complete), scrolling, and selecting something in a table. In this case it’s best to record traces for each of the three scenarios separately to keep the analysis focused for each issue.
If a scenario involves navigating to a site, consider beginning the scenario at about:blank. Starting at about:blank will avoid the overhead of the previous page. If it involves navigating away from a site, navigate to about:blank to complete the scenario. This will keep the noise of other sites out of the trace unless the specific interaction between sites is the issue under investigation.
In our example, the scenario is a simple page load. We’ll navigate the browser to about:blank, and then navigate to the example page (you can download the sample on the Performance Analysis Test Drive here).
Record and execute scenarios
Once you’re ready to gather a trace for a given scenario, click “Start” to begin recording and execute the scenario you intend to measure. In our example, we’ll simply perform the navigation to our sample page.
As the browser navigates to and loads the demo page, Windows Performance Recorder will collect information about all programs running on the computer while the trace is recording, with minimal impact on active processes. As soon as you’ve finished executing the scenario (page load is complete), click “Stop” immediately and save the trace. This helps minimize the noise in your analysis as well as keep the trace file to a manageable size, as ETL files can get quite large.
Analyzing a performance trace
To analyze the trace, open Windows Performance Analyzer and open the ETL file generated in the previous step. You may need to load symbols for the trace, which can involve a large download. We recommend restricting the symbols loaded to Microsoft Edge and web apps, unless you have a specific additional need. You can do this by selecting “Trace/Configure Symbol Paths” from the WPA menu. Here you can use the Load Settings menu to restrict symbols to MicrosoftEdgeCP.exe and WWAHost.exe (as seen in the screenshot below).
The symbols will be cached to disk and future traces will load symbols much more quickly. After symbols begin loading, apply the HTML Analysis Profile by selecting “Profiles/Apply” from the menu then clicking “Browse Catalog.” Choose HtmlResponsivenessAnalysis.wpaProfile. For nearly all web site investigations, we recommend starting with this profile since it includes the key graphs and tables necessary for analyzing the performance of a website. This profile will configure four tabs (Big Picture, Frame Analysis, Thread Delay Analysis, and Trace Markets) loaded with data and graphs useful for analysis (as seen in the screenshot below).
For more on configuring these views and the functions of each tab, see our “Analyzing a trace” walkthrough on Microsoft Edge Dev. For the purposes of this post, we’ll assume you have the views configured to your liking and walk through a single performance analysis technique – top-down analysis.
Top-down Performance Analysis
Once you have recorded and loaded a trace for analysis, there are a number of techniques to investigate performance. For this post, we’ll walk through a technique called top-down performance analysis, which is focused on finding the most obvious and impactful performance problems on a page – literally investigating operations from the top down by impact in milliseconds. This general technique can be used in many tools, including the JavaScript view in the F12 Developer Tools, as well as in WPA.
To perform this analysis, begin with in Windows Performance Analyzer’s “Frame Analysis” tab. Under CPU Usage, sort the collapsed nodes by decreasing total CPU time (weight in milliseconds). From here, review each node and look up the corresponding source code to evaluate the potential reduction in call counts until CPU time breaks into smaller pieces. Note that this step is easiest with unminified code.
On a complex page, you should apply this technique to each major component independently. Many site have several separate components competing for CPU and network time, which the top-down analysis technique will help to highlight.
Sample analysis
Using the top-down analysis technique, let’s walk through the analysis of the demo page which we recorded above. For the purposes of this example, we’ll use a performance issue that is relatively simple and contrived.
Follow the instructions above to open the recording and then open the trace of our sample page in Windows Performance Analyzer. After doing so, go to the Frame Analysis tab and scroll down to the CPU Usage (Attribute) graph. Highlight the portion of time that has a visible graph and right click to Zoom in. This will filter the information in the CPU Usage (Sampled) table down to only that section of time. Next, remove the Thread ID and Activity to get a bit more space to view the Stack.
We’ll begin our Top-down Analysis here by clicking in the UI Thread root in CPU Usage (Sampled) seen in the screenshot below. Expand the tree and review what is occurring until you find the first bit of JavaScript—this should be topdown.js!Global code-1:1 (line 1, column 1). This appears to call down into runOnParse-164:18 (line 164, column 18) which then calls into initalizeHashtags-96:26 (line 96, column 26).
If we look into the code referenced here, we can observe that Global declares a few consts, creates a number of functions and calls runOnParse. So far so good! Continuing down the stack, we’ll next look into runOnParse. This appears well structured:
Next, we’ll look into intializeHashtags. Reviewing the code, we observe a loop that creates the hashtags. We also can observe a line at the end of the loop with a comment (lines 111-112) that it should run after the loop where all hashtags are created.
This is our problem code! Moving setWidthOfCells outside of the loop will run it after all hash tags are created, running only once instead of once for every tag, resulting in a dramatic performance improvement.
This is a relatively simple and contrived example, but illustrates the principle well. Top-down performance analysis is just one technique—while it’s a good start to debugging many simply performance problems, WPT enables more sophisticated approaches as well. Some other techniques include Bottom-up DOM API Analysis, which groups all of the API calls and then looks at the callers to find important optimizations, as well as Synchronous Layout Reduction. We plan to explore some of these techniques in more detail in future posts and demos.
Try out the Windows Performance Toolkit for yourself!
The best way to get acquainted with WPT is to try it out for yourself! We’ve published the slow web page used in the above example to our demo site and GitHub so you can follow along to identify the performance problem – see my video from Edge Web Summit to follow this debugging in real time.
WPT is powerful but it can be a steep learning curve – if you have any questions, don’t hesitate to reach out! You can get in touch via the comments below or @MSEdgeDev on Twitter with any questions or comments.
– Todd Reifsteck, Senior Program Manager, Microsoft Edge
Overview
The Windows Performance Toolkit (WPT) is a suite of tools designed for measuring and analysing system and application performance on Windows XP, Windows Vista, Windows 7 and Windows Server 2008. They can be used by enterprises to log and analyse clients in order to detect and optimise performance problems. I intend to use the WPT in a number of upcoming articles so this post will cover how to obtain and install it.
Unfortunately, the WPT is included as part of the Windows 7 SDK and cannot be downloaded separately, and the SDK download is a whopping 2.5GB! However, by following these steps it is possible to download only the minimal files required to gain access to the WPT MSI files. These MSI files can then be internally redistributed for easy installation of WPT.
Installation
- Download the Microsoft Windows SDK for Windows 7 and .NET Framework 4 (it’s a bootstrap setup and is only around 500KB).
- Run the file winsdk_web.exe.
- Accept all defaults until the Installation Options screen is reached.
- Deselect all components except Redistributable Packages \ Windows Performance Toolkit. (Depending on the client, you may not have the option to deselect the .NET 4 tools)
Windows 7 SDK Options for WPT
- Complete the installation.
- Browse to C:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Windows Performance Toolkit. Copy the wpt_x64.msi and wpt_x86.msi files.
WPT Redist Files
These wpt_*.msi files can now be used to install the WPT on any client machine and should be kept in a safe place so that you don’t need to download the SDK each time.
Windows Performance Analysis Tools
The Windows Performance Tools (WPT) Kit contains performance analysis tools. Windows Performance Tools are designed for analysis of a wide range of performance problems including application start times, boot issues, deferred procedure calls and interrupt activity (DPCs and ISRs), system responsiveness issues, application resource usage, and interrupt storms.
The Windows Performance Tools (WPT) is part of the Windows 8 SDK and the Windows Assessment and Deployment Kit. In this guide I’ll use the Windows 8 SDK Installer to install the WPT.
Go to the download site of the SDK:
http://msdn.microsoft.com/en-us/windows/hardware/hh852363
and click on the button download to download the Webinstaller:
and store the installer on your HDD. Now run the setup and this screen shows up:
Click next and select the WPT from the list:
Click «Install» and the Setup downloads the required files.
and installs the WPT
After a reboot (required to add the WPT folder to the PATH variable to run the tools from every place) you are ready to follow my xperf guides here on msfn:
Trace Windows Vista/7 boot/shutdown/hibernate/standby/resume issues
http://www.msfn.org/board/index.php?showtopic=140247
How to speed up boot process under Windows Vista or Windows 7
http://www.msfn.org/board/index.php?showtopic=140262
Analyzing DPC / Interrupt Issues:
http://www.msfn.org/board/index.php?showtopic=140263
Analyzing High CPU Usage Issues:
http://www.msfn.org/board/index.php?showtopic=140264
1 tip: The setup stores the MSI files in the folder C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit\Redistributables. The 32Bit version is named WPTx86-x86_en-us.msi, the 64Bit version is named WPTx64-x86_en-us.msi. The 3rd file (WPTarm-arm_en-us.msi) is needed for ARM based tablets/notebooks which run Windows RT.
You can use the MSI installer to avoid downloading the WPT after you reinstall Windows!
If you use Windows 8.1, you MUST use the WPT from the 8.1 SDK:
http://msdn.microsoft.com/en-US/windows/desktop/bg162891
But here the xperfview.exe is missing and you must use the horrible, blurry WPA.exe and I don’t update my guide to show how it works with this broken tool, this is too much hassle. Upload the files and I’ll try the WPA.exe to read the files.
Edited by MagicAndre1981
Модернизация приложений
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:\analysis\sysconfig.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:\windows\symbols), либо использовать онлайновую загрузку со специального сервера компании 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:\Products\Versions\1.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