Why .NET Framework process uses 100% CPU

If a .NET Framework process named MSCORSVW.EXE is constantly running at 100% CPU, it is either compiling high priority assemblies, which need to be completed as soon as possible, or else there's something wrong with the .NET installation. Here's how to resolve the problem.

Recently dealing with a system that had a broken .NET Framework installation, I noted that one symptom of the break was a process named MSCORSVW.EXE that was constantly running at 100% CPU.

At the time I didn't know that it was a .NET Framework process, but after some research, I found out its whole story.

MSCORSVW.EXE is a process used by the .NET Framework to precompile .NET assemblies in the background. It tends to run most on two occasions:

  • Right after you've installed the .NET Framework redistributable, when it needs to compile the highest-priority assemblies, and
  • After an application that uses the .NET Framework has been installed and needs to have its assemblies compiled.

<!--@REG-->

(Note: The process will not run on multiple cores or processors, as a deference to the user's needs. For instance, if it's pegging at full usage on a two-core machine, it will be listed as using up 50% of available CPU.)

The process usually only runs as low priority, meaning that if other processes are running, it should cede CPU usage to them. When it does this, it will work through a queue of assemblies that need to be compiled, so it's not unusual to see it running for a few minutes on end if there's a lot of work to be done.

But if the process is running at 100% and refuses to cede to other processes, it is either compiling high priority assemblies, which need to be completed as soon as possible, or else there's something wrong with the .NET installation.

One way to get the process to crank through all of its pending work at once is to issue the command ngen.exe executequeueditems from the .NET executables directory. If this doesn't work—i.e., if the process remains at 100% for minutes on end—the .NET installation may be damaged and should be removed and reinstalled. However, this doesn't happen very often; it's often just that there's a large queue of work that's suddenly been set up.

About the author: Serdar Yegulalp is editor of the  Windows Power Users Newsletter, which is devoted to hints, tips, tricks, news and goodies for Windows NT, Windows 2000 and Windows XP users and administrators. He has more than 10 years of Windows experience under his belt, and contributes regularly to SearchWinComputing.com and SearchSQLServer.com.

More information on this topic:

 

This was first published in October 2006

Dig deeper on Microsoft Group Policy Management

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchExchange

SearchSQLServer

SearchWinIT

SearchEnterpriseDesktop

SearchVirtualDesktop

Close