Optimizing Power for Interactions between Virus Scanners and Pre-bundled Software

Published:06/27/2015   Last Updated:06/26/2015

Download PDF


Original equipment manufacturers (OEMs) like Lenovo,Toshiba, Dell, etc. ship their desktop PCs, laptops, and Ultrabook™ devices with software already installed on them (bundled applications) in order to help make their products more appealing to their customers. Most likely, you have bought a PC that came with several applications already installed on it, one of which is usually an anti-virus application such as Norton, McAfee (which Intel now owns), Avast, etc. This article will discuss ways for analyzing and optimizing power consumption by looking at the interaction an anti-virus scanner might have with another bundled application.

Users often times blame the anti-virus scanner for why their new PC only has a battery life of ~4 hours, when the box claimed it should be ~8 hours. Anti-virus scanners have higher CPU usage when one of these bundled system utilities performs certain operations like writing to a directory or performing an update.

Anti-virus software can start a chain reaction due to another process making changes to the system such as write operations. If one of these bundled applications (let’s call them system utilities from now on) is performing an operation more than it should, the anti-virus scanner will in turn consume more system resources. This chain reaction is why your PC does not have the battery life labeled on the box.

Tools are available that provide insight as to how these bundled applications interact and impact the overall system. The case study below shows how a system utility was writing to a directory more than it should, which in turn caused an anti-virus scanner to execute to ensure the operation was safe. The interaction between the two caused a very high power consumption resulting in less battery life.

Case Study

This case study will first describe the problem that required investigation, the tool used for that investigation, and finally the methods used to solve the problem.

The Problem

The problem is that a particular machine claims to have 8 hours of battery life yet the actual shutdown time is 6 hours. What is occurring on the system to cause such a massive drain on battery power? Many tools are available that can help debug this type of situation. Below are brief descriptions of these tools.

Windows* Tools for Power Analysis

Of the many Windows-based tools available to help you optimize your system, the first step is understanding how each can help you determine how one bundled application affects another.

The second step is to see what can be done to improve the overall power consumption of the system.

Measurement Tools

  1. Intel® Power Gadget
    • Gathers power/energy metrics such as package (CPU and GPU) power consumption. This is a must-have tool for analyzing power consumption while the app is running.
  2. Intel® Soc Watch
  3. Windows Assessment Console (WAC)
    • Packaged with Windows 8/8.1 ADK.
    • Pick the “Battery Life during idle periods” job
    • WAC’s user interface allows you to perform traces showing specific system metrics like CPU utilization, virtual memory commits, power consumption, etc. It provides a summary of projected system shutdown times.

Analysis Tool

  1. Windows Performance Analyzer (WPA)
    • Packaged with Windows 8/8.1 ADK.
    • WPA is used to load the .etl file generated by WPR/WAC so that in-depth analysis can be performed.

Suggested checklist when using these tools

  1. Does Intel Power Gadget report a package (CPU and GPU) power consumption that is much larger than when the pre-bundled application is uninstalled?
  2. Does Intel Soc Watch on the latest Intel® processors report C7 state residency being at least 95%?
  3. Does the Windows Performance Analyzer show high CPU usage or many writes to a specific directory under the IO section?
    • Which process is writing to this directory excessively and what is the full path for these writes?
    • If there are spikes in CPU usage, what is occurring on the system? Maybe an activity occurs every three seconds causing the CPU usage to increase every three seconds.
  4. Does an application change the system’s timer tick resolution from 15.6 ms (Windows default) to a smaller value?
    • If an application is changing the system’s timer tick resolution to a smaller value, i.e., 1 ms, the application or system utility could perform certain activities more frequently thus causing higher power consumption on the overall system.

Note: This is not a full list. For more information refer to Intel Optimization Guide.

The Investigation

The tool used to investigate power consumption was the Windows Assessment Console (WAC), which can be found at the following paths:

The 64-bit “wac.exe” application — C:\Program Files (x86)\Windows Kits\8.x\Assessment and Deployment Kit\Windows Assessment Toolkit\amd64

The 32-bit “wace.exe” application — C:\Program Files\Windows Kits\8.x\Assessment and Deployment Kit\Windows Assessment Toolkit\x86.

The Windows Assessment Console (WAC) provides a summary view in which the statistics of each run can be viewed in the same window for easy comparisons. Note the projected shutdown times below.

Comparing projected shutdown times under different conditions

Comparing average projected shutdown times of the best case (no Internet/no anti-virus) to worst case (Internet and anti-virus) shows roughly a one hour reduction in battery life between these runs.

Using the summary view provided by the Windows Assessment Console (WAC), it is evident that in some runs a particular application is changing the system’s timer tick resolution down to 1ms. This change can be very significant to the overall system performance as other system utilities are using the timer for purposes such as when to update. The next figure shows how WAC would report something of this nature.

WAC Summary view showing issues reported during Idle Battery Life job

By further investigating the results provided by the Idle Battery Life assessment, the interaction between a system utility and a bundled anti-virus application becomes better understood. The next snapshot shows that the CPU usage of the anti-virus application increases (purple line) shortly after the CPU usage of a particular system utility increases (red line).

Anti-Virus software executing during 3rd-party write operations

The system utility updates its cache, which the anti-virus then cross-checks to ensure the operation is safe. This behavior was seen with and without Internet connection.

System utility writing to its log file, which in turn causes the anti-virus software to execute to ensure the operation is safe.

An increase in CPU usage causes an increase in the power consumption of the system, which reduces the battery life of the system. The goal is to reduce behavior that causes increased and unnecessary CPU usage.

End Result

Both the system utility and the anti-virus software came bundled on the machine. One way to stop the anti-virus software from running every time the system utility performs an IO operation is to put the system utility on a pre-approved list. That way the anti-virus software knows the system utility is safe and doesn’t execute unnecessarily.

See the difference in behavior on the system after this change was made.

No CPU usage increase caused by the anti-virus software when the system utility writes to its log

Now that CPU usage has decreased, the overall power consumption of the system will decrease as well. The following figure shows the new estimated shutdown times.

New projected shutdown times show significantly longer battery life.

Even though there are two runs with issues reported due to writes to storage, the projected shutdown times in both these runs are unaffected.


In this case study, the write operations performed by a system utility were causing the bundled anti-virus scanner to execute to ensure the operations were safe. This chain reaction in turn caused CPU usage to increase every time this particular system utility performed a write operation. Every time the CPU usage increased, the overall power consumption of the system would increase thus reducing battery life and showing lower projected shutdown times. By adding the system utility to a safe list, the projected shutdown times increased even when writes to storage still occurred.


[1] "Windows Assessment and Deployment Kit (Windows ADK)." Microsoft Corporation, 2 April. 2014. Web. 3 April. 2014. http://msdn.microsoft.com/en-us/library/windows/hardware/dn247001.aspx

[2] Pantels, Tom, Sheng Guo, and Rajshree Chabukswar. Touch Response Measurement, Analysis, and Optimization for Windows* Applications Intel Corporation, 10 April. 2014. Web. 22 May. 2015. https://software.intel.com/content/www/us/en/develop/articles/touch-response-measurement-analysis-and-optimization-for-windows-applications.html

[3] Chabukswar, Rajshree, Mike Chynoweth, and Erik Niemeyer. Intel® Performance Bottleneck Analyzer. Intel Corporation, 4 Aug. 2011. Web. 12 Feb. 2014. http://software.intel.com/en-us/articles/intel-performance-bottleneck-analyzer

[4] Kim, Seung-Woo, Joseph Jin-Sung Lee, Vardhan Dugar, Jun De Vega. Intel® Power Gadget. Intel Corporation, 7 January. 2014. Web. 25 March 2014. http://software.intel.com/en-us/articles/intel-power-gadget-20

Product and Performance Information


Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.

Notice revision #20110804