• Task Manager does not read a single instantaneous "CPU busy" value from Windows.
• The percentage is a periodic summary of activity that happened between refreshes.
• The display timer controls when the UI updates, but it does not supply the CPU denominator.
• CPU usage is an accounting result built from choices about cores, modes, idle time, interrupts, DPCs, and averaging windows.

How the percentage is computed

• Task Manager asks the kernel for cumulative per-process execution time, split across user time and kernel time.
• Each process behaves like an odometer: the code reads the running total, subtracts the last sample, and gets that process's CPU delta for the interval.
• The code also does a full pass across the process table, sums all current cumulative times, subtracts the previously remembered total, and gets the system-wide total delta.
• The per-process CPU percentage is that process delta divided by the total delta across all processes during the same sample window.
• This keeps the result meaningful even when the UI timer fires late or unevenly.
• The old code uses integer arithmetic and rounding to produce a fast, stable percentage without floating-point work in a hot UI path.

Why the number can feel wrong on modern hardware

• The meter answers how long a process was scheduled, not how many cycles or how much work the hardware delivered during that time.
• Dynamic frequency scaling, turbo behavior, thermal limits, deep sleep modes, and parked cores break the old assumption that a second of scheduled CPU time maps cleanly to a fixed amount of work.
• A process can show about 50% CPU for half of a sample window even though the actual work done in that half-window can vary widely with clock speed.
• The percentage is closer to occupancy than productivity.

Why totals, cores, and idle time confuse people

• On a multicore system, the process column answers what share of total machine CPU capacity a process consumed during the sample window.
• One process fully saturating one core on an 8-core machine lands near 12% to 13% of total machine capacity, not 100%.
• The System Idle Process is the bucket for unclaimed cycles, so busy time plus idle time adds up to the full machine total for the interval.
• The number is an average over the recent refresh window, so a short burst can be diluted into a small value or rounded to zero.
• Watching total CPU can hide a single saturated core, especially on machines with many cores or threads.

Why the code contains clamps, assertions, and edge cases

• The code clamps computed CPU above 99 back to 99 because early builds sometimes produced totals above 100% from a rare kernel-side accounting anomaly.
• The bug was trapped with assertions and eventually confirmed and fixed on the kernel side.
• The code invalidates old process records when cumulative CPU time moves backward, because PID reuse can make one dead process and one new process share the same identifier across samples.
• The code also marks an idle-process time of exactly zero as bogus and invalidates it.
• WOW tasks add another accounting wrinkle: child 16-bit task times are capped so they do not exceed the parent NTVDM total.

What the tool is for

• CPU usage is a ratio assembled from accounting decisions, not a substance that exists on its own.
• Task Manager favors a cheap, robust, human-readable approximation over a more forensic display.
• A 0% reading can still mean less than 1% average activity in the sample window, and a bouncing 0%, 6%, or 12% can match a bursty worker thread behaving normally.
• Catching microstutters, scheduler hiccups, or DPC storms needs a more specialized view than a one-second UI average.
• The old Windows NT4 Task Manager still runs on Windows 11, groups CPUs in sets of 16, and shows how much of the original design still survives.
• The final number is a fast, useful summary of a complicated reality, as long as it is read as an accounting ledger instead of a thermometer.