Patch Tuesday Strikes Again: Microsoft’s August Updates Break Printing and PDF Export in WPF Apps

Ah, Patch Tuesday.

That wonderful time of the month when administrators apply security updates, sip their coffee, watch dashboards turn green… and quietly wonder what Microsoft accidentally broke this time.

For August 2026, one of the answers appears to be:

Printing.

More specifically, Microsoft has confirmed that the August 2026 .NET Framework cumulative updates can break printing, PDF generation, and XPS output in certain applications built using Windows Presentation Foundation (WPF).

So if one of your perfectly functional business applications suddenly decided that printing is an optional feature after Patch Tuesday, your printer may not be the problem.

Your update might be.

What Actually Broke?

The issue affects Windows applications that use WPF, Microsoft's desktop UI framework used by plenty of enterprise and line-of-business applications.

After installing the August 2026 .NET Framework cumulative update, affected applications can throw a:

System.IO.FileFormatException

when attempting to print or generate PDF/XPS documents.

The problem appears to involve the way WPF processes and subsets certain TrueType fonts.

And because Windows wouldn't be Windows without dragging an innocent font into the situation, Calibri is one of the fonts known to trigger the problem.

Users have reported errors similar to:

CALIBRI.TTF does not conform to the expected file format specification.

Another report showed the same behaviour with CALIBRIB.TTF, the bold version of Calibri. Microsoft community reports have reproduced the failure in .NET Framework 4.8 applications and confirmed that removing the affected update restored printing functionality.

Because obviously the font that has spent years silently creating spreadsheets and corporate reports finally chose violence.

This Isn't Just "Microsoft Print to PDF"

One important distinction is that this isn't necessarily a problem with the Microsoft Print to PDF printer itself.

The failure is happening farther up the stack.

WPF applications can use the Windows XPS printing architecture when generating documents. During that process, WPF may create subsets of fonts containing only the characters required for the document.

After the August update, that font-subsetting process can fail.

One Microsoft Q&A discussion narrowed the problem down to the GlyphTypeface.ComputeSubset() functionality, meaning developers can reproduce the error without even invoking the entire printing pipeline.

That explains why the problem can appear in several different ways:

• Printing from a WPF application fails.
• Exporting a report to PDF fails.
• XPS generation fails.
• Reporting software suddenly stops printing.
• Applications throw FileFormatException errors referencing Windows fonts.

So replacing the printer driver, restarting the print spooler twelve times, sacrificing a USB printer to the IT gods, and blaming Bob from Accounting probably aren't going to fix this one.

What Systems Are Affected?

This isn't limited to one version of Windows.

Microsoft says the known issue impacts supported Windows client and server platforms, including Windows 10, Windows 11, and Windows Server releases ranging from Windows Server 2012 through Windows Server 2025.

Reports have also surfaced against different update packages.

For example, users have associated the issue with KB5120708, while another administrator reported the same behaviour with KB5120705 on Windows Server 2022.

That makes this particularly important for enterprise environments where an older internal application may quietly depend on WPF for reporting.

The application might have worked perfectly for ten years.

Then Patch Tuesday arrives.

And suddenly:

"The reports won't print."

The five words every infrastructure administrator loves hearing at 8:03 Monday morning.

Microsoft Has a Workaround — With a Catch

Microsoft has provided a temporary workaround while it investigates a permanent fix.

The workaround involves enabling an AppContext switch in the affected application's configuration:

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

That can restore the affected font-processing behaviour and allow WPF applications to print or generate PDF/XPS documents again.

Problem solved?

Not exactly.

There's a rather important sentence attached to Microsoft's workaround:

It disables protections introduced by the August security updates.

Those protections were added to address security vulnerabilities. Enabling the compatibility switch therefore reduces some of the protection provided by the update. Microsoft recommends using the workaround only temporarily and only where it is actually required.

And that's where this becomes more interesting from a security perspective.

Don't Immediately Uninstall the Security Update

The natural reaction when an update breaks a production application is:

REMOVE THE UPDATE.

And yes, administrators have reported that uninstalling the affected update restores functionality.

But removing a security update across an entire organization because one application can't print isn't necessarily the best trade-off.

Security patches exist for a reason.

Instead, I'd approach the problem like any other security-versus-availability decision.

First, determine whether you're actually affected.

Identify which systems run WPF applications that depend on printing, XPS generation, or PDF export.

Then test the application on an updated machine.

If it works, leave it alone.

If it breaks, determine whether Microsoft's application-level workaround can be applied specifically to that application rather than rolling back security patches across the entire operating system.

Most importantly, document the exception.

If you're temporarily disabling a security protection to maintain business functionality, that should be treated as exactly that:

A temporary security exception.

Not a configuration setting that someone discovers six years from now and wonders:

"Why on earth is this enabled?"

What I Would Do in an Enterprise Environment

If this landed in an environment I was responsible for, my approach would look something like this.

1. Identify impacted applications

Look specifically for WPF-based applications responsible for:

• Reporting
• Invoice generation
• Shipping documents
• Labels
• PDF export
• XPS generation
• Specialized internal printing

2. Reproduce the problem

Confirm that the August update is actually causing the failure.

Look for System.IO.FileFormatException errors and references to fonts such as Calibri.

Don't assume every printing issue after Patch Tuesday is this bug.

Printers are still printers.

They are perfectly capable of breaking themselves.

3. Avoid broad update removal

If twenty thousand endpoints received the update and twelve machines running a legacy reporting application have problems, don't necessarily remove the security update from twenty thousand machines.

Scope the remediation.

4. Apply the workaround only where required

Microsoft's AppContext workaround can potentially keep the application running without removing the entire cumulative security update.

But because it disables newly introduced protections, use it only on systems where it's needed.

5. Track the exception

If you're using vulnerability management or change management, record:

• The affected systems
• The affected application
• The workaround applied
• Why it was required
• The associated Microsoft known issue
• Who approved the exception

And most importantly:

Create a reminder to remove the workaround once Microsoft releases a permanent fix.

Temporary workarounds have an amazing ability to become permanent infrastructure.

Patch Management Is About More Than Installing Patches

This issue is another good example of why patch management isn't simply:

Update available → Install update → Done

Security updates can affect applications, drivers, libraries, authentication systems, networking components, and apparently the ability for Calibri to peacefully exist inside a PDF.

Organizations need some level of staged deployment.

Even a simple model helps:

Test Group → Small Production Group → General Deployment

For servers and critical workstations, application validation is just as important as checking whether Windows successfully rebooted.

A server showing "fully patched" isn't particularly comforting when the accounting department can no longer generate invoices.

Security is ultimately risk management.

You want the vulnerabilities patched.

You also want the business to function.

Sometimes those two goals briefly attempt to fight each other.

The Bottom Line

Microsoft's August 2026 .NET Framework security updates have introduced a confirmed issue affecting certain WPF applications when printing or generating PDF/XPS documents.

The problem appears to involve TrueType font subsetting and can generate System.IO.FileFormatException errors with fonts including Calibri.

Microsoft is investigating and has provided a temporary AppContext workaround.

But because that workaround disables security protections added by the August update, administrators should use it cautiously and only where necessary.

So if your help desk suddenly starts receiving tickets saying:

"Printing worked yesterday."

Before spending three hours reinstalling printer drivers…

Check Windows Update.

Then refill your coffee.

You're probably going to need it.

Source: BleepingComputer https://www.bleepingcomputer.com/news/microsoft/microsoft-august-updates-break-printing-pdf-export-in-wpf-apps/