multithreading 错误 MSB4166：子节点过早退出。关闭

error MSB4166: Child node exited prematurely. Shutting down

提问by Ludwo

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?

它似乎是完全随机的，我无法随意复制它。我正在运行 VS2010 Win7 x64 MSBuild 4.0，但这个问题似乎与平台和操作系统无关。我正在并行构建解决方案（/m switch + BuildInParallel=True），我不想禁用此功能，因为我正在编译包含 800 多个项目的应用程序。知道如何解决吗？

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:

编辑：当我安装 .NET 4.5 开发者预览版时，MSBuild 4.5 中的错误日志得到了改进，现在错误字符串如下所示：

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:

我可以在 Temp 文件夹中找到错误日志文件。这是 MSBuild_*.failure.txt 文件的内容：

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()

回答by Fabio Cirone

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:

经过大量时间和研究试图解决这个问题，我找到了一个对我有用的解决方案。我正在使用带有 /m 和 /p:BuildInParallel=true 的 msbuild 并且构建在 CI 服务器中失败。它总是在第二个组件中失败并出现错误：

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

错误 MSB4166：子节点“3”过早退出。关闭。

Adding /nodeReuse:false fixed the problem.

添加 /nodeReuse:false 解决了这个问题。

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

这是一个很好的参考：https: //blogs.msdn.microsoft.com/msbuild/2007/04/16/node-reuse-in-multiproc-msbuild/

回答by Kevin Vermeer

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

奇怪的是，我在具有 4GB 物理和“无限”虚拟 RAM 的 64 位 Win7 笔记本电脑上使用 64 位 MSBuild。MSBuild 进程使用了​​大约 1GB 的 RAM（1.5GB 峰值）。– Ludwo 4 小时前

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

我在 32 位 WinXP 桌面上使用 32 位 MSBuild，具有 2GB 物理内存和类似的无限虚拟内存。奇怪的是，当物理 RAM 完全用完时会发生崩溃。就像我的虚拟内存为零一样！– 凯文·维米尔 3 小时前

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

是的，似乎 MSBuild 没有使用虚拟内存 :) – Ludwo 2 小时前

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

看起来 MSbuild 没有使用虚拟内存。我做了一些测试（启动一堆程序），似乎没有使用虚拟内存。我做了一些搜索，导致我检查

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.

并发现存在一个限制我的虚拟内存大小系统范围的设置。我曾想象虚拟内存实际上是无限的，或者更准确地说，32 位 XP 上的每个进程有 4 GB。我没有接近这个极限。但是，我的虚拟内存空间被限制为...0MB。不酷，不管是谁做的。

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.

我将其更改为分配最少 1024 MB 和最多 4096 MB 的虚拟内存。我在Process Explorer 中添加了“Virtual size”列，它与“System Commit”图一起表明我现在使用的内存比物理 RAM 棒中的可用内存多。

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.

这解决了我的问题。不幸的是，每当我的系统尝试对任何内存进行分页时，它都会几乎停止运行，但这总比崩溃要好。我确实重新启用了并行构建；当我还有 RAM 时它会并行化并使用大量 CPU（对于大多数文件来说都是如此）并且当我没有更多 RAM 时会下降到 1% 的 CPU 使用率。完成这些文件后，速度就会恢复。

回答by William Jockusch

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

就我而言，答案是更新 Antlr。显然，这仅适用于您在项目中使用 Antlr 的情况。

回答by tehlexx

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

我们得到了同样的 msbuild 错误，并且在日志文件中有

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.

我们能够通过设置环境变量禁用 msbuild-node 重用功能来解决该问题MSBUILDDISABLENODEREUSE=1。

回答by MikeBMcL

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

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.

如果您使用普通的 Reference 标签来依赖作为构建一部分的另一个项目的输出（而不是 ProjectReference 标签），您可能会遇到这样的情况：通常项目 X 在项目 Y 之前完成（这取决于项目 X 的输出），但偶尔它们会同时构建，在这种情况下，当 Y 去寻找它时 X 的输出将不存在，从而导致 Y 失败。我找不到任何关于 MSBuild 在那种情况下给出什么样的错误输出的信息（而且现在还没有现成的方法来测试它），所以可能不是这样。

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

结果的不一致（通常是成功的，偶尔是失败的）让我怀疑类似的事情很可能是原因。

回答by David Q Hogan

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)

您可能会耗尽内存，导致其中一个构建子进程失败 - 如果您使用 /m:2 将其限制为两个并发构建，它是否会减少失败？（假设您有 2 个以上的内核）

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?

或者，如果您可以从另一台机器借用一些 RAM，或者增加交换大小，当您在构建机器上安装更多内存时，这种情况是否会减少？

回答by Tam Bui

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.

对我来说，这是因为我无意中将一个对 .NET Framework 4.6.1 项目的项目引用添加到了我的一个 .NET Standard 2.0 项目中。在撰写本文时，以及在 VS 2017 15.9.12 中，您可能几乎没有注意到这是在您的参考资料中的解决方案资源管理器中显示的“黄色三角形”符号，表示可能有问题。我有一个包含多个项目的解决方案，在构建解决方案中间的某个地方，它会因“子节点 X 过早退出”而失败，在随机项目中，并且在失败的地方永远不会一致。

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.

一旦我将错误追溯到有问题的 .NET Framework 4.6.1 引用项目，我就将这个 .NET Framework 4.6.1 项目转换为 .NET Standard 2.0，所有这些子节点 X 错误都消失了。

Hope this helps anyone reading.

希望这对任何阅读的人都有帮助。