error MSB4166: Child node exited prematurely. Shut

问题:

Sometimes my build fail with this error.

 0>MSBUILD : error MSB4166: Child node "3" exited prematurely. Shutting down.

It seems to be completely random and I've not been able to reproduce it at will. I'm running VS2010 Win7 x64 MSBuild 4.0 but this problem seems to be platform and OS independent. I'm building solutions in parallel (/m switch + BuildInParallel=True) and I don't want to disable this feature because I'm compiling application containing 800+ projects . Any idea how to solve it?

EDIT: When I installed .NET 4.5 developer preview, error logging was improved in the MSBuild 4.5 and now the error string looks like this:

error MSB4166: Child node "3" exited prematurely. Shutting down. Diagnostic information may be found in files in the temporary files directory named MSBuild_*.failure.txt

I can find error log file in the Temp folder. This is content of MSBuild_*.failure.txt file:

System.InvalidOperationException: BuildEventArgs has formatted message while serializing!
   at Microsoft.Build.Framework.LazyFormattedBuildEventArgs.WriteToStream(BinaryWriter writer)
   at Microsoft.Build.Framework.BuildMessageEventArgs.WriteToStream(BinaryWriter writer)
   at Microsoft.Build.Shared.LogMessagePacketBase.WriteToStream(INodePacketTranslator translator)
   at Microsoft.Build.BackEnd.NodeEndpointOutOfProcBase.PacketPumpProc()

回答1:

After a lot of time and research trying to fix this problem I found a solution that worked for me. I am using msbuild with /m and /p:BuildInParallel=true and the build was failing in the CI server. It was always failing in the second componen with the error:

error MSB4166: Child node "3" exited prematurely. Shutting down.

Adding /nodeReuse:false fixed the problem.

This is a good reference: https://blogs.msdn.microsoft.com/msbuild/2007/04/16/node-reuse-in-multiproc-msbuild/

回答2:

As discussed in the exchange of comments to the question:

Strange thing is that I'm using 64bit MSBuild on 64bit Win7 laptop with 4GB of physical and "unlimited" virtual RAM. MSBuild process is using about 1GB of RAM (1,5GB peak). – Ludwo 4 hours ago

I'm using 32bit MSBuild on a 32-bit WinXP desktop with 2GB of physical and similarly unlimited virtual RAM. The weird thing is that the crash occurs when physical RAM is completely used up. It's like I've got zero virtual memory! – Kevin Vermeer 3 hours ago

Yes, it seems like MSBuild is not using virtual memory :) – Ludwo 2 hours ago

It did seem like MSbuild wasn't using virtual memory. I did some tests (starting a bunch of programs) and it seemed like nothing was using virtual memory. I did some searches which lead me to check

Control Panel -> System -> Advanced -> Performance -> Advanced -> Virtual Memory

and found that there exists a setting which limited my virtual memory size system-wide. I had imagined that virtual memory to be effectively infinite, or, more precisely, 4 GB for each process on 32-bit XP. I wasn't approaching this limit. However, my virtual memory space was limited to...0MB. Not cool, whoever or whatever did that.

I changed this to allocate a minimum of 1024 MB and a maximum of 4096 MB of virtual memory. I added the "Virtual size" column in Process Explorer, which, together with the "System Commit" graph, demonstrates that I now use more memory than the amount available in the physical RAM sticks.

This fixed my problems. Unfortunately, my system grinds to a near-halt whenever it tries to page any memory, but that's better than a crash. I did re-enable parallel builds; it parallelizes and uses lots of CPU while I have RAM left (which is true for most of the files) and dips to 1% of CPU usage when I have no more RAM. When those files are done, speed is restored.

回答3:

In my case, the answer was to update Antlr. Obviously, this only applies if you are using Antlr in your project.

回答4:

We got the same msbuild error, and in the log file there was

UNHANDLED EXCEPTIONS FROM PROCESS 10260:
=====================
05/01/2019 18:41:55
System.IO.IOException: Pipe is broken.
  at System.IO.Pipes.PipeStream.WinIOError(Int32 errorCode)
  at System.IO.Pipes.PipeStream.BeginWriteCore(Byte[] buffer, Int32 offset, Int32 count, AsyncCallback callback, Object state)
  at System.IO.Pipes.PipeStream.WriteCore(Byte[] buffer, Int32 offset, Int32 count)
  at System.IO.Pipes.PipeStream.Write(Byte[] buffer, Int32 offset, Int32 count)
  at Microsoft.Build.BackEnd.NodeEndpointOutOfProcBase.RunReadLoop(Stream localReadPipe, Stream localWritePipe, ConcurrentQueue`1 localPacketQueue, AutoResetEvent localPacketAvailable, AutoResetEvent localTerminatePacketPump)
===================

We were able to resolve the issue by disabling the msbuild-node reuse feature by setting the environment variable MSBUILDDISABLENODEREUSE=1.

回答5:

You could be running out of memory, causing one of the build sub processes to fail - does it fail less if you use /m:2 to restrict it to two concurrent builds? (assuming you have more than 2 cores)

Or, if you can borrow some RAM from another machine, or increase your swap size, does it happen less often when you have more memory installed on your build machine?

回答6:

Perhaps it's the build-equivalent of a race condition?

http://blogs.msdn.com/b/msbuild/archive/2007/04/26/building-projects-in-parallel.aspx

If you are using an ordinary Reference tag for a dependency on the output of another project that is part of the build (rather than a ProjectReference tag) you could be getting a situation where usually project X completes before project Y (which depends on project X's output) but occasionally they build concurrently, in which case the output of X would not exist when Y went to look for it, causing Y to fail. I can't find anything about what sort of error output MSBuild gives in that situation though (and don't have a readily available way to test it just now), so that may not be it.

Still the inconsistency in the outcomes (often successful, occasionally fails) leads me to suspect that something like that may well be the cause.

回答7:

Just wanted to add my case and resolution for those who weren't able to resolve this issue with the other responses here.

For me, it was because I had inadvertently added a project reference to a .NET Framework 4.6.1 project to one of my .NET Standard 2.0 projects. As of this writing, and VS 2017 15.9.12, you may barely notice this as a "yellow triangle" symbol shown in Solution Explorer in your References that something might be wrong. I had a solution with several of projects, and somewhere in the middle of Build Solution, it would fail with this "Child Node X exited prematurely", on random projects, and never consistent where it failed.

Once I traced the mistake to the offending .NET Framework 4.6.1 referenced project, I converted this .NET Framework 4.6.1 project to .NET Standard 2.0, and all of these Child Node X errors went away.

Hope this helps anyone reading.