VBCSCompiler.exe的许多实例 [英] Numerous instances of VBCSCompiler.exe

问题描述

我刚刚下载并安装了Visual Studio专业版2015年（14.0.23107.0）。我第一次打开了我们的解决方案（28个项目），并进行了建设 - >重建解决方案，我的机器来到一个绝对的抓取。该CPU被刷爆了100％和构建从未完成 - 即使在10分

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.

我打开Windows任务管理器，发现：> 10 VBCSCompiler.exe任务运行。合并后，这些任务送的CPU> 90％。

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?

这是最接近我能找到别人遇到了同样的问题：<一href="https://github.com/dotnet/roslyn/issues/2790">https://github.com/dotnet/roslyn/issues/2790

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

更新（8/7）

-Hans帕桑特，伟大的思想。我的经理为我提供了这个版本（14.0.23107.0）。这是正确的版本为正式发布？我没有故意安装任何的每个发行版本的Visual Studio 2015的，我不认为有任何的β位躺在附近的。

-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，我没那么熟悉的Visual Studio环境的环境变量;不过，我天真地跑设置DisableRosyln =在VS（和MSBuild的）真正命令提示符窗口。这似乎没有产生任何影响。 VBCSCompiler.exe即使重新启动VS2015后表现出右后卫。

-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.

我修好我的VS2015安装和执行重新启动。这并没有帮助。

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

更新第2部分（8/7） -Hans帕桑特，很IM pressive写上去！虽然，这个问题没有发生在这段时间，我看了一下你所描述的事情：

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:

至于装有VBCSCompiler.exe模块，这里是我的：

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

有趣的是，我们的.NET的核心组件是在不同的版本。你是在79年4月6日同时，我在81年4月6日。

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.

我的客户端的DLL（位于C：\ Program Files文件（x86）的\的MSBuild \ 14.0 \斌\ Microsoft.Build.Tasks codeAnalysis.dll）是同一版本和时间戳和你：

My "client side dlls" (located at C:\Program Files (x86)\MSBuild\14.0\Bin\Microsoft.Build.Tasks.CodeAnalysis.dll) are at the same version and time stamp as yours:

奇怪的是，当我看code在ILSpy，我看到一些略有不同 - 优化也许

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;
}

**让我回来跟你传递给VBCSCompiler.exe的情况下，具体的pipname说法。我将不得不等待，直到它再次发生。

**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.

推荐答案

嗯，没有明显的摄制场景，没有人抱怨这一点。您的解决方案是不寻常的。假如将CPU为100％，获得VBCSCompiler过程吞下〜1.5 GB的是不是很辛苦的一个大项目却是干干净净的，当我看到我的。

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:

请注意，故意隐瞒某些列，以保持它的可读性。时间戳CST时区。

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

这就是服务器端。该客户端是有你发现位于C错误：\ Program Files文件（x86）的\的MSBuild \ 14.0 \斌\ Microsoft.Build.Tasks codeAnalysis.dll。看看它的属性，我的是85192个字节，周日，2015年6月21日，下午7点06分54秒，文件版本号1.0.0.50618创建。你可以看一下有像反射或ILSpy反编译的文件，浏览到BuildClient.TryAllProcesses（）。与bug修复的相关行是：

That's the server side. The client side that had the bug you discovered is located in C:\Program Files (x86)\MSBuild\14.0\Bin\Microsoft.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++)

马车版本缺少 \\。\管道\ 。

请注意是如何错误检查是非常不够的，在上面的代码片段，File.Exists（）返回的假的原因是多方面的。同样的基本原因的错误是没有早点发现。这使一些可能的故障模式，启用如果你的机器被感染了典型的收缩包装的恶意软件程序员自行安装的那种。服务器和客户端code通过相互连接通过命名管道有一个特别的名字。有些东西你可以在任务管理器中看到，进程选项卡。使用查看>选择列（在Win8和高达：右键单击列标题），并勾选命令行选项：

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:

注意 -pipename 参数。如果File.Exists（）调用返回的假的那么的MSBuild将再次启动VBCSCompiler.exe。如果你看到所有的这些实例中运行具有相同-pipename的说法，那么你有你的机器，干扰了正常的命名管道用法上运行的软件。你会考虑那么第一件事情就是找一个不太积极的反恶意软件解决方案。您可以编写使用System.IO.Pipes命名空间，以获得更好的异常消息一个小的测试程序。

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屋！