WPF/XPS font handling error that still worked a few week ago

[jbe2277]

Description

I have an automated UI test executed on GitHub's Windows Server 2022 runner.

• It was working until Jul 27, 2026: https://github.com/jbe2277/waf/actions/runs/30286284736
  • OS: Microsoft Windows NT 10.0.20348.0; .NET: 10.0.10
• Now Aug 12, 2026 it started failing with always the same error: https://github.com/jbe2277/waf/actions/runs/31636504949
  • OS: Microsoft Windows NT 10.0.20348.0; .NET: 10.0.11

Context:

• .NET 10 / WPF 10 application
• Open source: Writer sample application - https://github.com/jbe2277/waf
• Error comes when it creates a FixedDocument for print preview

Reproduction Steps

• Run the UI test action (GitHub) on GitHub's Windows Server 2022 runner.
• The error occurs on my Windows 11 PC as well - but only after I updated .NET 10.0.10 to 10.0.11.

Steps:

• Open System.Waf.slnx solution file (https://github.com/jbe2277/waf/tree/master/src/System.Waf)
• Writer.Presentation > Set as Startup Project
• Start application
• Press New
• Enter Hello
• Menu > Print preview
• Exception: System.Windows.Markup.XamlParseException

Expected behavior

UI test should work

Actual behavior

Application shows the error:

2026-08-12 20:17:18.47 [I] 7948 App Waf Writer 8.0.0.0 is starting; OS: Microsoft Windows NT 10.0.20348.0; .NET: 10.0.11 
2026-08-12 20:17:24.45 [E] 7948 Writer.P UnhandledException; IsTerminating=True System.Windows.Markup.XamlParseException: 'Initialization of 'System.Windows.Documents.FixedDocument' threw an exception.' Line number '1' and line position '105'.
 ---> System.FormatException: One of the identified items was in an invalid format.
   at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode, IntPtr errorInfo)
   at MS.Internal.Text.TextInterface.Factory.CreateFontFace(Uri filePathUri, UInt32 faceIndex, FontSimulations fontSimulationFlags)
   at System.Windows.Media.GlyphTypeface.Initialize(Uri typefaceSource, StyleSimulations styleSimulations)
   at System.Windows.Documents.Glyphs.ParseGlyphRunProperties()
   at System.Windows.Documents.Glyphs.ComputeMeasurementGlyphRunAndOrigin()
   at System.Windows.Documents.Glyphs.MeasureOverride(Size constraint)
   at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   at System.Windows.UIElement.Measure(Size availableSize)
   at System.Windows.Controls.Canvas.MeasureOverride(Size constraint)
   at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   at System.Windows.UIElement.Measure(Size availableSize)
   at System.Windows.Documents.FixedPage.MeasureOverride(Size constraint)
   at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   at System.Windows.UIElement.Measure(Size availableSize)
   at System.Windows.Documents.FixedDocument.GetPage(Int32 pageNumber)
   at System.Windows.Documents.FixedDocument.OnInitialized(Object sender, EventArgs e)
   at MS.Internal.Xaml.Runtime.ClrObjectRuntime.InitializationGuard(XamlType xamlType, Object obj, Boolean begin)
   --- End of inner exception stack trace ---
   at System.Windows.Markup.XamlReader.RewrapException(Exception e, IXamlLineInfo lineInfo, Uri baseUri)
   at System.Windows.Markup.WpfXamlLoader.Load(XamlReader xamlReader, IXamlObjectWriterFactory writerFactory, Boolean skipJournaledProperties, Object rootObject, XamlObjectWriterSettings settings, Uri baseUri)
   at System.Windows.Markup.WpfXamlLoader.Load(XamlReader xamlReader, Boolean skipJournaledProperties, Uri baseUri)
   at System.Windows.Markup.XamlReader.Load(XamlReader xamlReader, ParserContext parserContext)
   at System.Windows.Markup.XamlReader.Load(XmlReader reader, ParserContext parserContext, XamlParseMode parseMode, Boolean useRestrictiveXamlReader, List`1 safeTypes)
   at System.Windows.Markup.XamlReader.Load(Stream stream, ParserContext parserContext, Boolean useRestrictiveXamlReader)
   at System.Windows.Xps.Packaging.XpsDocument.GetFixedDocumentSequence()
   at Waf.Writer.Presentation.Views.PrintPreviewView.LoadedHandler(Object sender, RoutedEventArgs e) in D:\a\waf\waf\src\System.Waf\Samples\Writer\Writer.Presentation\Views\PrintPreviewView.xaml.cs:line 49
   at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
   at System.Windows.BroadcastEventHelper.BroadcastEvent(DependencyObject root, RoutedEvent routedEvent)
   at System.Windows.BroadcastEventHelper.BroadcastLoadedEvent(Object root)
   at System.Windows.Media.MediaContext.FireLoadedPendingCallbacks()
   at System.Windows.Media.MediaContext.FireInvokeOnRenderCallbacks()
   at System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object resizedCompositionTarget)
   at System.Windows.Media.MediaContext.RenderMessageHandler(Object resizedCompositionTarget)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
   at System.Windows.Threading.DispatcherOperation.InvokeImpl()
   at MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(Object obj)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   at MS.Internal.CulturePreservingExecutionContext.Run(CulturePreservingExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Windows.Threading.DispatcherOperation.Invoke()
   at System.Windows.Threading.Dispatcher.ProcessQueue()
   at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
   at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
   at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
   at System.Windows.Application.RunDispatcher(Object ignore)
   at System.Windows.Application.RunInternal(Window window)
   at Waf.Writer.Presentation.App.Main() System.Object: 

Regression?

Yes, looks like a regression issue

• worked with 10.0.10
• started failing with 10.0.11

Known Workarounds

No response

Impact

No response

Configuration

No response

Other information

No response

[seancullinan31]

This is a major problem that has affected our WPF .NET Framework 4.8.1 application that serves tens of thousands of users around the world. Working with Claude we found the following which should be helpful to anyone experiencing or working on this issue:

Independent reproduction, plus three things that may help: .NET Framework is affected identically,
there is an undocumented AppContext switch that works around it, and a control case that narrows
where the change actually is.

Standalone repro (single C# file, builds with the in-box compiler, no dependencies):
https://github.com/seancullinan31/wpf-xps-regression-aug2026

.NET Framework is affected too

Same stack trace, same line 1 position 105, on .NET Framework 4.8.1 rather than .NET 10:

PresentationCore.dll	Origin	Result
4.8.9340.0	July servicing	OK
4.8.9344.0	KB5120708, installed 2026-08-11	FAIL

Since dotnet/wpf does not service .NET Framework, a fix shipped only in
Microsoft.WindowsDesktop.App will not reach it — both forks will need the change.

It is not the fonts, and not the pack URI

The repro includes a file-backed control: identical document, identical serializer settings,
written to a file instead of a MemoryStream registered in PackageStore.

                                        switch OFF     switch ON
  1. in-memory (PackageStore)              FAIL           PASS
  2. file-backed (control)                 PASS           PASS

Serialization and Commit() succeed in every case — only the read-back fails. Also ruled out:

• The embedded .ODTTF part is valid. Extracting it and loading it directly with GlyphTypeface
  succeeds.
• The pack URI form is not the trigger. Canonical URIs from PackUriHelper.Create() fail identically.
• Flushing the package, or backing it with a FileStream instead of a MemoryStream, makes no
  difference.

What matters is only whether WPF opened the package itself.

Undocumented workaround

4.8.9344 adds an AppContext switch that restores the previous behaviour. I could not find it
documented anywhere:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Windows.DisableXpsPackageBoundaryRestriction=true" />
  </runtime>
</configuration>

The name is present in 4.8.9344 and absent in 4.8.9340. Both builds are still in the component store
on a patched machine, so it can be checked directly:

$old = 'C:\Windows\WinSxS\amd64_presentationcore_31bf3856ad364e35_4.0.15920.119_none_a684281745790d81\PresentationCore.dll'
$new = 'C:\Windows\WinSxS\amd64_presentationcore_31bf3856ad364e35_4.0.15920.120_none_a67b2559458129c3\PresentationCore.dll'
foreach ($f in @($old, $new)) {
    $s = [Text.Encoding]::Unicode.GetString([IO.File]::ReadAllBytes($f))
    '{0}: {1}' -f (Get-Item $f).VersionInfo.FileVersion, ($s -match 'DisableXpsPackageBoundaryRestriction')
}

4.8.9340.0: False
4.8.9344.0: True

Verified working on .NET Framework via AppContextSwitchOverrides and via AppContext.SetSwitch
set before WPF first touches the XPS stack. Worth confirming whether the same switch is honoured on
.NET 10.

Two requests

1. Please document the change and the switch. The KB states "Microsoft is not currently aware of
   any issues in this update" and lists no WPF, XPS or font changes. A compatibility switch shipping
   alongside suggests the impact was anticipated; a single line in the KB would have saved a lot of
   people a lot of time.
2. Please state whether the switch is supported long-term or is a temporary shim. Remediation
   plans depend on the answer — engineering around this means restructuring how documents are built,
   which is not something to undertake speculatively.

Separately, surfacing this as a bare System.FormatException with the default message and no URI
makes it near-undiagnosable in the field. The underlying failure crosses the DirectWrite COM boundary
as HRESULT COR_E_FORMAT (0x80131537), so the original type and message are discarded. A distinct
exception naming the blocked resource would help every affected application.

[ToreDemant]

This could be related to #11834

[ToreDemant]

Could this have been introduced with #11835

[himgoyalmicro]

We are investigating the issue and working on a fix.

[jbe2277]

I tried the workaround described in KB5120708:

• https://support.microsoft.com/en-us/servicing/dotnetframework/windows-11/25h2/august-11-2026-kb5120708-cumulative-update-for-net-framework-3-5-and-4-8-1-for-windows-11-version-25

<configuration>
  <runtime>
    <AppContextSwitchOverrides
      value="Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection=true"/>
  </runtime>
</configuration>

The article and workaround are intended for .NET Framework 4.8.1. Since I'm using .NET 10, I configured the equivalent AppContext switch for .NET 10 instead. Unfortunately, it did not resolve the issue.

[ToreDemant]

I tried the workaround described in KB5120708:

• https://support.microsoft.com/en-us/servicing/dotnetframework/windows-11/25h2/august-11-2026-kb5120708-cumulative-update-for-net-framework-3-5-and-4-8-1-for-windows-11-version-25

The article and workaround are intended for **.NET Framework 4.8.1**. Since I'm using **.NET 10**, I configured the equivalent AppContext switch for .NET 10 instead. Unfortunately, it did not resolve the issue.

Hi @jbe2277

You can find a workaround for ,Net in the following PR that has not been completed yet:
dotnet/core#10535