Microsoft's .NET Update Broke Printing. Here's the Real Lesson

WPF (Windows Presentation Foundation) is a framework developed by Microsoft for building Windows desktop applications, built on top of .NET Framework. Typical WPF applications include Windows-based ERP, accounting, logistics, engineering, administration and other line-of-business applications. WPF is particularly common in enterprise software that has been developed on Microsoft .NET Framework over many years.

Applications that generate reports, labels, invoices or other printable documents, especially ERP, POS, and warehouse systems that print through Windows, are worth checking first. Microsoft's August 2026 cumulative update for .NET Framework is causing some WPF applications to fail when printing or generating PDF/XPS output with certain fonts, including Calibri, as The Register first reported. If your team pushed this update and printing suddenly started throwing errors, this is likely why.

What actually broke

Microsoft's August 11 .NET Framework updates cause some WPF apps to throw a System.IO.FileFormatException on print or PDF/XPS generation, tied to how certain fonts get processed including Calibri, the default font in Word since 2007. The bug hits Windows 10, Windows 11, and every supported version of Windows Server from 2012 through 2025, which is a lot of surface area for a font rendering issue.

Microsoft's own fix is a config-file switch: Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection. That protection was added in the same August update to close a security gap. Turning it off to fix printing means turning off a fix that was shipped, on purpose, days earlier. Microsoft says as much in its own guidance, framing the switch as a temporary measure and flagging that it reopens exposure to the vulnerabilities the update patched.

Microsoft says it's still investigating. No timeline for a real fix yet.

What this means if you're patching

If your users hit this, enabling Microsoft's config switch (below) will get them printing again by turning off the new font-processing protection. That's a step backward on security, by Microsoft's own description, and it's meant to be temporary. If you go this route, track which machines have it applied so it can come out the moment a real fix ships.

Quick fix. Add this to the affected application's config file, under <runtime>. It's a per-app setting, not machine-wide, so if the app already has a <runtime> section, add this line into it rather than replacing the file:

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

The longer-term point is less about this one bug and more about where print sits in your environment. Every time print depends on the full Windows stack (drivers, spooler, .NET, WPF, and whatever else a given app pulls in) it inherits every patch risk in that stack, whether the patch has anything to do with printing or not.

Build printing that doesn't depend on Windows

This bug reaches everyone downstream of the standard Windows print pipeline. The way to avoid exposure to bugs like this isn't to hope for a better Windows print system, it's to change how your app prints in the first place.

For WPF apps, that means avoiding the standard way of building documents. PrintDialog, FixedDocument, and XpsDocument all run through WPF's own font-subsetting and rendering, the exact code that broke here. Build a PDF with an independent library instead, one that never touches that pipeline, then hand it to ezeep through the API (or its MCP server, for apps built in AI-assisted dev tools) instead of the OS print path. That covers backend jobs that never touch a screen, warehouse labels from order events, invoices from accounting software, reports on a schedule, and it covers the everyday case just as well: an employee at their desk clicking print for the one page they need, no OS print dialog either way.

Ready to Simplify Your Print Stack?

See how now.

Start Free Trial