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.