[Update May 2020] This has been fixed in the 19041 SDK. Install the 19041 SDK, set your project’s Target SDK to 19041 and finally Rebuild the project/solution.
One of the more frustrating things for me is not being able to debug a problem. After updating my UWP app’s Target SDK to 18362 (Windows 10 1903), I was no longer able to compile. I got a very vague error. that I had to dig out of the msbuild logs:
Child node "2" exited prematurely. Shutting down.
So I dug into the msbuild logs and found the original error message
Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at Microsoft.Windows.UI.Xaml.Build.Tasks.NativeMethodsHelper.Write(…)
at Microsoft.Xaml.XBF.XbfGenerator.GenerateXbfFromStreams(…)
Which was ultimately caused by this process exception
UNHANDLED EXCEPTIONS FROM PROCESS 22472:
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)
After several hours try trying different things to isolate what was causing the issue, I reached out to the engineering team at Microsoft. They took over and dug deeper, which actually required the WDG group to investigate (big shout out to Alan!).
The problem stems from using a property of a custom base class in XAML. For example, if you have a custom control, for example a Telerik control. You need to have the base class listed in the xmlns of the XAML, even if you aren’t explicitly using it.
To make this simple, let’s use an example. This is the specific scenario that caused my error, but it can happen with any custom control. Look at the code sample below. As you can see on Line 5 the xml namespace is defined as input, and it is used on Line 10 for the RadRangeSlider.
<UserControl xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="https://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="https://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:input="using:Telerik.UI.Xaml.Controls.Input"
mc:Ignorable="d"
d:DesignHeight="400"
d:DesignWidth="400">
<Grid>
<input:RadRangeSlider Minimum="0" Maximum="10"/>
</Grid>
</UserControl>
Notice the Minimum and Maximum properties, those are actually defined in a base class, not in the RadRangeSlider class… this is what causes the exception in the latest SDK.
This will be fixed in a future UWP SDK release, but for now the workaround is to define the xmlns of the base class, even though you’re not explicitly using it. Here’s the fixed version of that code, notice Line 6.
<UserControl xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="https://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="https://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:input="using:Telerik.UI.Xaml.Controls.Input"
xmlns:controls="using:Telerik.UI.Xaml.Controls"
mc:Ignorable="d"
d:DesignHeight="400"
d:DesignWidth="400">
<Grid>
<input:RadRangeSlider Minimum="0" Maximum="10"/>
</Grid>
</UserControl>
I hope the SEO for this post is good enough to go to the top of your Google/Bing search for the eror and this explanation helps someone who encounters the issue in the future. Happy coding!
Is there any way to identify which class is causing the problem?
Hi Michael, unfortunately there isn’t an easy way to see what XAML file contains the missing namespace. However, since you need to fix any instance of it, the solution is to just think about any view in your project that uses an external library for controls. Then, add the extra namespace in tat view.
For example, let’s say you have UI controls library that is referenced by the project named “MyControls” (via NuGet, assembly or project reference). If you have 10 pages that use a “MyImage” control that is in the “MyControls.ImageControls namespace, you would have the xmlns:imageControls=”using:MyControls.ImageControls” already at the top of all those views.
The solution to this error means that you also need to add the root namespace xmlns:myControls=”using:MyControls”, even though that view doesn’t explicitly use anything from there.
This is full of win.
Fantastic, really, a huge thanks for posting the info.
As the other commenter noted, it can be hard to figure out which base class contains the value, but it is no where near as difficult as it was to figure this out.
A link to this post was also buried the in the comments of stackexchange, took me hours of reading and trying stuff before I found this.
We worked with MS and found that this is, indeed, a bug with the 18362 SDK. MS provided us with replacement files for genxbf.dll (both x86 and x64). The original files had a File Version of 10.18362.1. The updated files had the following File Version: 10.0.18362.592 (WinBuild.160101.0800).
The signature for the x64 file: 52D9B5F0-1254-B8FC-17AB-EC3ACEC3BB09 | Deterministic
The signature for the x86 file: 560E2A42-35DC-ADD1-6211-3D7D790028FC | Deterministic
Because we received these due to our Support Agreement, I can’t share them. Hopefully with the above information, you can find them online.