In most modern multi-programmed data processing or computer systems, various tasks or user applications contend for processing time to execute on a central processing unit (CPU) or similar processing device. Activity in even the most highly multi-tasking environment tends to be bursty, having periods of latency or inactivity followed by periods of intense processing activity. Accordingly, it is useful to analyze the utilization of CPUs and other similar data processing system devices for a variety of reasons. For example, high processor utilization during periods in which few or no user tasks are scheduled may be an indicia of a virus program or of some correctable fault in task scheduling resulting in thrashing or other inefficient system behavior. In theory, CPU utilization may be determined by accumulating CPU idle time across a sampling interval to determine the percentage of time the processor is inactive. To accomplish this, a list of tasks or threads is maintained by the OS which are ready-to-run, i.e., not waiting for some event to resume execution. When this ready-to-run list is empty, no tasks are being executed and the processor is idle. Accordingly, a CPU-independent timer is read and the processor is essentially deactivated. This is accomplished by putting the processor in a predefined processor performance state such as the C2 or C3 states defined by the well known Advanced Configuration and Power Interface Specification, Revision 2.0, Jul. 27, 2000 (ACPI). In the C2 state clock signals are removed from the functional units of the processor while its memory subsystem remains active and “snoopable” by other devices. In a C3 state, the clock signal is also removed from this memory portion of the data processing system and a so-called “deep sleep” state is entered. When a new task is added to the ready-to-run list, the processor is placed in an active state (such as the CO ACPI state) and the timer is read again. The difference between the first and second timer reads (multiplied by the timer's period) then represents the CPU's idle time. The accumulation of this time across a sampling interval is then used to determine the CPU utilization (what percentage of the CPU's time is spent idle). Unfortunately, this measure of CPU utilization is difficult to calculate outside of the OS through a supported application programming interface (API). This is because the API is generally unaware of the ready-to-run task list which is known only to the OS.