MSB4166子节点过早退出.关闭

有时我的构建失败了这个错误。

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

它似乎完全是随机的，我无法随意复制它。我正在运行VS2010 Win7 x64 MSBuild 4.0，但这个问题似乎与平台和操作系统无关。我正在并行构建解决方案(/m开关+ 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()

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

错误MSB4166:子节点"3"过早退出。关闭。

添加/nodeReuse:false修复问题。

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

在对问题交换意见时讨论:

奇怪的是，我在64位Win7笔记本电脑上使用64位MSBuild，拥有4GB物理和"无限"虚拟RAM。MSBuild进程使用了大约1GB的RAM(峰值1.5 gb)。- Ludwo 4 hours ago

我在32位WinXP桌面上使用32位MSBuild，具有2GB物理和类似的无限虚拟RAM。奇怪的是，当物理RAM完全用完时发生崩溃。就像我没有任何虚拟内存一样!- Kevin Vermeer 3 hours ago

是的，MSBuild似乎没有使用虚拟内存:)- Ludwo 2 hours ago

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

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

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

我将其更改为分配最小1024 MB和最大4096 MB的虚拟内存。我在Process Explorer中添加了"Virtual size"列，它与"System Commit"图一起显示，我现在使用的内存超过了物理RAM棒中的可用内存。

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

对于我来说，答案是更新Antlr。显然，这只适用于在项目中使用Antlr的情况。

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

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

如果有人仍然遇到这个错误并且其他答案都不起作用，对我来说，可靠地解决它的唯一方法是设置-maxCpuCount:1 (-m:1) (MSBuild命令行参考)。

这是Debian 10 (buster)上的dotnet core 6.0.300。

也供参考:如果有人不知道MSBuild标志是如何应用时使用dotnet cli，他们可以追加到许多命令(1)使用MSBuild内部(与-或/)，例如:

# shell
dotnet restore "example/example.csproj" -maxCpuCount:1
dotnet build "example/example.csproj" /maxCpuCount:1 /nodeReuse:false

(1)例外似乎是结合其他dotnet *命令的命令，如dotnet run;其中大部分可以在dotnet构建参考中找到。

您可能会耗尽内存，导致其中一个构建子进程失败—如果使用/m:2将其限制为两个并发构建，它会失败得更少吗?(假设您有超过2个内核)

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

也许这是构建中的竞争条件?

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

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

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

只是想把我的情况和解决方案添加到那些无法解决这个问题的人。

对我来说，这是因为我无意中将一个。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，所有这些子节点X错误都消失了。

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

我能够通过在Visual Studio命令提示符中执行以下命令来解决VS 2017中的此问题。

gacutil /i "C:Program Files (x86)Microsoft Visual Studio2017ProfessionalMSBuild15.0BinMicrosoft.Build.Framework.dll"
gacutil /i "C:Program Files (x86)Microsoft Visual Studio2017ProfessionalMSBuild15.0BinMicrosoft.Build.dll"
gacutil /i "C:Program Files (x86)Microsoft Visual Studio2017ProfessionalMSBuild15.0BinMicrosoft.Build.Engine.dll"
gacutil /i "C:Program Files (x86)Microsoft Visual Studio2017ProfessionalMSBuild15.0BinMicrosoft.Build.Conversion.Core.dll"
gacutil /i "C:Program Files (x86)Microsoft Visual Studio2017ProfessionalMSBuild15.0BinMicrosoft.Build.Tasks.Core.dll"
gacutil /i "C:Program Files (x86)Microsoft Visual Studio2017ProfessionalMSBuild15.0BinMicrosoft.Build.Utilities.Core.dll"

相关内容

最新更新

热门标签：