A document that printed without complaint in July stops printing in late August. Depending on the application, the print dialog closes and nothing reaches the queue, the export writes a file that will not open, or an error surfaces carrying the text System.IO.FileFormatException. The printer is not the thing that broke: the same printer, on the same machine, answers immediately from a different program.
Microsoft has published this as a known issue against the .NET Framework cumulative updates released on August 11, 2026. The published wording is narrow, and the narrowness is the part worth reading closely: "After installing the August 2026 .NET Framework cumulative update, some WPF applications may fail with a System.IO.FileFormatException when printing or generating PDF/XPS content that uses certain fonts, including Calibri." Some applications, not every application. Certain fonts, of which Calibri is the only one named; the rest of that set has not been published. The status line under that paragraph still reads "Investigating." What follows begins with the changes that cost nothing, then covers the two that cost something specific, and names the cost in each case.
Two Minutes, and Nothing Given Up
Three moves clear the immediate job without altering the security state of the machine. Try them in this order.
- Change the font in the document and send the job again. Calibri is the one typeface Microsoft names. If the same content prints once it is set in something else, the job is out and nothing on the machine has changed. This doubles as the cleanest confirmation available, because a document that fails in one font and succeeds in another matches the published symptom more precisely than any other check.
- Print the same file from a different application. The known issue is scoped to WPF applications. Opening the same document or PDF in a program built on something other than WPF routes the job through a different rendering path, which is why a printer that looks dead in one window responds instantly in the next.
- Separate the export from the printing. Where an application can still write a file even though its own print path fails, moving that file to a viewer that prints normally sidesteps the failing step rather than repairing it.
If any one of the three clears the job, stop there. The two options after this point each trade something away, and neither is worth spending when a font change would have done it.
Ruling Out the Printer Before Ruling In the Update
The diagram above lays out the sequence, and the order is deliberate. The printer, the driver and the print queue are the cheapest things to eliminate, and eliminating them costs one test job from an unrelated program. Only after that does the update history become worth opening.
Installed updates are listed by KB number and date under Settings, then Windows Update, then Update history. The relevant entry carries the date August 11, 2026, and a number beginning KB512. If nothing from that date appears in the list, the machine has not received the update that carries this defect and the symptom has some other origin.
One limit is worth stating plainly rather than papering over. Microsoft's published text scopes the issue to WPF applications but gives no way to tell whether a given program is one, and no such identifier appears anywhere in the four update pages. The three checks in the diagram exist because that direct answer is not available to a person sitting at the machine, and a font-dependent failure that survives a change of program is the closest practical substitute.
Four Packages Went Out That Day, and Only One Is on the Machine
The same defect appears under four different KB numbers, because Microsoft ships the .NET Framework cumulative update separately for each supported Windows version. Windows 11 version 24H2 receives KB5120710. Windows 11 version 25H2, together with the server operating system version 24H2, receives KB5120708. Windows 11 version 26H1 receives KB5120711. Windows Server 2022 receives KB5120705. Other Microsoft products received their own packages on the same date.
Reading those four pages side by side produces two observations Microsoft does not state directly. The first is that the known-issue paragraph is word-for-word identical on each of them, as are the six CVE identifiers listed above it, so the defect is not version-specific even though the package number is. The second is a difference in coverage: the 24H2, 25H2 and Server 2022 packages each cover two .NET Framework versions, while the 26H1 package covers .NET Framework 4.8.1 alone. A machine on 26H1 has one leg where the others have two.
The practical consequence is a search problem. A KB number picked up from a news headline is only correct for the version that headline happened to be written about. Searching KB5120708 from a 24H2 machine returns a support page whose title names a version the machine is not running, which reads like a dead end when it is simply the wrong page. The version itself is under Settings, then System, then About, where it appears under Windows specifications.
The Switch Microsoft Publishes, and the Sentence Attached to It
The published workaround is an AppContext switch named Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection, set to true in an application configuration file. Microsoft Learn documents the element that carries it: the switch lives in an AppContextSwitchOverrides element, nested inside a runtime element, nested inside the file's configuration element. The attribute takes the form value="name=value", and where more than one switch is set, the pairs are separated by semicolons.
The sentence Microsoft prints immediately after the snippet is the reason this option ranks below a font change: "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."
Two words in that sentence are load-bearing. The first is may: Microsoft writes that exposure may increase, not that it will, and repeating it as a certainty overstates what has been published. The second is temporary, which is Microsoft's own characterisation and not an editorial softening. A switch set once and forgotten stops being the documented workaround and becomes a standing configuration change that no decision produced.
The placement also fixes the blast radius. The switch sits in an application's own configuration file, so it affects that application. That is a meaningfully smaller footprint than the alternative below, and the difference is the strongest argument for preferring it when a single program is the one that fails.
Six Fixes, and What the Switch Name Says About Them
The August 11, 2026 packages each close six vulnerabilities: CVE-2026-65810 and CVE-2026-62872, both elevation of privilege; CVE-2026-62886, CVE-2026-62897 and CVE-2026-70354, each of them remote code execution; and CVE-2026-62902, information disclosure. Grouping them gives the shape in the chart above, three remote code execution against two elevation of privilege against one information disclosure. The quality section on those same pages reads "There are no new Quality and Reliability Improvements in this update," which means the package is security content and nothing else.
The switch name identifies the protection being handed back rather more precisely than the prose does. It names overflow protection over cmap and sbit data inside TrueType handling. Both are standard font table terms in Microsoft's own OpenType specification: the cmap table is the Character to Glyph Index Mapping Table, which "defines the mapping of character codes to a default glyph index," and embedded bitmaps in OpenType "are called 'sbits' (for 'scaler bitmaps')." So the protection sits over two specific structures inside a font file.
What has not been published is which of the six vulnerabilities that protection belongs to, or why a font as ordinary as Calibri trips it. All four pages say only "Investigating." Any account of the mechanism beyond the name of the switch is inference at this point, and treating inference as documentation is how the wrong fix gets applied confidently.
Removing the Update Instead, and What That Widens
The other paid option is removing the update. Microsoft's documented path runs Start, then Settings, then Windows Update; under More options, Update history; under Related settings, Uninstall updates; then select the update and choose Uninstall. Microsoft attaches a caution to that page worth carrying forward: "Some updates cannot be uninstalled."
Compared with the switch, this widens rather than narrows. The switch is set in one application's configuration file and affects that application. Removing the package removes the six fixes for every .NET Framework application on the machine, including the ones that were printing perfectly. Where a single program is failing, that is a larger surface for the same result.
Removal also has a shelf life, because Windows Update offers the package again. Pausing is the documented way to hold that off: Settings, then Windows Update, then "Pick a date" on the "Pause updates" control. Microsoft states the ceiling as "You can pause updates for up to 35 days from the current date," and that "If you do nothing, updates resume automatically when the pause expires to help keep your device secure and reliable." The pause is a delay with a published end, not a decision.
The Calendar This Is Sitting On
Microsoft Learn states the release rhythm directly: "The monthly security update release is published on the second Tuesday of each month, typically at 10:00 AM Pacific Time (PST/PDT)," while "Optional nonsecurity preview releases are typically released on the fourth Tuesday of the month." Applying that rule to the calendar produces the dates in the timeline above, and the arithmetic is worth doing rather than guessing at.
The update shipped August 11, 2026, the second Tuesday of that month. The fourth-Tuesday preview slot for August fell on August 25 and has passed. The next monthly security release falls on September 8, which is 28 days after August 11. The one after that falls on October 13, which is 63 days out. A 35-day pause started on August 29 expires on October 3, which lands after the September release but ahead of the October one.
Two things follow. First, a workaround described by its own publisher as temporary is being held for at least the interval to the next release, and as of August 29, 18 days after the update shipped, the status line has not moved off "Investigating." Second, whoever sets the switch or removes the package needs a date in the calendar to revisit it, because neither change announces itself later. September 8 is the first defensible date to check.
What Not to Change
Some repairs cost time without touching this defect, and a few make the situation harder to read.
- Reinstalling the printer driver. If the printer answers from another program, the driver is already exonerated. Reinstalling it replaces a working component and adds a variable.
- Deleting or re-registering the font. Calibri is named as a font that triggers the failure, not as a font that is damaged. Removing it changes what documents look like and leaves the parsing path untouched.
- Applying the switch machine-wide when one application fails. The documented placement is an application's configuration file. Widening it past that gives up the protection for programs that were printing without trouble.
- Setting the switch with no date to remove it. Microsoft's wording is "only as a temporary measure and only when required." A switch with no review date fails both halves of that.
- Turning off Windows Update entirely. The documented pause is bounded at 35 days, and updates resume on their own when it expires. Anything built to outlast that is a standing configuration change made to route around one print job.
When This Doesn't Apply
The frame above holds only under fairly specific conditions, and several near neighbours look identical from the outside.
- The failure predates August 11, 2026. Everything here starts at that install. A print path that was already failing in July has a different origin, whatever the error text says.
- No August .NET Framework package appears in Update history. Without KB5120710, KB5120708, KB5120711 or KB5120705 on the machine, the published known issue is not what is being observed.
- The failing program is not a WPF application. Browsers, and applications built on other frameworks, sit outside the scope of the published text. The symptom may resemble this one and still be unrelated.
- The error is a spooler or connectivity error. A queue that stalls, a device that drops off the network, or an offline printer produces a different failure with a different remedy.
- The font in use is not implicated. Calibri is the only font named. A document that fails identically in several unrelated typefaces is weaker evidence for this issue than one that recovers as soon as the typeface changes.
- The application ships without an editable configuration file. Packaged and managed applications may not expose one, in which case the switch is not available and the choice narrows to the no-cost moves or removing the package.
- Microsoft revises the guidance. The status is "Investigating," which means the published workaround is provisional. Once a fixed package ships, applying a switch that reverses part of it stops being a workaround and becomes a regression.
Where the three no-cost moves clear the job, none of the rest of this needs deciding. That is the whole argument for trying them first.
Comments
Post a Comment