Improve Battery Life and Performance using the Intel Battery Life Diagnostic Tool

This story was also published in Medium

Abstract

This article introduces the newest version of Intel(R) Battery Life Diagnostic Tool (BLDT), covering some of the new additions on version 3.0, and then walks through how to use the tool to do a high-level analysis of a consumer system with an Intel CPU to identify potential issues in configuration and installed software that may have a negative impact on either power consumption or resource utilization.

I Need a Charger, Quick!

Technically speaking, modern Intel CPUs on any new or recent laptops should provide the user with enough battery power to last a full day or more without requiring it to be charged, and at the same time exhibit good performance and snappy behavior. However, reality is sometimes different. Not necessarily because of failures with the CPU or other hardware, but because the software that is running on the system or some improper configuration settings at the OS level prevent the CPU and the rest of the system hardware from working to its full capabilities or as efficiently as it can. Improperly configured software or even poor software development practices can lead to excessive power usage or to resources being wasted away. This, in turn, leads to laptops in which the battery runs out only after a few hours, or the system constantly becomes laggy and slow.

Combining this with the fact that most modern systems are running a whole set of software behind the scenes, either because of corporate mandates, or standard software shipped by the system manufacturer, the decrease on performance or battery life can come as a surprise to the end user.

To address this issue, Intel developed a tool called the Intel® Battery Life Diagnostic Tool, or BLDT for short. This tool is designed to support end users and system administrators by providing insights into power consumption, system configuration, and usage of energy and computing resources by active software. BLDT provides the results in a format that is accessible and relatively easy to read, although fully understanding it might require some additional context and background information. Nevertheless, having an accurate picture of the system internal state provides a starting point for a deeper investigation if needed.

BLDT internally collects system and operational data and telemetry from a myriad of low-level sources and collectors, then aggregates it and provides a view of what the system is doing. Basically, it is like having a personal health lab that provides you with a blood panel, an MRI and multiple X-Rays so that you can see what is happening beneath the surface.

On top of that, the latest version of BLDT adds an AI-powered layer on top of the results so that it complements all the charts and metrics in the reports with a plain-English explanation of what it all means; and, more importantly, it provides the user with some next steps and guidance on what to do about any issues found.

Getting and Using BLDT

As can be imagined, BLDT encapsulates a lot of the knowledge Intel has about measuring, analyzing and troubleshooting power and utilization of CPUs, which unsurprisingly is considerable. But despite that, BLDT is free to download and use, and it is available directly from Intel’s website. At the time of writing, Intel offers two flavors of the tool: a standard version, and an enhanced version that includes an AI-assisted analysis feature.

https://www.intel.com/content/www/us/en/download/19521/intel-battery-life-diagnostic-tool.html

If you choose the AI-enabled version, keep in mind that it has a larger disk footprint than the standard one. That’s because the analysis runs locally on your device using on-device LLM inference, rather than sending your report to a cloud service. The upside is that the analysis is fast and self-contained; the tradeoff is that it needs more local resources and requires newer CPU platforms.

Installation is intentionally simple: download the installer and double-click it, then follow the prompts. Once installed, you can launch BLDT from its desktop icon, or by searching for “Battery Life Diagnostic Tool” in your installed applications.

Most people will use BLDT through its graphical interface, but it can also be run as a command-line tool. The CLI mode is particularly useful for automation scenarios (for example, running the same test across a fleet of machines, or integrating BLDT into a broader diagnostic workflow).

The way BLDT works is by running one or more “Tests” on a system. When you open the tool, the initial page shows the available tests as buttons; each test focuses on a different aspect of power, performance, and system behavior. In this article we’ll focus on the three most commonly used:

• System Config Checker: Evaluates operating system and platform configuration settings that influence power and performance and compares them against Intel-recommended values.
• Battery Life Assessment: Captures an aggregated, system-wide view of power and utilization over a sampling period to provide a quick, high-level snapshot of overall behavior.
• Software Hygiene Assessment: Observes the system over a short period of time and identifies background activity, resource utilization, and power impact at both the system and process/application levels. This test is meant to be an observation of the system on its “Idle” state.

It’s also worth noting that BLDT is extensible: Intel can (and does) add new tests over time, additional modules can expand what the tool is able to collect and report. So, if your BLDT home page shows extra tests beyond the ones mentioned here, that’s expected.

Running a test is straightforward: select the test button, optionally adjust any parameters for that test, then click Start. When the test finishes, BLDT will open the results in your default browser.

A couple of practical notes before you hit Start:

• Some tests take longer to complete than others. When a test is in progress, BLDT will attempt to minimize its impact on the system by not constantly updating the UI window with progress indicators. This may give the impression that the system is frozen or unresponsive. Be assured that it is not, the test is running on the background.
• Don’t use the machine during the test. If you open apps, browse the web, or otherwise interact with the system, you’ll change the workload and skew the measurements. For best results, leave the system alone.
• Follow power-source prompts. If a test requires running on battery or on AC power, BLDT will display a message asking you to plug in or unplug the power adapter at the right time. If this happens, the test will pause until the expected power source condition is met.

The latest version of BLDT also includes a feature to create custom tests. This allows customers to build a fully tailored workflow by selecting only the specific types of analysis and report “widgets” they care about, instead of running a larger, fixed test profile. Custom test definitions (and their corresponding report layouts) can be saved and reused later, which is handy when you want consistency across repeated troubleshooting runs.

Analyzing a System

BLDT can look at your machine from a few different angles, and it’s helpful to keep those “scopes” in mind as you read the available reports. Across its various tests, BLDT tends to provide three broad scopes of analysis:

• Configuration and Settings: Covers configuration settings that influence power and performance and how they compare against recommended values. This includes Windows settings as well as more Intel CPU-specific power and performance controls.
• System Metrics: Provides aggregated metrics for the entire system. BLDT observes behavior over a sampling period, collecting large amounts of telemetry and summarizing it into a coherent system-wide picture.
• Processes Behavior and Resource Usage: Breaks down behavior at the process/application level — how much power each process consumes, how CPU resources are utilized, and how that activity maps to different parts of the platform.

There is overlap between scopes and tests (for example, a “system” test may still include process-level tables), but some tests lean more heavily in one direction or another. For example, Battery Life Assessment is primarily system-focused, System Config Checker is, unsurprisingly, configuration-focused, and Software Hygiene Assessment goes deeper into process activity and resource usage. There are other tests in BLDT, but for the purposes of this article, these three are the most relevant ones.

When you’re diagnosing overall health — or troubleshooting something specific like “my battery only lasts a couple of hours” or “this system feels sluggish all the time” — it’s usually best to start with System Config Checker. It’s relatively fast, and it can immediately flag configuration issues that have an outsized impact on both power and responsiveness. After verifying configuration and settings, the next logical step is to get a more in-depth review of the system using the Software Hygiene Assessment.

Step 1: Reviewing System Configuration and Settings

Config Checker compares your current settings to Intel-recommended values and provides some guidance on what to change. As always, take recommendations in context: some settings that maximize battery life may not be appropriate for a machine that’s expected to be plugged in all day and deliver consistent peak performance, and some “performance” settings may not make sense on a system that spends most of its life on battery.

One part of the Config Checker output that can look a bit more obscure is the PPM section. The PPM (Processor Power Management) policy is a collection of features that guide runtime behavior of your system. OS runtime power management includes core parking, scheduling decisions, hybrid processor capabilities, efficiency preferences, and others. A subset of PPM settings are tuned by Intel and delivered as provisioning settings that automatically apply to the appropriate OS and Processor combination. The Config Checker validates the settings of your system against the expected values from Intel and highlights any out-of-date or overridden settings that may have unsatisfactory impacts on your battery life and system performance.

Step 2: In-Depth Analysis with Software Hygiene

After you’ve reviewed configuration (and applied changes that make sense for your scenario), the next step is to run a test that observes real behavior over time. Both Battery Life and Software Hygiene can provide that system-wide view, but if you want the deeper, more complete picture — especially for “something is draining my battery in the background” types of issues — Software Hygiene is usually the better choice because it provides more detailed results.

When you select the Software Hygiene test, you’ll see several parameters that control how the test is performed. For an initial analysis and troubleshooting pass, it’s usually best to keep the defaults. In the default configuration, expect the test to run for roughly an hour and to run on battery power. If you’re validating a specific scenario (for example, an always-plugged-in kiosk, or a shorter “spot check”), you can adjust duration, power source, and other settings accordingly.

One reason the Software Hygiene test is so useful is that computers are rarely “truly idle.” Whether it’s antivirus scanning, update checks, sync engines, OEM utilities, enterprise agents, or applications that periodically wake up to do a little work, there is almost always background activity. Individually, each of these tasks may look harmless; in aggregate, over time, they can add up to a surprising amount of CPU time and power drain.

Software Hygiene is designed specifically to measure that “death by a thousand paper cuts” effect. This test is meant as an Idle Scenario test, meaning the intent is for the machine to be left alone — no open apps, no Windows Settings panels, no Task Manager watching the graphs, or other user-initiated activities. When the test finishes, BLDT will open the generated report in a browser window. The report includes both system-level information and process-level breakdowns; it may also include a subset of configuration information, but not as comprehensively as Config Checker.

Understanding the Software Hygiene Test Results

BLDT reports are divided into multiple sections called widgets. Each widget is a self-contained view of a particular type of data or visualization. Some widgets are narrowly focused (for example, a table of CPU package C-state residency), while others combine multiple data sources to provide a more “story-like” summary of what the system was doing. Because of that, it’s normal for some widgets to overlap or reinforce each other.

The first widget on every report is the Test Summary, shown at the top. It provides the basic context for everything else: what system was tested, which test profile ran, when it ran, how long it ran, and details such as the state and charge of the battery at the start of the test.

TIP: Every widget includes a HELP button in the top-right corner. If you’re unsure what a chart or metric means, this is the fastest way to get the documentation for that widget.

In addition, many widgets can highlight whether observed values fall outside what BLDT considers typical for a well-behaved system. Those highlights appear when you click the Recommendations button (if the widget has one). If there’s nothing to flag, the button may not appear.

The thresholds behind those highlights are based on expected behavior for typical business/corporate laptops. That’s important context: a clean, out-of-the-box consumer machine, a gaming laptop, or a workstation running heavy background services may look “abnormal” by corporate standards, even if it’s behaving exactly as its owner intends.

Fully understanding every widget and metric would require a lot more detail and context that what can be covered here, but there are a few key places that are particularly helpful when you’re trying to answer the practical question: “what is my system doing when it should be doing nothing?”.

The following checklist covers the main points worth focusing on:

Total CPU Idle Duration (IDLE/BUSY HISTOGRAM widget). Because Software Hygiene is intended to be an “idle” test, the first sanity check is how idle the CPU actually was. The rule of thumb is simple: higher is better. This metric aggregates how much time the CPU spent not doing work. Since the CPU is one of the most power-hungry components in a laptop, unnecessary CPU activity while “idle” is one of the fastest ways to lose battery life. And of course, the less power being used when the computer is idle, the longer the amount of charge on the battery will last.

CPU Power States / C-States (SOC POWER METRICS widget). CPU power states (C-States) describe how “awake” the CPU package is. In very broad terms, lower-numbered states mean higher activity and higher power (for example, PC0), while higher-numbered states indicate deeper idle and lower power (for example, PC10). During a healthy idle scenario, you generally want the CPU to spend most of its time in the deeper (higher-numbered) states. If the report shows significant time in PC0 during an idle test, that’s a strong indicator that something kept the CPU fully active.

A 100% of time spent on PC 0 implies that the CPU was fully active for the entire duration of the test

During its normal operation, a CPU moves up and down through the different C-States depending on what it is doing (anything from rendering a spreadsheet to going to sleep when closing the lid).

CPU package power (SOC POWER METRICS widget). In the same widget, BLDT also reports total CPU power in milliwatts. This gives you a single number that often correlates well with battery drain in an idle scenario: if CPU package power is high while the machine is “idle,” something is forcing activity.

Process-level investigation.

Once you’ve confirmed the system was or wasn’t as idle as expected, the next step is finding out who did the work. The Software Hygiene report includes multiple process-level views, but the two widgets that are the most immediately useful are PROCESS ACTIVITY SUMMARY and TOP BATTERY LIFE IMPACT. The former focuses on CPU utilization and the latter on power consumption.

PROCESS ACTIVITY SUMMARY focuses on CPU utilization. It shows the top processes sorted by total CPU use and also breaks down activity across core types (for example, Performance vs. Efficiency cores) and Quality of Service (QoS) levels.

Generally, the processes that use more computing resources will also be the ones requiring more electricity, but that is not always the case. Depending on many factors, including how the applications are designed or what they do, some processes may have a high CPU utilization cost, but a lower energy usage; or vice versa. However, these cases are more of an exception than the rule.

The PROCESS ACTIVITY SUMMARY widget displays a list of the top 20 processes sorted by their total CPU utilization. For each process, the activity is also shown across the different core types. Modern Intel CPUs have multiple core types, which could be Performance cores, Efficiency cores or Low-Power Efficiency cores on some systems. Different systems and CPU generations may have different arrangements of these core types.

In general, Performance cores are the most capable and should be used for the most compute intensive work, and Efficiency cores are the ones that are designed to be, as implied, more energy efficient but not necessarily intended to be used for the more demanding computational jobs. When a process is running, different types of tasks can be distributed among the available cores. Where each task operates is the result of multiple complex factors that involve the operating system and the software itself. However, understanding how the process is being distributed across cores can help shine a light on why some processes are more expensive than others in terms of resources.

The table also shows the distribution of process activity across the different Quality of Service (QoS) levels. Understanding QoS goes beyond the scope of this article, but in general terms it is a way for software to indicate the type of work being used so that the system can better assign the appropriate compute resources for a thread running a given task.

Clicking on each process row, reveals two more graphs called the “Busy Bucket Distribution” and the “Idle Bucket Distribution”. These are complementary views that shows how “Busy” (active) or “Idle” (quiet) that process was in relation to using the CPU. For the process to be efficient, its busy periods should be short (higher amount of green lines towards the left side of the graph), and longer periods of quietness (more green bars on the right side of the graph)

TOP BATTERY LIFE IMPACT focuses on power consumption. It lists applications by total power used over the observation window and breaks that power down by components such as CPU, Disk, and Others.

For each row, the table shows the total power usage in milliwatts, as well as the power used by individual components (CPU, Disk and Others). For reference, total busy and idle durations are also displayed. Finally, the count of WMI calls and ACPI Interrupts associated is also displayed.

In contrast to the Process Activity Summary table, the rows on the Top Battery Life Impact table represent individual applications and not processes. This is because internal Windows systems report power utilization at the application level and not at the process level. Clicking the row of any application will allow you to drill down into the individual processes that make it up. However, be aware that at the process level, only CPU, WMI and ACPI metrics are displayed.

TIP: The TOP BATTERY LIFE IMPACT table does not include the display panel/monitor power. So, if your “battery life is bad” problem is primarily a brightness or panel-refresh issue, that may not show up as a top offender in this table.

On both summary tables, you can use the search feature to explore and investigate the resource utilization of any process on the system for which data was captured. You are not limited to only the top 20 items.

Understanding resource utilization by individual processes and applications is also an avenue to understand first what processes are running in the background and the cost of each process in terms of compute and energy resources.

Make it all make sense using AI

As incredible as it may be, not everyone who wants to make their laptop more efficient is a thermal-and-performance engineer with years of experience staring at power-state residency tables. BLDT’s reports are rich, but they can also be intimidating if you don’t live and breathe this type of data. That’s why the newest BLDT version includes an optional AI-powered analysis layer for Software Hygiene results.

The AI analysis runs entirely on the user’s system. No report data needs to be uploaded, and no data is sent to Intel as part of the inference process.

To run an AI Analysis, first you need to have completed a Software Hygiene Assessment on the machine being analyzed. Once you have the results, select the “SW Hygiene AI Analysis” test from the BLDT’s homepage. Choose the desired SW Hygiene result and click START to run the analysis.

The first time it runs, it usually takes a bit longer since it needs to initialize all the AI components, but subsequent runs are faster. Additionally, analysis time is related to the system hardware and capabilities.

Like any BLDT test, once the test finishes, the results will open on a new browser window.

The AI analysis examines the captured results, identifies areas that fall outside expected ranges, and provides a plain-English explanation of what looks unusual and why it matters. More importantly, it also suggests next steps to address the issue. Just keep in mind the same caveat as before: “expected” behavior is based on typical business/corporate laptop environments, and other usage profiles may legitimately look different.

The AI analysis report is organized by the same widgets as the Software Hygiene Assessment report. For each widget that fails to meet the expected threshold, BLDT generates a corresponding section on the AI Analysis results. Each section typically includes:

• Findings: what BLDT observed and which metric(s) were out of range.
• Recommendations: concrete suggestions for what to check, change, or validate next.
• Links: a direct link back to the corresponding widget in the original Software Hygiene report, plus a link to additional documentation explaining what that widget measures.

The AI inference process in BLDT is tuned with domain-specific context around power and performance on Intel-powered systems. Still, it is AI-generated guidance — so treat it the way you would treat any automated recommendation: sanity-check it, confirm it aligns with your usage scenario and policies, and verify that the suggested changes are appropriate before applying them.

Summary

When battery life or “snappiness” doesn’t match expectations, the cause is often not the CPU itself, but the combination of system configuration and background software activity that prevents the platform from operating efficiently. Intel’s Battery Life Diagnostic Tool (BLDT) helps make that visible by collecting low-level telemetry and presenting it as readable reports. Now on it’s third major version, BLDT 3.0 enhances its capabilities with more tools, knowledge and an AI-powered analysis of the obtained results.

To troubleshoot a system with poor battery life, the recommended workflow is to start with running the Config Checker test to catch obvious configuration issues (including Processor Power Management findings), then move to Software Hygiene to quantify “idle” background activity and identify which processes and applications are driving CPU usage and power drain. If you have the AI-enabled version, the on-device AI analysis can translate key out-of-range widgets into plain-English findings and next steps — while keeping all data local to the system.