Using Windows Performance Analyzer to analyze Modern Standby issues
The Windows Performance Analyzer (WPA) displays traces of system activity in a graphical format. WPA is used for many Windows performance and debugging scenarios, and is the second-level triage tool for Modern Standby issues that cannot be resolved by using SleepStudy. WPA presents a graphical format of a trace file that contains events collected during a Modern Standby session.
Watch this video to learn how to use WPA to analyze traces of Modern Standby sessions.
This video shows how to use the Platform Idle State graph and PDC Resiliency Activity graph to identify the cause of software activity that prevents the hardware platform from spending sufficient time in the DRIPS state.
Watch this video to learn how to use the Platform Idle State graph and Device Dstate graph to track down a hardware device that causes the hardware platform to spend too little time in the DRIPS state.
For more information about the Platform Idle State graph, see the «Common WPA graphs for connected standby power management» section below. For more information about the PDC Resiliency Activity graph and Device Dstate graph, see the «View a WPA trace» section below.
WPA is available in the Windows Assessment and Deployment Kit (Windows ADK) download package and includes scripts and documentation for Modern Standby analysis.
The remainder of this section refers to the documents and scripts that are provided in this download.
Capture and view a WPA trace for Modern Standby diagnostics
Trace capture is the key diagnostic method that is used to debug issues that are observed during Modern Standby through SleepStudy or other tools. A trace contains detailed information about system platform states, device states, software activity, CPU utilization, memory utilization, and other system events. Events that are captured in a trace show exactly what happened during Modern Standby and any problems that resulted.
Capture a WPA trace
Capture a trace of at least one hour of Modern Standby to observe trends and averages.
Use the following method to capture a WPA trace using the Windows Performance Recorder (WPR) with the Power profile:
- Install the Windows Performance Toolkit (WPT).
- Open an elevated command prompt and navigate to the WPT install location.
- To start the trace, run: wpr -start Power
- While recording, put the system into Modern Standby. Wait for at least one hour, then wake up the system.
- To stop and save the trace into an event trace log (ETL), run: wpr -stop .etl
View a WPA trace
Use the WPA tool to view and analyze Modern Standby traces. Download the WPA tool, install it on a computer, and follow these instructions to open the trace file:
- Run Wpa.exe. Note that Wpa.exe is available for x86 and x64 only.
- In the WPA menu, click File, click Open, and select a trace file.
- To apply a profile, click Profiles\Apply to open a separate Analysis tab.
- Click Browse and select the applicable profile to apply.
- Add other graphs to the current analysis view from Graph Explorer by following these steps:
- Expand a graph category in Graph Explorer.
- Select the graph to add and drag it to the Analysis View pane.
To correlate data from a SleepStudy report to the WPA trace, use the mapping shown in the following table.
| SleepStudy | WPA trace |
|---|---|
| Activators | The PDC Resiliency Activity graph shows a list of activators that were active during the Modern Standby session. |
| Processors | The CPU Idle States graph shows a list of the CPUs in the system and their respective states. |
| Fx devices | The Device Dstate graph shows the list of Windows power framework (PoFx) devices that were active during the Modern Standby session. |
| PDC phases | The PDC Notification Phase graph shows the details of all the PDC phases. |
| Networking | Several graphs show networking activities. The PDC Resiliency Activity graph shows activators such as the broker infrastructure (BI) or Windows Push Notification Services (WNS) that can trigger network activities. The Device Dstate graph shows information about the activity of the Wi-Fi device. The Generic Events graph can show events that are triggered by networking components such as WCM, DHCP, and TCPIP. |
| Power Requests | The Power Requests graph shows details for all power requests that were active during this session. The relevant request types for Modern Standby are «System Required» and «Execution Required» power requests. «Display Required» are used for screen on scenarios. |
Common WPA graphs for Modern Standby power management
[!Important] @Jacob Write up on power request graphs -> under graphs and SPR section
The graphs that are generated from the Modern Standby WPA profile are key to observing system behavior in Modern Standby and identifying problems. Two commonly used WPA graphs are the Platform Idle State graph, which shows how much time the platform spends in the various platform idle states, and the DRIPS graph, which shows the activity levels of software and hardware components.
Each graph has a table view that shows the raw data that was used to construct the graph. The view can be configured by using the buttons that are located at the upper right-hand corner of the graph window.
The default view is graph only. The following paragraphs explain how to change the default view to obtain information about Modern Standby behavior.
Platform Idle State graph
The Platform Idle State graph shows the residency in platform idle states plotted against time.
On different platforms, the numerical states might correspond to different System on a Chip (SoC) states. Contact the SoC vendor to get the specific mapping for their hardware. This section covers only the lowest power platform state because the time spent in this state is critical to Modern Standby battery life.
The most important of the platform idle states is the deepest state, DRIPS. The DRIPS state corresponds to the lowest power state for the SoC during Modern Standby. Each SoC defines its own DRIPS state and corresponding state index.
The percentage of time that is spent in the DRIPS state (DRIPS percent) is an important metric for Modern Standby because it is directly proportional to battery life. If the DRIPS percent is high (above 90 percent), battery life will be longer than if the DRIPS percent is lower (for example, below 80 percent).
To obtain the DRIPS percent, open the table view and drag the % Duration column to filter on State. This column will then display the percentage of time that the system was in each state.
DRIPS graph
The DRIPS graph shows the components that are active during the trace period, including activators, devices, and processes. Use this graph to identify the components that are active the longest and that prevent the system from entering DRIPS.
Activators are components that take references and perform tasks while in Modern Standby. They handle the value-adding, explicitly allowed software activities that can run during sleep. Ideally, they should be active only in short bursts, and the DRIPS graph can be used to identify the most active activator during a Modern Standby session. This information is important because a particular activator could hold a reference for a long period of time, which prevents the system from entering DRIPS.
All components that are shown in the preceding graph, except for Devices and CPU Activity, are activators. For example, the preceding graph shows BI, WNS, NCSI, and Image Download Manager as activators. To identify the top activators, open the table view and look at the % Reason Time column, which shows the percentage of time the activator was active during the Modern Standby session. For example, the following screenshot shows that BI is the top activator with 49.71 percent active.
BI is a special activator because it provides broker services to apps to access system resources. When BI shows up as an active activator, expand the BI row and determine which apps are causing BI to be active. Use this graph to determine the top active apps during the Modern Standby session.
In addition to activators, active devices might prevent the system from entering DRIPS.
Similar to system idle states, devices have low-power states that range from D0 to D3. Device low-power states are generally standardized by device class. Low-power states for devices the SoC itself are defined by the SoC manufacturer. Low-power states for devices outside of the SoC are typically standardized across all systems.
Use the DRIPS graph to determine the top active devices during the Modern Standby session. The graph shows only those devices that can block the SoC idle state (DRIPS), based on information provided by the platform power engine plug-in (PEP). For more information about the PEP, see PoFxPowerControl.
Some devices can be active because an activator is running tasks that require the device to be active. Common examples are the primary storage (eMMc/SSD) and Wi-Fi devices, which are active whenever the BI activator is active.
To identify the most active devices, open the table view and look at the % Reason Time column, which shows the percentage of time that each device was active during the Modern Standby session.
In addition to activators and devices, a final reason that the system cannot enter DRIPS is due to excessive CPU activity. CPU activity is a less common problem compared to activators and devices, but might be exacerbated by OEM pre-installed desktop applications and services.
View the active processes by expanding the CPU Activity row.
Как с помощью Windows Performance Analyzer определить скорость всех элементов автозагрузки в Windows 10
Для достижения лучшей производительности Windows очень часто рекомендуют выполнить очистку системы от устаревших файлов. В действительности эта процедура практически не влияет на скорость работы операционной системы, поскольку временные файлы обычно ею не задействуются. Если на что и нужно обращать внимание в первую очередь, так это на автозагружаемые приложения и процессы, именно они оказывают непосредственное влияние на производительность Windows и время ее загрузки.
Существует много программ, предназначенных для выявления «тормозящих» приложений, но ни одна из них не может заменить Windows Performance Analyzer или сокращенно WPA — мощный профессиональный инструмент администрирования, позволяющий определять время загрузки всех и взятых по отдельности процессов с точностью до доли миллисекунды. Единственный его существенный недостаток — сложность освоения, как никак ориентирован Performance Analyzer на системных администраторов.
Когда в окне мастера появится предложение выбрать компоненты для установки, отметьте галочкой пункт «Набор средств для оценки производительности Windows».
Установку остальных компонентов можно проигнорировать, чтобы не занимали на диске место.
Где Windows хранит отчеты о загружаемых процессах
Идентифицировать загружаемые вместе с Windows программы нетрудно. Для этого можно воспользоваться любой утилитой для анализа автозагрузки или даже штатным Диспетчером задач, кстати, умеющим показывать степень влияния той или иной программы на скорость загрузки операционной системы.
Но в данном случае нас больше интересуют файлы BootCKCL.elt и ShutdownCKCL.etl , расположенные в системной папке C:\Windows\System32\wdi\LogFiles , именно в них Windows записывает сведения о запускаемых процессах, а также загруженности диска и процессора.
Анализируем логи в WPA
Содержащаяся в логе BootCKCL.elt информация представлена в бинарном формате, но Windows Performance Analyzer может ее расшифровать и прочитать. Запустите WPA , перейдите в меню File и укажите путь к этому самому файлу BootCKCL.elt .
При этом в левой колонке рабочего окна утилиты у вас появятся графики. С ними мы как раз и будем работать. Нажатием на стрелку-треугольник разверните элемент Computation, в раскрывшемся списке найдите график «CPU Usage (Precise)» и перетащите его мышкой на вкладку «Analysis» — серое поле в правой части рабочего окна.
В результате в этой части окна появится три таблицы. Кликните ПКМ по любому из заголовков содержащей список запущенных в системе процессов нижней таблицы и отметьте галочкой в открывшемся контекстном меню пункт «CPU Usage (in view)».
Отмеченный столбец тут же появится в таблице.
Теперь в столбце «New Process» выделите мышкой программы, скорость загрузки которых хотите измерить, кликом ПКМ вызовите контекстное меню и выберите в нем «Filter To Sеlеction».
В списке процессов останутся только нужные.
Теперь смотрим, что из всего этого получилось. Данные в столбце «CPU Usage (in view)» представлены временем загрузки каждой программы в миллисекундах. Например, Download Master загружается 4620,797806 миллисекунд (4,62 секунды) и это много, так как средней степенью влияния считается время автозагрузки не более 1000 миллисекунд.
Теперь откройте еще одну вкладку «Analysis» и перетащите на нее график «Lifetime by Process». Точно так же выделите интересующие вас процессы и отфильтруйте их из контекстного меню. Обратите внимание на данные столбца «Start Time (s)».
Он содержит время в секундах, через которое приложение начинает запускаться сразу после загрузки основных процессов операционной системы. Если время загрузки программы очень мало (1-2 секунды) , это может означать, что программа стартует вместе с основными процессами Windows, тормозя ее загрузку. В этом случае имеет смысл отложить автозагрузку такого приложения, воспользовавшись твиками реестра или утилитой AnVir Task Manager.
Примечание: в Windows 8.1 и 10 с целью ускорения загрузки разработчики снизили влияние сторонних приложений на запуск операционной системы, тем не менее, вы можете отсрочить их загрузку, если считаете, что они тормозят запуск системы.