Build 2.2 causes build error ("child node 2 exited prematurely", IOException, "pipe is broken")

[Sergio0694]

Describe the bug

Updating to the new Microsoft.UI.Xaml package version 2.2 causes the following build error for me:

Child node "2" exited prematurely. Shutting down.

UNHANDLED EXCEPTIONS FROM PROCESS 10252:
=====================
06/09/2019 01:30:38
System.IO.IOException: Pipe is broken.
   at System.IO.Pipes.PipeStream.CheckWriteOperations()
   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)
===================

Steps to reproduce the bug

Steps to reproduce the behavior:

1. Update Microsoft.UI.Xaml to 2.2
2. Try to build the app

NOTE: this is happening for me with a specific app, and I'd be happy to give access to the solution to someone from the team to look into it. I've already tried to clean the solution, restart VS, update VS, even tried on 2 different devices, same error. If I try to reproduce this with a blank UWP app, it works just fine and builds with no problems, but I have no clue on what's triggering this in particular in my current app. Due to the nature of the error though, this clearly looks like an issue with the library and not with my actual code (which works just fine with WinUI version 2.1).

Expected behavior

The app should just build

Version Info

NuGet package version:
Microsoft.UI.Xaml 2.2.190830001

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
May 2019 Update (18362)	Yes
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)

Additional info
I can confirm that this is happening to other developers as well. Here's an error log I got from one of them (which is pretty similar to the one I'm getting):

Error Child node "3" exited prematurely. Shutting down. Diagnostic information may be found in files in "C:\Users\F8R\AppData\Local\Temp" and will be named MSBuild_*.failure.txt. This location can be changed by setting the MSBUILDDEBUGPATH environment variable to a different directory.
C:\Users\F8R\AppData\Local\Temp\MSBuild_pid-18428_813ed25b544d4e6dbccee0f95f096e6d.failure.txt:

UNHANDLED EXCEPTIONS FROM PROCESS 18428:
=====================
9/5/2019 4:24:44 PM
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)
===================    Rewrite 

[Sergio0694]

So, turns out this isn't caused by WinUI itself, but rather by the SDK 18363 that's breaking my app as well as the app of some other UWP devs. Closing this, since it's off topic with respect to WinUI.

[jevansaks]

@sotteson1 may be able to help with SDK issues. I'm not sure the right place to report them but if it's crashing MSBuild then perhaps filing a bug using the Visual Studio "send feedback" button (in VS itself) may collect the right logs.

[jevansaks]

This is apparently an issue with the SDK as you found. HEre's some more details: https://dvlup.com/2019/08/07/postmortem-child-node-2-compilation-error-after-updating-to-18362-sdk/

And the SDK folks say this is fixed in latest insider SDK flights.

[Sergio0694]

Hi @jevansaks - thank you for following up on this, even though it's not really an issue caused by WinUI. I'm aware of that block post (a couple other MS engineers have linked it to me as well), but unfortunately that hasn't solved the issue for me just yet.
I know the issue has been resolved in the new preview SDK, and apparently the team working on that is considering backporting it to the 19H1 SDK as well, so fingers crossed for that 🤞

Currently there's @LanceMcCarthy that has kindly offered to help and is looking at my repo to reproduce the issue on his end and possibly figure out a way to work around that on the current SDK.

Thank you all again for your time and your help, I really appreciate it!

...And people said the Windows dev community wasn't that great 😄

[michael-hawker]

FYI @jevansaks @ranjeshj hit this same issue or something pretty similar just now on 2004 (it's building fine on another machine with 1909). It's something in this commit range to the sample page xaml file there at the top. I'll try and filter it down a bit more tomorrow.

[michael-hawker]

Yup, I've confirmed it looks like a weird version of the same issue @jevansaks linked to.

As if I add the extra namespaces to the top:

    xmlns:base="using:Microsoft.Toolkit.Uwp.UI.Media.Base"
    xmlns:effects="using:Microsoft.Toolkit.Uwp.UI.Media.Effects"
    xmlns:effectbase="using:Microsoft.Toolkit.Uwp.UI.Media.Effects.Abstract"
    xmlns:int="using:Microsoft.Toolkit.Uwp.UI.Media.Effects.Interfaces"

Then I can build again.

The weird thing though is that it seems to work for others on 1909 targeting the 18362 SDK in VS 2019. However, trying to compile on OS 2004 caused it to break.

I tried retargeting the app to the 19041 SDK and then it worked again! Really really odd.

[Sergio0694]

According to the tracking issue in the VS feedback hub (here), the fact that it builds fine when targeting the 19041 SDK makes perfect sense, as this issue was apparently caused by a XAML compiler bug in the toolchain set for the 18362 SDK. The super weird things though are:

• The fact that I can build that just fine targeting the 18362 SDK, on a W10 19H2 system.
• The fact that for you the build is breaking down just for using W10 20H1 at all.

I'm very confused 🤣

[LanceMcCarthy]

It just seems to come down to using any properties that are only defined on the base class that has no xmlns.

e.g.

namespace MyLibrary.BaseStuff
{
    public class MyBaseControl : UIElement
    {
           public DependencyProperty PixelHeightProperty {...}
           public double PixelHeight {...}
    }
}

and a control that inherits from that:

namespace MyLibrary.Controls
{
    public class MyConcreteControl : MyBaseControl
    { }
}

If you use that control and set the DependencyProperty that is defined in the base...

<Page xmlns:myControls="using:MyLibrary.Controls" >
    <myControls:MyConcreteControl PixelHeight="200" />
</Page>

that replicates the issue.

The workaround is to make sure the compiler has access to the base where the DP is defined:

<Page xmlns:myControls="using:MyLibrary.Controls"
            xmlns:ExcpetionPreventer="using:MyLibrary.BaseStuff">
    <myControls:MyConcreteControl PixelHeight="200" />
</Page>

@michael-hawker Reach out to Alan Wu (WDG), he's the one who discovered the cause and offered the workaround

[michael-hawker]

Also, running a Release mode version of the package built on 1909 worked fine on 2004, so it appears to be purely a build issue.

[michael-hawker]

@StephenLPeters if you need another repo, building the Sample App out of the current master of the Windows Community Toolkit should exhibit the problem: https://github.com/windows-toolkit/WindowsCommunityToolkit#-required-dependencies

My co-worker hit it on their machine as well running 2004.

[Sergio0694]

To add to this, I can confirm that in my case, setting the 19041 SDK as target SDK for my app solved the issue, I can now finally build it without having to change anything. For reference, if I keep the target SDK to 18362 and try to build an app package from a PC with Windows 10 19041, the app package creation will just fail with that "child node 2 exited" error message.

[yoshiask]

I'm hitting this same error when attempting to build the Windows Community Toolkit Sample App, targeting Windows 10 18362, with Windows 10 18363.

[LanceMcCarthy]

@yoshiask The problem is in the 18362 SDK. Since there was no updated SDK for 18363, you needed to wait for the new SDK that has the fix: 19041, which is available now.

1. Open the Visual Studio Installer app
2. Click Modify
3. Switch to the Individual Components tab
4. Scroll down to and check the Windows 10 SDK v19041 option
5. Complete the update

After that's done, update the project's Target SDK to 19041, then do a Rebuild.

[michael-hawker]

To clarify, I've seen similar issue with "child node 3" and "child node 9", I think they're all related to the same root issue.

[michael-hawker]

So, just hit this in another inheritance scenario. In this commit, I had one of our controls inherit from another in a different namespace/assembly.

If I add any properties from the base control to it in the MainPage.xaml where I use the control, then the compile step blows up and gives me this error:

MSBUILD : error MSB4166: Child node "2" exited prematurely. Shutting down.

<wgt:PeoplePicker x:Name="PeopleChooser" PlaceholderText="Testing"/>

Where PeoplePicker is a TokenizingTextBox and PlaceholderText is a property from the TokenizingTextBox.

[LanceMcCarthy]

Aha, that's exactly the problem that was supposed to be fixed in 19041. Add the xmlns for the TokenizingTextbox to the page, even though it won't be used anywhere, and it will fix that.

[michael-hawker]

Thanks @LanceMcCarthy, I forgot to call out that appeared to help (though I was noticing other issues with one of our properties I'll have to investigate).

It'll be a pain for anyone to use though as they'll have to do that down-stream too, eh?

[LanceMcCarthy]

yep, as far as I can tell, all downstream consumers are affected. check out what I had to do with the input namespace here https://dvlup.com/2019/08/07/postmortem-child-node-2-compilation-error-after-updating-to-18362-sdk/

[evelynwu-msft]

This was fixed a while ago. (For future reference the internal bug is https://task.ms/23467613.)