如何杀死 mscorsvw.exe答案

【问题标题】：How to kill mscorsvw.exe如何杀死 mscorsvw.exe
【发布时间】：2011-06-24 15:05:31
【问题描述】：

mscorsvw.exe（预编译程序集的 .NET 优化）占用了我的 CPU 的很大一部分 - 50-100%。

这篇文章（和许多其他文章）说

ngen.exe 执行队列编辑

从命令行应该杀死它。对我来说，该命令只是挂起。有没有更好的方法来杀死这个过程？

我没有尝试重新启动。在过去的几天里，我不止一次看到我的 CPU 利用率飙升，我怀疑这是我的问题；我想知道如何杀死它。

【问题讨论】：

为什么投票结束？此过程是一个 .net 预编译优化器（会破坏计算机的性能）。据我所知，这个问题对程序员来说是相当的话题。
真正的问题是，为什么要占用这么多 CPU。杀死它不会有帮助。就像：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. 只是这一次，可能这辆车是为了在你砍掉它后自动恢复引擎的:)。
为什么这个过程需要这么多 CPU 需要 MS 来回答。但它占用大量 CPU 是一个非常普遍的问题。 google.com/…

标签： .net visual-studio ngen

【解决方案1】：

试试

ngen queue status

希望不仅仅是“我在跑步”，而是显示它试图编译的内容。 ngen queue stop 命令将停止服务。

当安装程序部署程序集并要求服务使用ngen install 预编译它时，此服务开始运行。显然你的机器上有一个坏的，我猜它一次又一次地失败来编译一个程序集。检查 Windows 事件日志以获取有关此的面包屑。卸载执行此操作的程序。

【讨论】：

有趣，在我的情况下，'ngen queue status' 返回服务已停止，并且 ngen queue stop 不是一个选项。但我做了'ngen queue pause' 收到一条消息“服务已启动并暂停”，然后进程资源管理器停止查看 4 个线程的启动和停止。所以这很有趣。

【解决方案2】：

这篇文章（和许多其他文章）说

ngen.exe 执行队列编辑

从命令行应该杀死它。对我来说，该命令只是挂起。有没有更好的 > 杀死这个进程的方法？

不;它不会杀死它。相反，它故意使情况变得更糟。而不是涓涓细流的后台编译（这样你通常不会注意到它），它会一次处理所有排队的项目。这需要一些时间才能完成。它不会挂起，它将非常努力地工作。当它完成时，它就完成了，不会有更多的东西需要后台编译了。

请注意，最近的升级（很可能）已添加后台编译作业（您可能安装了服务包）。 Windows 通过使用 .NET JIT 编译器对所有托管程序集进行 AOT 编译来帮您一个忙，该编译器了解您的确切硬件和处理器类型，因此它将发出最优化的代码。通过这种方式，.NET 可以确保软件在未来运行得更快，但代价是现在编译您的程序集

_{在您间接链接到您自己的众多资源中，请阅读以下内容，例如：}

http://techdows.com/2010/08/what-is-mscorsvw-exe-how-to-disable-it.html

【讨论】：

【解决方案3】：

在我看来，.NET 有一些有问题的设计，当一个“及时”编译器需要运行所有东西才能在 It's Time 之前编译它时。

通常有两个mscorsvw 守护进程在运行，一个用于 64 位，一个用于 32 位（它们彼此同步）。 100% 的 CPU 利用率是您对编译器的期望，但它是以低优先级完成的，并且一次不应占用一个以上的内核。多核 CPU 的一个优点是，像这样的东西仍然为您留下一个核心来驱动用户界面交互。（请注意，搜索索引器是另一个相同类型的守护进程，设计思路相同。）如果您有一个单核 CPU，那么您会真正注意到增加的负载。

【讨论】：

感谢您指出有两个进程。即使您可能从未在服务器上运行 32 位进程，32 位任务也会为此编译代码以防万一。也许他们应该称它为 JIC（以防万一编译）而不是 JIT？

【解决方案4】：

有时这会导致典型的错误。我的 SQL Server 案例msiexec.exe processes keep running after installation of SQL Server 2012 SP1 照常等待下次更新。

【讨论】：

【解决方案5】：

我在安装 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。

【讨论】：

【解决方案6】：

看，.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。

【讨论】：