15

mscorsvw.exe (a.NET optimization that precompiles assemblies) is taking up a substantial percentage of my CPU - 50-100%.

This article (and many others) say that

ngen.exe executequeueditems

From the command line should kill it. For me, that command just hangs. Is there some better way to kill this process?

I have not tried rebooting. I've seen my CPU utilization spike up more than once in the last few days, and I suspect this has been my problem; I'd like to know how to kill it going forward.

Adam Rackis
  • 79,454
  • 49
  • 255
  • 377
  • 2
    Why is this getting voted to close? This process is a .net precompiling optimizer (that wrecks your computer's performance). This question is fairly on topic for programmers as far as I can tell. – Adam Rackis Jun 24 '11 at 15:15
  • 6
    The real question is, why is it taking so much CPU. Killing it is not going to help. It's like: `why is the engine of my car using so much gasoline? Well: I'll just axe the front of my car, and hope it stops using gasoline.` Only this time, probably the car was built to automatically revive the engine after you axed it :). – sehe Jun 24 '11 at 15:19
  • 2
    Why this process takes so much CPU is something for MS to answer. But it taking a lot of CPU is a very common problem. http://www.google.com/#sclient=psy&hl=en&authuser=0&source=hp&q=mscorsvw.exe%20windows%207&pbx=1&oq=&aq=&aqi=&aql=&gs_sm=&gs_upl=&bav=on.2,or.r_gc.r_pw.&fp=c358ed31db4f1a8d&biw=1600&bih=1115&pf=p&pdl=300 – Adam Rackis Jun 24 '11 at 15:32

6 Answers6

15

Try 

ngen queue status

Hopefully is shows more than just "I'm running" and shows what it is trying to compile. The ngen queue stop command will stop the service.

This service starts running when an installer deployed an assembly and asked the service to pre-compile it with ngen install. Clearly you've got a bad one on your machine, I'd guess that it is failing over and over again to compile an assembly. Check the Windows event log for a breadcrumb about this. Uninstall the program that did this.

Hans Passant
  • 873,011
  • 131
  • 1,552
  • 2,371
  • Interesting, in my case 'ngen queue status' returned that the serice was stopped, and ngen queue stop was not an option. But I did 'ngen queue pause' Got a message "service is started and paused" and then process explorer stopped seeing the 4 threads starting and stopping. So that was interesting. – Ross Youngblood Jan 21 '21 at 23:26
10

This article (and many others) say that

ngen.exe executequeueditems

From the command line should kill it. For me, that command just hangs. Is there some better > way to kill this process?

Nope; it doesn't kill it. Instead it makes it intentionally worse. Instead of trickling background compiles (so that you normally wouldn't notice it), it will process all queued items at once. This will take some time to finish. It doesn't hang, it will be working very hard. When it's done, it's done, and there will be no more things left to background-compile.

Note that the background compilation jobs have been added (most likely) by a recent upgrade (you probably installed a service pack). Windows is doing you a favour by AOT-compiling all the managed assemblies using the .NET JIT compiler which knows all about your exact hardware and processor type, so that it will emit the most optimized code. In this way, .NET ensures that software run faster in the future, at the cost of compiling your assemblies now

Of the many resources you indirectly linked to yoursef, read this one e.g.:

sehe
  • 328,274
  • 43
  • 416
  • 565
5

.NET, in my opinion, has some questionable design, when a "Just In Time" compiler is required to run through everything to compile it before It's Time.

There are normally two mscorsvw daemons running, one for 64-bit and one for 32-bit (they synchronize with each other). The 100% CPU utilization is what you expect for a compiler, but it's done at low priority, and no more than one core should be tied up at a time. One advantage of multi-core CPUs is that things like these still leaves you a core to drive the user-interface interaction. (Note that the search indexer is another daemon of the same general kind, designed along the same lines.) If you have a single-core CPU then you'll really notice the added load.

J. Steen
  • 14,900
  • 15
  • 57
  • 62
DAGwyn
  • 51
  • 1
  • Thanks for pointing out that there are TWO processes. Even though you probably don't ever run 32-bit processes on your server, the 32-bit task will compile code for that too just in case. Maybe they should call it JIC (just-in-case-compilation) instead of JIT? – James Nov 30 '18 at 21:34
3

Sometimes this causes on a typical bug basis. My case of SQL Server msiexec.exe processes keep running after installation of SQL Server 2012 SP1 Wait for next update as per usual.

84RR1573R
  • 3,012
  • 2
  • 23
  • 42
2

I had the same issue after installing SQL 2012. After running the command ngen queue status, I saw it was the CLR optimization proces that was running. Again using this thread I was able to see there were two services Microsoft.NET Framework NGEN v4.0.30319_X64 and Microsoft.NET Framework NGEN v4.0.30319_X64 indicating the 32 bit and 64 bit optimmization code.

I saw that these two were started, and the x86 version was the culprit. I stopped the service and the CPU came back from 100% to 0% and memory reduced by about 2GB.

Sar
  • 31
  • 1
-1

Look, .NET murders single core media center PCs. Old computers slow for hours, web based video becomes unwatchably choppy. So much for energy efficiency - must I leave my PC compiling 24/7 to be occasionally caught up? User-directed processes do not take priority. Best yet it won't step aside for automatic updates... including of .NET! Which induce another recompile of all resources, never to finish before Patch Tuesday. I haven't found the suggested workarounds ('ngen.exe install /queue' or 'ngen.exe update' - find ngen in the relevant framework directory) responsive. So. I DISABLE Microsoft .NET Framework NGEN service in services.msc - or via command line ('sc config clr_optimization_v4.xxxx start= disabled' where xxxx is version number; get version number via sc query or directory name or services.msc); 'stop' just restarts within seconds. Consider or attempt total removal of .NET 4.

Relth
  • 21