If you have seen Process Lasso report a CPU value above 100%, or noticed that its numbers do not line up with Task Manager, nothing is broken. You are looking at a different measurement. Windows exposes two ways to express how loaded a processor is, and Process Lasso defaults to the one that reflects actual work performed rather than time spent busy.
This is the classic measurement, and it is the one every version of Windows has offered. Over a sampling interval, it is the fraction of wall clock time the processor spent running something other than the idle thread. It ignores clock speed completely. A core pegged at 800 MHz and a core pegged at 5 GHz both read 100%. The value cannot exceed 100% per core.
Introduced with Windows 8, this measurement scales busy time by the performance actually delivered. Windows tracks a companion value, Processor Performance, which is the average frequency delivered over the interval divided by the CPU’s nominal base frequency. That ratio comes from hardware performance counters (APERF and MPERF on Intel and AMD parts). The relationship is straightforward:
CPU Utility % = CPU Time % x (delivered frequency / base frequency)Because the base frequency is not the maximum frequency, any processor running in turbo delivers more than 100% of its nominal performance. That is where values above 100% come from.
Consider a core that is busy for half of the sampling interval while boosting to 1.6 times its base clock. Time reads 50%. Utility reads 80%, because the core completed 1.6 times the work it would have completed at base clock during that same busy period. Now consider a fully loaded core holding a sustained boost of 1.3 times base. Time reads 100%. Utility reads 130%.
The reverse happens too, and it surprises people just as often. A core that is busy for the entire interval but downclocked to half its base frequency, whether from a power plan, thermal throttling, or a low performance state, reads 100% Time but only 50% Utility. Systems with aggressive core parking and frequency scaling show this behavior regularly, which is one reason we built ParkControl.
Neither reading is an error. Time answers how much of the interval the processor was occupied. Utility answers how much work it got done relative to its nominal capability.
Process Lasso uses CPU Utility % by default. To switch to the classic measurement, uncheck:
View > Use CPU Utility % instead of CPU Time %
With that item unchecked, Process Lasso reports CPU Time % instead, and values stay within the traditional 0 to 100% range. The setting changes only how usage is presented. It has no effect on how Process Lasso manages processes, and no effect on the system itself.
The disagreement between utilities comes down to which counter each one chose and whether it clamps the result.
| Tool | What it shows | Can it exceed 100%? |
|---|---|---|
| Process Lasso (default) | CPU Utility % | Yes, values above 100% are shown as measured |
| Process Lasso (View item unchecked) | CPU Time % | No |
| Task Manager | Utility based for the overall CPU figure since Windows 8 | No, the display is clamped at 100% |
| Performance Monitor | Whichever counter you add, including % Processor Time, % Processor Utility, and % Processor Performance | Yes, Utility and Performance both plot above 100% |
| Resource Monitor | Usage plus a separate line for current frequency as a percentage of maximum | No, the two factors are graphed separately instead of combined |
Task Manager is the source of most confusion here. It adopted the Utility model but hides the consequence by capping what it draws, so a machine sitting in sustained turbo pins at 100% and stays there. Process Lasso shows you the real figure. That is why a heavily loaded system can read 100% in Task Manager and 120% or more in Process Lasso at the same moment, with both tools reading the same counters correctly.
Performance Monitor is the best place to see the mechanics for yourself. Add the Processor Information object, then add % Processor Time, % Processor Utility, and % Processor Performance for the _Total instance. Watch the three lines under load and the relationship above becomes obvious. Note that the older Processor object offers only % Processor Time, since the newer counters were added alongside the Processor Information object.
Per-process numbers are a separate matter. Per-process CPU accounting in Windows is derived from thread kernel and user time, which is a time based quantity by nature. That is why per-process figures in any tool, including Task Manager’s own process list, may not reconcile cleanly with a Utility based total. The two columns are answering different questions.
Utility depends on the nominal base frequency Windows reports for the processor. On the occasional system that value is inaccurate, or the platform exposes its performance counters inconsistently, and the resulting Utility figure is skewed. CPU Time % is unaffected by any of this, so if a reading looks implausible, uncheck the View menu item and compare. If the two still disagree in a way that does not make sense, send us the details and we will take a look.