Numerous instances of VBCSCompiler.exe

Question

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)\MSBuild\14.0\Bin\Microsoft.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.

Answer 1

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)\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++)

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.

Answer 2

Any idea why there are so many of these tasks running?

Roslyn uses a shared compiler process that keeps your compiled code in memory for reuse in subsequent compiles. So the second compile will be quicker, but as you've seen there's a memory overhead.

Any way to stop this from happening?

Yes. From here there's a property of the compile task in msbuild that turns off the shared compiler, and it's set to true by default.

So in each project you'll have to add this property to the project file. Or in Visual Studio 2015 there's now shared projects, where you could add this property to the shared project and then include that shared project in all the other projects that need this setting.

<PropertyGroup>
  <UseSharedCompilation>false</UseSharedCompilation>
</PropertyGroup>

Answer 3

As of November 22, 2015 this issue was still happening to me in the Visual Studio 2015 community edition. My laptop was starting to double as a space heater with all of the instances of VBCSCompiler running full throttle.

The only fix that worked for me was to locate the file VBCSCompiler.exe in the /bin/roslyn directory of the web application and change security permissions on it.

You need to deny read & execute permission for the AppPool that your web app is running under.

Answer 4

According to Slaks, you can disable roslyn (which is what the VBCSCompiler.exe appears to be) by setting the DisableRoslyn environment variable to true.

See http://blog.slaks.net/2014-05-21/exploring-roslyn-part-2-inside-end-user-preview/ for more information.

Note, the link above is for the preview, but I can't imagine that it would have changed much between then and now.

Answer 5

You can also change "keep alive" option for VBCSCompiler, to close it just after execution... You need to modify "VBCSCompiler.exe.config" file ("C:\Program Files (x86)\MSBuild\14.0\Bin\VBCSCompiler.exe.config") and set needed value in seconds (by default it's 600).

Answer 6

Also encountered this issue with Visual Studio Enterprise 2015, Update 1. The issue was solved by upgrading to Update 2.

Answer 7

I found that changing the identity to 'NetworkService' in the Application pool advanced settings sorted out the problem for me.