Ошибка MSB4166: ребенок node вышел преждевременно. Выключение

Ответ 1

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

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

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

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

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

Возможно, это строительный эквивалент состояния гонки?

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

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

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

Ответ 5

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

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

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

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

Ответ 6

Мы получили ту же ошибку 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.

Ответ 7

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

Для меня это было потому, что я случайно добавил ссылку на проект .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 исчезли.

Надеюсь, что это помогает любому читать.