ошибка MSB4166: дочерний узел вышел преждевременно. Выключение - PullRequest
25 голосов
/ 27 октября 2011

Иногда моя сборка завершается с этой ошибкой.

 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 _ *. Fault.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()

Ответы [ 7 ]

4 голосов
/ 13 февраля 2019

После долгих исследований и попыток решить эту проблему, я нашел решение, которое сработало для меня. Я использую msbuild с / m и / p: BuildInParallel = true, и сборка на сервере CI не удалась Во втором компоненте всегда происходил сбой с ошибкой:

ошибка MSB4166: дочерний узел "3" завершился преждевременно. Выключение.

Добавление / nodeReuse: false исправило проблему.

Это хорошая ссылка: https://blogs.msdn.microsoft.com/msbuild/2007/04/16/node-reuse-in-multiproc-msbuild/

4 голосов
/ 02 ноября 2011

Как обсуждалось при обмене комментариями к вопросу:

Странно то, что я использую 64-битную MSBuild на 64-битном ноутбуке Win7 с 4 ГБ физической и «неограниченной» виртуальной оперативной памяти.Процесс MSBuild использует около 1 ГБ ОЗУ (1,5 ГБ пик).- Ludwo 4 часа назад

Я использую 32-битную MSBuild на 32-битном рабочем столе WinXP с 2 ГБ физической и аналогичной неограниченной виртуальной оперативной памяти.Странно то, что сбой происходит, когда физическая память полностью израсходована.Как будто у меня нулевая виртуальная память!- Кевин Вермеер 3 часа назад

Да, похоже, что MSBuild не использует виртуальную память :) - Ludwo 2 часа назад

Похоже, что MSbuildне использовал виртуальную память.Я провел несколько тестов (запустил кучу программ), и казалось, что ничто не использует виртуальную память.Я сделал несколько поисков, которые заставили меня проверить

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

и обнаружил, что существует настройка, ограничивающая размер моей виртуальной памяти в масштабе всей системы.Я предполагал, что виртуальная память будет фактически бесконечной, или, точнее, 4 ГБ для каждого процесса в 32-разрядной XP.Я не приближался к этому пределу.Тем не менее, объем моей виртуальной памяти был ограничен ... 0 МБ.Не круто, кто бы это ни делал.

Я изменил это, чтобы выделить минимум 1024 МБ и максимум 4096 МБ виртуальной памяти.Я добавил столбец «Виртуальный размер» в Process Explorer , который вместе с графиком «Подтверждение системы» демонстрирует, что теперь я использую больше памяти, чем объем, доступный в физических флеш-накопителях.

Это исправило мои проблемы.К сожалению, моя система практически останавливается всякий раз, когда она пытается листать какую-либо память, но это лучше, чем сбой.Я снова включил параллельные сборки;он распараллеливает и использует много ресурсов ЦП, в то время как у меня остается ОЗУ (что верно для большинства файлов) и снижает до 1% использования ЦП, когда у меня больше нет ОЗУ.Когда эти файлы сделаны, скорость восстанавливается.

2 голосов
/ 30 июля 2017

В моем случае ответом было обновить Antlr.Очевидно, это применимо, только если вы используете Antlr в своем проекте.

1 голос
/ 30 января 2019

Мы получили ту же ошибку 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, установив переменную среды MSBUILDDISABLENODEREUSE=1.

1 голос
/ 05 ноября 2011

Возможно, это эквивалент гонок?

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

Если вы используете обычный тег Reference для зависимости от вывода другого проекта, являющегося частью сборки (а не тега ProjectReference), вы можетевозникает ситуация, когда обычно проект X завершается до проекта Y (что зависит от результатов проекта X), но иногда они создаются одновременно, и в этом случае выходные данные X не будут существовать, когда Y будет его искать, что приведет к сбою Y.Я не могу найти что-либо о том, какой вывод ошибок выдает MSBuild в этой ситуации (и у меня нет доступного способа проверить это прямо сейчас), так что это может быть не так.

Тем не менеенесогласованность результатов (часто успешных, иногда неудачных) заставляет меня заподозрить, что причиной может быть что-то подобное.

1 голос
/ 31 октября 2011

Возможно, у вас не хватает памяти, что приводит к сбою одного из подпроцессов сборки - не станет ли он меньше, если вы используете / m: 2, чтобы ограничить его двумя одновременными сборками? (при условии, что у вас более 2 ядер)

Или, если вы можете заимствовать часть ОЗУ с другого компьютера или увеличить размер подкачки, это случается реже, когда на сборочном компьютере установлено больше памяти?

0 голосов
/ 17 мая 2019

Просто хотел добавить мой случай и решение для тех, кто не смог решить эту проблему с другими ответами здесь.

Для меня это было потому, что я случайно добавил ссылку на проект в a.NET Framework 4.6.1 проект для одного из моих проектов .NET Standard 2.0.На момент написания этой статьи и VS 2017 15.9.12 вы можете едва заметить это как символ "желтого треугольника", показанный в обозревателе решений в ваших ссылках, что что-то может быть не так.У меня было решение с несколькими проектами, и где-то в середине Build Solution оно не получалось с этим «Дочерним узлом X преждевременно завершенным», на случайных проектах и ​​никогда не соответствовало тому, где оно провалилось.отследил ошибку до ссылочного проекта .NET Framework 4.6.1, я преобразовал этот проект .NET Framework 4.6.1 в .NET Standard 2.0, и все эти ошибки дочернего узла X исчезли.

Надеюсь, что этопомогает всем, кто читает.

...