Rendering WPF controls to XPS fails on ARM64

[SFREPTyler]

.NET Version: 6.0.13
Windows version: Windows 11 22H2 (OS Build 22621.1194)
Does the bug reproduce also in WPF for .NET Framework 4.8?: No

In our production application we are rendering a WPF control to XPS. We've found that on ARM64 using .NET 6 (Windows Desktop) the WPF control is often rendered incorrectly with missing content. This occurs almost every time in our production application, and I've created a repro demo which also frequently shows the issue. This demo is attached below.

Actual behavior:
The repro demo renders a simple WPF control (defined in TestControl.xaml) which contains a single Rectangle control. In many cases the Rectangle is not rendered in the XPS. There is a missing Data attribute:

<FixedPage xmlns="http://schemas.microsoft.com/xps/2005/06" xmlns:x="http://schemas.microsoft.com/xps/2005/06/resourcedictionary-key" xml:lang="und" Width="816" Height="1056"> <Path Name="ColorRectangle" Fill="#FF0000FF" RenderTransform="1,0,0,1,8,303" /> </FixedPage>

Expected behavior:

When the test application renders successfully, the Rectangle is present:
<FixedPage xmlns="http://schemas.microsoft.com/xps/2005/06" xmlns:x="http://schemas.microsoft.com/xps/2005/06/resourcedictionary-key" xml:lang="und" Width="816" Height="1056"> <Path Name="ColorRectangle" Fill="#FF0000FF" RenderTransform="1,0,0,1,8,303" Data="M0,0L800,0 800,450 0,450Z" /> </FixedPage>

Minimal repro:

Using the solution attached, the issue can be replicated with the following steps.

1. Unzip the solution folder.
2. Build and launch the application using the built exe or Visual Studio's Start Without Debugging. This does not occur when the debugger is attached. The issue will occur regardless of whether a Debug or Release build is used.
3. Click the Save XPSs button.
4. 18 XPS files will be generated using a loop. We've found that the issue almost always occurs with the 16th, 17th, or 18th attempt, pointing towards a resource issue. However, it will often occur in the first XPS file generated, or any attempt in between.
5. If XPS files are associated with an appropriate viewer, the first and last (18th) file should be opened automatically to show the issue. If files association is not set, a crash may occur. Associate the file type using "Apps > Default Apps" in Windows or disable the code in MainWindow.ShowXps().

• The issue is very unpredictable and may or may not occur on the 1st or 18th attempt, but in our testing with this demo the 18th attempt almost always reproduces the issue. Again, this affects our production application in almost every instance.
• In the test application, an artificial delay is added, using Thread.Sleep, which causes the issue to occur more frequently. This is not necessary if the loop is not used and SaveXps is clicked repeatedly. This is documented in the code.
• To reiterate, this only occurs on ARM64. We're testing using multiple Surface Pro X tablets. This does not occur on x64 or x86 natively or when running under emulation on Windows 10/11 for ARM64.
• Again, this does not occur when using the debugger.

WPF - XPS Rendering Issue Demo.zip