KB5120708 still breaks WPF printing and PDF export on Windows 11 (September 7, 2026)
Chapters
TL;DR
Printing and PDF or XPS export from WPF applications has been broken on Windows 11, Windows 10 and Windows Server since the August 2026 .NET Framework cumulative update, which BleepingComputer reported Microsoft confirming on August 24, 2026. As of September 7, 2026, four weeks later, there is still no fix. The only published workaround is a per-application setting that also turns off security protections the same update added.
- The error is System.IO.FileFormatException, thrown when a WPF application prints or writes PDF or XPS output using certain fonts. Calibri is the font most often named.
- KB5120708 is the August 2026 .NET Framework cumulative update named as the cause.
- Microsoft said on August 24, 2026 that it was still investigating, and as of September 7, 2026 no fix has shipped.
- The workaround is the AppContext switch Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection, which also disables the protections the August update introduced.
- Windows 11 25H2 and 24H2, Windows 10, and Windows Server 2012 through Windows Server 2025 are all on the affected list.
What has changed since August 24, and what has not
Nothing has shipped. On August 24, 2026, BleepingComputer published Microsoft's confirmation that the August 2026 .NET Framework cumulative update breaks printing and PDF or XPS export in WPF applications, and that Microsoft was "still investigating the issue". That is still Microsoft's stated position as of September 7, 2026. The original report is in the August 24 post.
I have no new, dated Windows bug report for September 7, 2026, so the story of the day is the one that has not moved. Four weeks after the August updates, the only published remedy is still an application setting that switches off part of the hardening those updates delivered.
What breaks, and where the failure sits
A WPF application throws System.IO.FileFormatException the moment it prints, or generates PDF or XPS content, using certain fonts. Microsoft's wording, quoted by BleepingComputer, is that "some WPF applications may fail with a System.IO.FileFormatException when printing or generating PDF/XPS content that uses certain fonts". Calibri is named among the affected fonts.
The failure sits in the TrueType font subsetting path that WPF uses during printing and document export, which is why the symptom is so abrupt. An application that produced invoices, statements or reports before the update produces nothing after it, and it fails on the font rather than on the printer. The Register traced the regression to the August 11, 2026 .NET Framework cumulative update in its report on August 25, 2026.
Who is affected
PCWorld named KB5120708 as the .NET Framework cumulative update at fault in its report on August 25, 2026. The platform list is wide. On the client side it covers Windows 11 25H2 and 24H2 and Windows 10, and on the server side Windows Server 2012 through Windows Server 2025, according to both BleepingComputer and The Register.
That server range is the part people underestimate. Bulk document output often runs on Windows Server, so a fault that reads like a desktop printing problem can stop a nightly invoice run just as easily as it stops one accountant.
| Item | Detail |
|---|---|
| Update named | August 2026 .NET Framework cumulative update, KB5120708 |
| Error | System.IO.FileFormatException on printing or PDF and XPS export |
| Font most often named | Calibri |
| Clients affected | Windows 11 25H2 and 24H2, Windows 10 |
| Servers affected | Windows Server 2012 through Windows Server 2025 |
| Microsoft status | Still investigating, no fix as of September 7, 2026 |
| Workaround | AppContext switch Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection |
The workaround, and what it costs
The remedy Microsoft published is an AppContext switch, Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection, set in the configuration file of each affected application. BleepingComputer quotes Microsoft saying the switch "will also disable protections introduced with the August 2026 .NET Framework update".
The Register wrote that Microsoft recommends the workaround "only as a temporary measure", and noted the exposure to the vulnerabilities the August update addressed while it is in place. The price is therefore explicit. Printing comes back, and the font parsing protection from August goes away for that application. It is set per application rather than per machine, so a site with six line-of-business applications edits six configuration files, and has to unwind all six when a real fix lands.
What you can do today
1. Confirm the pattern before you change anything. The signature is System.IO.FileFormatException from a WPF application at the moment it prints or exports, on a machine that took the August 2026 .NET Framework update. A printer that fails from every application is a different fault.
2. Work out which applications actually matter. If one internal application prints the invoices and nothing else is affected, you have one configuration file to edit, not a fleet.
3. If you set the switch, set it in that one application's configuration file, write down the date, and put a reminder in place to take it out. Microsoft's own guidance is that it is temporary.
4. Do not set it on a machine that parses documents arriving from outside your organization. Move that work to a machine that has not taken the August 2026 .NET Framework update, or hold the work until a fix ships.
5. Try a different font on one document template as a test. The fault is in font subsetting and Calibri is the font most often named, but Microsoft has not published the full list of affected fonts, so treat a font change as a test rather than a remedy.
Frequently asked questions
Has Microsoft fixed the WPF printing failure?
No. As of September 7, 2026 the only published remedy is the AppContext switch, and on August 24, 2026 Microsoft said it was still investigating.
Should I remove the August .NET Framework update instead?
None of the three reports behind this post put that forward as guidance, so I will not present it as one. The documented remedy is the per-application switch, and it carries the security cost Microsoft describes.