How Do I Investigate a CPU Usage Spike Without Being Present?

19,085

Here are some options; the easiest one is either Process Explorer if the CPU usage is significant, else you will more likely want to look at a graph in Process Monitor. I feel that the most likely culprit is either a back-up or an update, so you might want to see when those are scheduled. The task scheduler does shown when tasks were last run...

Without a trace

Based on an event

  • ProcDump can automatically create dump files based on things like high CPU usage.

    An advantage to having a dump is that you a developer can actually debug it in WinDBG.

With a trace

  • Process Monitor, set it to keep a lot of history and let it only log profiling events.

    1. In the Options, you can set the history depth and can turn on generation of the profiling events.

    2. Then, disable the I/O, Registry and Network buttons.

  • Windows Performance Toolkit has XPerf, which allows you to take advanced traces.

    This might be hard for the first time, so you might want to try Process Monitor first...

Share:
19,085

Related videos on Youtube

CadentOrange
Author by

CadentOrange

Updated on September 18, 2022

Comments

  • CadentOrange
    CadentOrange over 1 year

    I have a server that's mysteriously using up a lot of CPU late at night, when it shouldn't be under heavy load. This causes some database calls to time out, and I've set up some alerts in PerfMon to trigger if CPU usage goes over 50% and this seems to coincide with the CPU spikes coincide with the database time outs.

    I suspect that it's a scheduled task of some sort, but I've looked at the Windows and SQL Server scheduled tasks list and don't find anything. The Windows event logs only contain the database time outs and PerfMon entries indicating that CPU usage has spiked.

    My question is this: How do I determine what process is causing the CPU spike without being physically present? I really do not want to have to log into the server at 2 a.m.

    Update: It turns out the problem was with the product I'm working on. The problem started manifesting itself during normal work hours, and I didn't have to rely on some sneaky performance investigating technique after all.