31

有时我的构建会因此错误而失败。

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

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

编辑：当我安装 .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

我可以在 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()
4

7 回答 7

14

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

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

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

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

于 2019-02-13T14:32:53.907 回答
4

正如在对该问题的评论交流中所讨论的：

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

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

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

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

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

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

我将其更改为分配最少 1024 MB 和最多 4096 MB 的虚拟内存。我在Process Explorer中添加了“虚拟大小”列，该列与“系统提交”图一起表明我现在使用的内存比物理 RAM 棒中的可用内存量更多。

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

于 2011-11-02T14:56:53.457 回答
2

我们得到了相同的 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)
===================

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

于 2019-01-30T11:46:57.180 回答
2

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

于 2017-07-30T02:18:01.110 回答
1

也许这是竞争条件的构建等价物？

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

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

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

于 2011-11-05T04:47:41.647 回答
1

您可能内存不足，导致其中一个构建子进程失败 - 如果您使用 /m:2 将其限制为两个并发构建，它的失败会更少吗？（假设你有超过 2 个核心）

或者，如果您可以从另一台机器借用一些 RAM，或者增加交换大小，那么当您在构建机器上安装更多内存时，这种情况发生的频率会降低吗？

于 2011-10-31T07:22:35.373 回答
0

只是想为那些无法通过此处的其他回复解决此问题的人添加我的案例和解决方案。

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

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

希望这可以帮助任何人阅读。

于 2019-05-17T17:03:53.087 回答