VBCSCompiler.exe 的大量实例 [英] Numerous instances of VBCSCompiler.exe

问题描述

我最近刚刚下载并安装了 Visual Studio Professional 2015 (14.0.23107.0).我第一次打开我们的解决方案(28 个项目)并执行 Build -> Rebuild Solution 时，我的开发机器完全爬行了.CPU 已达到 100% 的最大值并且构建从未完成 - 即使超过 10 分钟.

我打开 Windows 任务管理器并注意到: > 10 个 VBCSCompiler.exe 任务正在运行.合并后，这些任务将 CPU 发送 > 90%.

知道为什么有这么多任务在运行吗?有什么办法可以阻止这种情况发生?

这是我能找到的最接近遇到相同问题的人的方法:

有趣的是，我们的 .NET 核心程序集有不同的版本.你在 4.06.79 而我在 4.06.81.

我的客户端 dll"(位于 C:Program Files (x86)MSBuild14.0BinMicrosoft.Build.Tasks.CodeAnalysis.dll)与您的版本和时间戳相同:

奇怪的是，当我查看 ILSpy 中的代码时，我看到了一些稍微不同的东西——也许是优化?

 private static NamedPipeClientStream TryAllProcesses(string pipeName, int timeoutMs, CancellationToken cancelToken, out string newPipeName){字符串 str = 管道名称；整数编号 = 1;while (File.Exists(string.Format("\\.\pipe\{0}", pipeName))){NamedPipeClientStream 结果；if ((result = BuildClient.TryConnectToProcess(pipeName, timeoutMs, cancelToken)) != null){新管道名称 = 管道名称；返回结果；}管道名称 = str + "."+ num.ToString(CultureInfo.InvariantCulture);数++；}新管道名称 = 管道名称；返回空；}

**让我再谈谈传递给 VBCSCompiler.exe 实例的特定 pipname 参数.我将不得不等到它再次发生.

解决方案

嗯，没有明显的重现场景，也没有人抱怨这个.您的解决方案并不罕见.将 cpu 固定到 100% 并让 VBCSCompiler 进程吞下约 1.5 GB 在大型项目中并不是很难，但当我看着我的项目时，它非常干净.

第一个可能的故障情况是您有一些未安装的测试版，这是一个非常常见的问题.使用调试器进行查看.使用 Debug > Attach to Process 并选择一个正在运行的实例.然后调试 > 全部中断和调试 > 查看 > 模块.注意版本号和时间戳，它们应该是这样的:

请注意，故意隐藏了一些列以使其可读.时间戳是 CST 时区.

<小时>

那是服务器端.存在您发现的错误的客户端位于 C:Program Files (x86)MSBuild14.0BinMicrosoft.Build.Tasks.CodeAnalysis.dll.看看它的属性，我的是 85,192 字节，创建于周日，2015 年 6 月 21 日，下午 7:06:54，文件版本号 1.0.0.50618.您可以使用 Reflector 或 ILSpy 等反编译器查看文件，导航到 BuildClient.TryAllProcesses().与错误修复相关的行是:

for (int i = 1; File.Exists(string.Format(@"\.pipe{0}", pipeName)); i++)

错误版本丢失\.pipe.

<小时>

请注意，上面的代码片段中的错误检查非常不充分，File.Exists() 返回 false 的原因有很多.这也是没有更早发现错误的基本原因.这会启用几种可能的故障模式，如果您的机器被程序员自愿安装的典型收缩包装恶意软件感染，则会启用这种故障模式.服务器和客户端代码通过具有特殊名称的命名管道相互连接.您可以在任务管理器的进程选项卡中看到的内容.使用视图">选择列"(Win8 及更高版本:右键单击列标题)并勾选命令行"选项:

注意 -pipename 参数.如果 File.Exists() 调用返回 false，则 MSBuild 将再次启动 VBCSCompiler.exe.如果您看到所有这些实例都使用相同的 -pipename 参数运行，那么您的计算机上运行的软件会干扰正常命名管道的使用.您首先要考虑的是寻找一种不太激进的反恶意软件解决方案.您可以编写一个使用 System.IO.Pipes 命名空间的小测试程序来获得更好的异常消息.

I just recently downloaded and installed Visual Studio Professional 2015 (14.0.23107.0). The first time I opened up our solution (28 projects) and performed a Build -> Rebuild Solution, my development machine came to an absolute crawl. The CPU was maxed out at 100% and the build never completed - even after > 10 minutes.

I opened up Windows Task Manager and noticed: > 10 VBCSCompiler.exe tasks running. When combined, these tasks sent the CPU > 90%.

Any idea why there are so many of these tasks running? Any way to stop this from happening?

This is the closest thing I can find to someone else experiencing the same issue: https://github.com/dotnet/roslyn/issues/2790

Update (8/7)

-Hans Passant, great thought. My manager provided me with this release (14.0.23107.0). Is this the correct version for the "official release"?? I did not knowingly install any of the per-release versions of Visual Studio 2015. I don't think there are any beta bits lying around.

-Kyle Trauberman, I'm not that familiar with environment variables in the context of Visual Studio; however, I naively ran set DisableRosyln=true in a VS (and MSBuild) Command Prompt Window. This did not seem to have any impact. VBCSCompiler.exe showed right back up even after restarting VS2015.

I repaired my VS2015 install and performed a reboot. This did not help.

Update Part 2 (8/7) -Hans Passant, very impressive write up!! Although, the problem didn't happen this time around, I took a look at the things you described:

As far as the modules loaded with the VBCSCompiler.exe, here's what I have:

It's interesting that our .NET core assemblies are at different versions. You're at 4.06.79 while, I'm at 4.06.81.

My "client side dlls" (located at C:Program Files (x86)MSBuild14.0BinMicrosoft.Build.Tasks.CodeAnalysis.dll) are at the same version and time stamp as yours:

Oddly enough, when I look at the code in ILSpy, I see something slightly different - optimization perhaps?

    private static NamedPipeClientStream TryAllProcesses(string pipeName, int timeoutMs, CancellationToken cancellationToken, out string newPipeName)
{
    string str = pipeName;
    int num = 1;
    while (File.Exists(string.Format("\\.\pipe\{0}", pipeName)))
    {
        NamedPipeClientStream result;
        if ((result = BuildClient.TryConnectToProcess(pipeName, timeoutMs, cancellationToken)) != null)
        {
            newPipeName = pipeName;
            return result;
        }
        pipeName = str + "." + num.ToString(CultureInfo.InvariantCulture);
        num++;
    }
    newPipeName = pipeName;
    return null;
}

**Let me get back with you on the specific pipname argument passed to the instances of VBCSCompiler.exe. I will have to wait until it happens again.

解决方案

Hmm, there is no obvious repro scenario and nobody else complains about this. Your solution is not unusual at all. Pegging the cpu to 100% and getting the VBCSCompiler process to swallow ~1.5 GB isn't very hard on a large project but it is squeaky clean when I look at mine.

First possible failure scenario that you have some uninstalled beta bits lying around, a very common problem. Use the debugger to have a look-see. Use Debug > Attach to Process and pick one of the running instances. Then Debug > Break All and Debug > View > Modules. Pay attention to the version numbers and timestamps, they ought to look like this:

Note that intentionally hid some columns to keep it readable. Time stamps are CST timezone.

---

That's the server side. The client side that had the bug you discovered is located in C:Program Files (x86)MSBuild14.0BinMicrosoft.Build.Tasks.CodeAnalysis.dll. Have a look at its properties, mine is 85,192 bytes and created on Sunday, ‎June ‎21, ‎2015, ‏‎7:06:54 PM, File version number 1.0.0.50618. You can look at the file with a decompiler like Reflector or ILSpy, navigate to BuildClient.TryAllProcesses(). The relevant line with the bug fix is:

for (int i = 1; File.Exists(string.Format(@"\.pipe{0}", pipeName)); i++)

The buggy version was missing \.pipe.

---

Note how error checking is very inadequate in the above snippet, File.Exists() returns false for many reasons. Also the basic reason the bug wasn't discovered earlier. That enables several possible failure modes, the kind enabled if your machine is infected by the typical shrinked-wrapped malware that programmers voluntarily install. The server and client code connect through each other through a named pipe with a special name. Something you can see in Task Manager, Processes tab. Use View > Select Columns (Win8 and up: right-click a column header) and tick the "Command line" option:

Note the -pipename argument. If the File.Exists() call returns false then MSBuild will start VBCSCompiler.exe again. If you see all these instances running with the same -pipename argument then you have software running on your machine that is interfering with normal named pipe usage. First thing you'd consider then is to look for a less aggressive anti-malware solution. You can write a little test program that uses the System.IO.Pipes namespace to get a better exception message.

这篇关于VBCSCompiler.exe 的大量实例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！