mscorsvw.exe（预编译程序集的 .NET 优化）占用了我的 CPU 的很大一部分 - 50-100%。
这篇文章（以及许多其他文章）说
ngen.exe 执行队列项
从命令行应该杀死它。对我来说，该命令只是挂起。有没有更好的方法来终止这个进程？
我没有尝试过重新启动。在过去的几天里，我发现我的 CPU 利用率不止一次飙升，我怀疑这是我的问题；我想知道接下来如何杀死它。
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.
发布评论
评论（6）
Try
Hope 不仅仅显示“我正在运行”，还显示它正在尝试编译的内容。
ngen queue stop命令将停止服务。当安装程序部署程序集并要求服务使用
ngen install对其进行预编译时，此服务开始运行。显然你的机器上有一台坏机器，我猜它在编译程序集时一次又一次地失败。检查 Windows 事件日志以获取相关信息。卸载执行此操作的程序。Try
Hopefully is shows more than just "I'm running" and shows what it is trying to compile. The
ngen queue stopcommand 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.没有;它不会杀死它。相反，它故意让事情变得更糟。它将立即处理所有排队的项目，而不是进行缓慢的后台编译（这样您通常不会注意到它）。这需要一些时间才能完成。它不会挂起，它会非常努力地工作。当它完成时，它就完成了，将不再需要后台编译。
请注意，后台编译作业（很可能）是通过最近的升级（您可能安装了服务包）添加的。 Windows 通过使用 .NET JIT 编译器 AOT 编译所有托管程序集来帮助您，该编译器了解您的确切硬件和处理器类型，以便生成最优化的代码。通过这种方式，.NET 确保软件将来运行得更快，但代价是现在编译程序集
在您间接链接到自己的许多资源中，请阅读此资源，例如：
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.:
在我看来，.NET 有一些有问题的设计，因为“及时”编译器需要在“时机”之前运行所有内容来编译它。
通常有两个
mscorsvw守护进程在运行，一个用于 64 位，另一个用于 32 位（它们彼此同步）。 100% CPU 利用率是您对编译器的期望，但它是在低优先级下完成的，并且一次不应占用超过一个内核。多核 CPU 的一个优点是，类似的事情仍然为您留下一个核心来驱动用户界面交互。 （请注意，搜索索引器是同一通用类型的另一个守护进程，按照相同的思路设计。）如果您有单核 CPU，那么您会真正注意到增加的负载。.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
mscorsvwdaemons 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.有时这会导致典型的错误。我的 SQL Server 案例 msiexec.exe 进程在安装 SQL Server 2012 SP1 后继续运行 像往常一样等待下一次更新。
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.
安装 SQL 2012 后我遇到了同样的问题。运行命令 ngen queue status 后，我看到正在运行的是 CLR 优化进程。再次使用此线程，我能够看到有两个服务 Microsoft.NET Framework NGEN v4.0.30319_X64 和 Microsoft.NET Framework NGEN v4.0.30319_X64 指示 32 位和 64 位优化代码。
我看到这两个都启动了，x86版本就是罪魁祸首。我停止了服务，CPU从100%恢复到0%，内存减少了大约2GB。
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.
看，.NET 毁掉了单核媒体中心 PC。旧电脑速度会慢上几个小时，基于网络的视频变得难以观看。关于能源效率就这么多了 - 我是否必须让我的 PC 24/7 编译，偶尔会被赶上？用户控制的进程不具有优先权。最棒的是，它不会放弃自动更新...包括 .NET！这会导致所有资源再次重新编译，并且永远不会在补丁星期二之前完成。我还没有找到响应建议的解决方法（“ngen.exe install /queue”或“ngen.exe update” - 在相关框架目录中找到 ngen）。所以。我在 services.msc 中禁用 Microsoft .NET Framework NGEN 服务 - 或通过命令行（'sc config clr_optimization_v4.xxxx start=disabled'，其中 xxxx 是版本号；通过 sc 查询或目录名称或 services.msc 获取版本号）； “停止”会在几秒钟内重新启动。考虑或尝试完全删除 .NET 4。
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.