Sign up ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

w3wp.exe is showing 99% CPU usage. What are the best ways to investigate the cause of this high CPU usage?

share|improve this question

migrated from Sep 3 '09 at 1:34

This question came from our site for professional and enthusiast programmers.

5 Answers 5

Attach WinDbg + sos and run !runaway. That will show you which thread is taking the most CPU time. Do a !clrstack on the thread to find out what it is doing.

share|improve this answer
Can you link to or fill-in some instructions for attaching a process? I've been using Windows since 3.11, programming for a decade and have no idea how to do that. – Rob Allen Apr 28 '09 at 10:02
Both WinDbg and Visual Studio (and many other debuggers) can attach to a process in order to debug it. The reason I mention WinDbg is that the sos extensions make it relatively easy to find CPU hugs. For more information on WinDbg please see – Brian Rasmussen Apr 28 '09 at 10:08
if issue in on LIVE server but I don't have access to it, do you have any suggestions. – Ravi Apr 28 '09 at 13:10
Without access it is going to be a lot harder to find out. Try going through the source code then. Look for potential live locks, huge memory consumption (the problem may be that too much time is spend doing GC) and so forth. Without additional details it is hard to give specific advice. – Brian Rasmussen Apr 28 '09 at 13:31

Other suggestion of tools is DebugDiag, see more here
[UPDATE] Use ProcDump, see more at Using ProcDump.exe to monitor w3wp.exe for CPU spikes.

share|improve this answer
Especially nice if none-developers have to provide the crashdumps etc. – Alex Sep 2 '09 at 20:18

w3wp.exe is the ASP.NET worker process, so if it is using a high percentage of the server's CPU, it is the ASP.NET application that is causing the problem. However, this does not necessarily indicate that there is a problem with the ASP.NET application. It may be serving too many requests with limited resources. The only real measure is to check the CPU usage against the amount of traffic being handled by the application.

If you are suspecting that a certain request takes too long, you could can use the Logparser command line utility to analyze your logfiles and find which page has a long execution time.

c:\>logparser "select top 10 cs-uri-stem, time-taken from INSERT_YOUR_IIS_LOG_FILE_NAME.log group by cs-uri-stem order by time-taken desc" -q:on

You could also use a tool to show which pages are currently executing, like IISPeek (not free).

If you want to go deeper, try to understand hwo to use WinDbg. Here is a good tutorial: Windows Debuggers: Part 1: A WinDbg Tutorial

share|improve this answer

I've had this problem intermittently before. It seems to spike to 99% after the first request and never comes down. If I kill the process the new worker process usually behaves correctly. I've never figured out why this happens.

share|improve this answer

We're having the same issue Greg notes above. We're just killing those processes. Didn't observe this on IIS6/windows server 2003, only on IIS7/windows server 2008.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.