To do it you only need to press the Stack button. The stack is a memory region that stores function history invocation. One way to look inside a thread execution is to look at the thread stack as bellow with Process Explorer. Because I have previously configured symbols for OS images in Process Explorer the thread list also showed function names in this case (Worker Thread) functions. If you press the Module button you can see details about the driver Srv.sys in this case. In the bellow screen we can map CPU activity to the file server device driver (Srv.sys) that respond to network I/O requests for file data on disk partitions shared to the network. You should configure process explorer to download symbols from MSFT to get thread function names for further information on it’s activity. Process Explorer shows the threads running in a process by consulting the Threads page of the Process Properties dialog. To answer the above question we can use process explorer to help us identify the culprit. How can I identify the device driver that’s causing the CPU Spikes? So if you notice CPU Spikes around the corner with the System process it could well be a misbehaving device driver. It’s existence serves OS threads for Windows subsystems and device drivers as well.

The System process is not bound to an executable image like any other process.

System threads don’t have a user process address space and thus must allocate any dynamic info from OS system memory heaps, such as a paged or nonpaged pool. System threads have all the attributes and contexts and are similar to regular user-mode threads, however they run only in kernel-mode.

The System process (PID 8 in Windows 2000 and process ID 4 in Windows XP Vista and Windows 2003) houses kernel-mode system threads. Before addressing the issue at hand it is best to get familiar with the System process and what makes it so unique in comparison.

Process monitor windows xp