Microsoft’s August 2026 update, specifically KB5120708, has introduced significant issues for Windows 11 users. The update, targeting the .NET Framework is causing application crashes when users attempt to print documents or save PDF and XPS files. This disruption stems from a faulty update affecting common fonts like Calibri triggering FileFormatException errors that interfere with everyday document workflows.
While Microsoft investigates the problem, a temporary workaround is available. However, the situation highlights the ongoing challenges users face with Windows updates and the importance of thorough testing before widespread deployment.
Understanding the Issue
The problematic update, KB5120708, is not directly related to Windows 11 itself but affects the .NET Framework. According to Microsoft, after installing this update, some applications may encounter errors when printing from documents containing certain common fonts or when creating PDF or XPS files. The issue is particularly prevalent in WPF (Windows Presentation Foundation) applications, which are widely used in line-of-business desktop software.
The error manifests as a .FileFormatException indicating a problem with the document’s format when using specific fonts. This issue is not limited to Windows 11 but also affects Windows 10 and recent versions of Windows Server. The error occurs during the XPS serialization process, which is used for printing and document export in WPF applications.
The Technical Explanation
A report filed in the public dotnet/wpf issue tracker provides a plausible technical explanation for the observed failure. The report suggests that WPF’s font-subsetting code now rejects several stock Windows fonts during XPS serialization, including CalibriCambriaConstantia and Corbel variants. The fonts render on screen without trouble, but the exception occurs when WPF tries to subset and embed glyphs for printing or document export.
This distinction explains why help desks may initially receive vague reports such as “PDF printing stopped” while users can still view the same document normally. Screen rendering and the export/print path do not exercise the same code, leading to this discrepancy. It also means the exception’s reference to a font file should not prompt administrators to delete, replace, or “repair” fonts in C:\Windows\Fonts as a first response.
Temporary Workaround
Microsoft has provided a temporary workaround for the issue. Applications can mitigate the problem by enabling the Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection AppContext switch in the app config file. This switch disables security protections introduced in the August 2026 update and may increase exposure to the vulnerabilities addressed by that update.
Microsoft recommends using this workaround only as a temporary measure and only when required to address this issue. The workaround involves adding the following code to the application configuration file:
This setting is not a Windows-wide registry repair but must be applied to each affected application individually. For in-house WPF software, developers should add the switch only after reproducing the failure with the application’s real document templates and fonts. For third-party products, the more defensible path is to open a vendor support case with the full exception, the installed August.NET Framework KB, Windows version, and a minimal document that triggers the failure.
The Security Tradeoff
Microsoft states directly that the switch disables protections introduced in the August 2026 update and may increase exposure to vulnerabilities that update addresses. KB5120708 lists six.NET Framework security fixes, including vulnerabilities for elevation of privilege, remote code execution, and information disclosure.
Rolling back the.NET update should not be treated as a routine printing fix, as it removes a broader set of security corrections. The documented AppContext setting scopes the compatibility concession to an individual application, providing a more targeted solution. Administrators should base their decision on the application’s exposure and risk profile.
Microsoft’s Response and Documentation
Microsoft has acknowledged the issue and is actively investigating it. However, the documentation for the update is not yet consistent. KB5120708 clearly lists the WPF printing/PDF problem as a known issue, but the August 2026.NET Framework cumulative-update overview still says the release contains no known issues.
Windows 10 documentation is also out of step with the broader affected-platform description reported by BleepingComputer. Microsoft’s pages for KB5120701 and KB5120709—the August.NET Framework updates for Windows 10 versions 21H2 and 22H2—state that Microsoft is “not currently aware of any issues” in those updates. This discrepancy highlights the importance of consulting multiple sources and staying informed about ongoing issues.
Organizations that use automated patch dashboards, knowledge-base scraping, or update notes to decide whether to test and mitigate regressions may miss the issue if they consult only the generic.NET release page or the relevant Windows 10 KB article. As of August 24, Microsoft has explicitly documented the problem for Windows 11 version 25H2/server 24H2 and Windows Server 2026. Its public Windows 10 KB entries have not caught up, if the issue applies there as reported.
What IT Teams Should Do Now
The first task is to identify whether the failing program is actually a WPF application and whether its print or export workflow passes through XPS serialization. The.FileFormatException, the document font family, and the application’s.config file are more useful starting points than reinstalling printer drivers.
Administrators should then inventory the August.NET Framework update applicable to each affected device. KB5120708 is associated with Windows 11 version 25H2 and server operating system 24H2; KB5120705 covers Windows Server 2026; Windows 10 has separate.NET Framework packages, including KB5120701 for.NET Framework 3.5 and 4.8 and KB5120709 for 3.5 and 4.8.1.
For applications where changing the configuration file is not feasible, a temporary document-level alternative may be possible: use a font that does not trigger the failure, or generate PDFs through a non-WPF path if the product supports one. Those are application-specific workarounds, not vendor-approved universal fixes, and they can alter document layout, branding, accessibility, or archival behavior. They deserve the same regression testing as the AppContext switch.
Microsoft has not announced a corrected build or a target date for a permanent fix. Until it does, the safest operational posture is to treat this as a targeted WPF compatibility regression, preserve the August security update, and limit the protection-disabling switch to confirmed business-critical failures rather than deploying it across the estate.
