One Program Stopped Printing After a Windows Update — And Everything Else Prints Fine

It starts on a Monday, usually at the front desk. Somebody goes to print an invoice, a work order, a treatment note, a quote, a packing slip — whatever the program is that your business actually runs its day on — and instead of a printout there is an error box, or a long pause and then nothing at all. Same thing if they try the program's own Save as PDF or Email as PDF button.

So they check the printer. It is on, it has paper, its little screen says Ready, and it will print its own test page from its front panel quite happily. Then somebody prints a Word document to prove a point, and that works. The browser prints. The PDF that was already on the desktop prints. Everything on that computer prints except the one program that matters.

At this point the usual thing happens: someone starts reinstalling printer drivers. That is a wasted afternoon, because in this situation the printer is not involved at all — and there is a specific, documented, published reason this is happening to a lot of small businesses right now. It is worth ten minutes to check before anyone touches a driver.

The two-minute test that decides everything

Before any of the rest of this matters, settle one question: is this a printer problem or a program problem? There is a clean test and it takes two minutes.

Open Notepad. Type a word. Print it to the same printer, from the same computer, with the same user logged in. Then go back to the program that failed and try again.

If Notepad prints and the program does not, you have a program problem, and you can stop troubleshooting the printer entirely. Nothing you do to the driver, the queue, the spooler or the cable will change the outcome, because none of those things is failing — the print job is dying inside the application before it ever reaches them. That single observation is worth more than everything else in this article.

If Notepad also fails to print, this is not your problem and you are in the right building but the wrong room. That is an ordinary printer fault and we have written it up properly elsewhere: start with the printer that says it is connected but will not print, then the print spooler that keeps stopping, and if the error mentions the driver specifically, the driver-is-unavailable guide covers what Microsoft changed about printer drivers in 2026. Go there instead — the rest of this page will not help you.

One more separator worth drawing, because it catches people: if the program fails to print on every computer in the office but only for one specific document or template, that is also a signal, and a useful one. Hold on to it — it comes back later.

What actually broke, in plain English

On August 11, 2026, Microsoft shipped a cumulative security update for the .NET Framework — the runtime that a very large share of Windows business software is built on top of. It was not a small one. It fixed six named vulnerabilities: two elevation-of-privilege flaws, three remote code execution flaws and one information disclosure flaw. Remote code execution is the serious end of that scale, so this was an update worth installing, and installing promptly.

Part of what it tightened was the way Windows handles fonts embedded into printed and exported documents. And that tightening had a side effect that Microsoft has since acknowledged in its own release notes: after installing the August 2026 .NET Framework cumulative update, in Microsoft's words, "some Windows Presentation Foundation (WPF) applications might fail with a System.IO.FileFormatException when printing or generating PDF/XPS content that uses certain fonts, including Calibri."

Unpack that sentence, because every part of it is doing work. WPF is the Microsoft framework that a great many Windows desktop business applications are built with — the invoicing packages, estimating tools, scheduling systems, practice-management suites, and the back-office side of a lot of point-of-sale systems. "Printing or generating PDF/XPS content" is why the program's Save as PDF button broke at the same moment its Print button did: to that application they are the same operation, and both go through the code that changed. And FileFormatException is the program complaining that a file it is trying to read looks malformed — which, from its point of view, the font now does.

So the chain runs: security update tightens font handling → the application's printing engine now rejects a font it used to accept → the print or the PDF fails inside the application → the printer never hears about it. Which is exactly what you observed when Notepad printed and your program did not.

Why it looks random — the Calibri detail

The single most confusing thing about this defect is that it does not break the whole program. It breaks some documents and not others, on the same machine, in the same application, on the same afternoon. That inconsistency is what convinces people it must be a flaky printer.

It is not random. It tracks the font. Microsoft names Calibri specifically, and Calibri is not an exotic choice — it was the default font in Office for well over a decade, which means it is baked into an enormous number of business document templates that nobody has looked at since the day they were made. So your invoice template, built years ago in Calibri, fails. Your statement template, built by somebody else in Arial, prints perfectly. Same program, same printer, opposite results, and no obvious reason.

Here is the honest limit of what is known, and it matters: Microsoft says "certain fonts, including Calibri." It has not published a complete list of affected fonts. There are lists circulating on forums and in news write-ups naming other fonts as affected and others as safe, and they may well be correct — but they are not Microsoft's word, and we are not going to repeat them here as though they were. What you can rely on is the shape of the thing: it is font-dependent, Calibri is confirmed, and if you can identify which template fails you have learned something genuinely useful about your own situation.

The second defect, for offices where print preview is what dies

There is a second known issue in the same update, and it produces the same error message from a different cause. It is worth knowing about because its symptom is slightly different and because it carries the single most useful sentence Microsoft has published about this whole episode.

This one affects WPF applications that print, or display a print preview, from a document the program has built in memory rather than saved to disk. Microsoft's description is that images and fonts inside that document "are then incorrectly rejected as being outside the package" — the tightened boundary check is misfiring on the program's own content. In practice, the tell is that the failure happens at print preview, before you have even chosen a printer.

And then the sentence: "Application code and XPS content do not need to have changed for this failure to occur." That is Microsoft stating plainly that nothing on your end changed. It is the answer to the question every business owner asks first and gets fobbed off on — we did not update the software, we did not change the template, we did not touch anything, so why did it stop? Because the ground moved under a program that stayed still. If your software vendor's first instinct is to ask what you changed, that sentence is the one to send back.

Do not rule this out because you are not on the newest Windows

A reflexive objection we hear a lot: "that must be a Windows 11 thing, we are still on Windows 10." It is not, and that assumption sends people down the wrong path for days.

Microsoft's own summary table for this update covers, in one list, Windows 11 versions 26H1, 25H2, 24H2 and 23H2; Windows 10 versions 22H2, 21H2, and the older 1809 and 1607 builds; and Windows Server 2025, 2022, 2019, 2016, 2012 R2 and 2012. That is effectively the entire supported Windows estate, desktop and server, old and new. A ten-year-old server in a cupboard running a line-of-business application got this update too.

What differs between them is only the KB number. The Windows 11 25H2 build is KB5120708, 24H2 is KB5120710, 23H2 is KB5120713, Windows 10 22H2 and 21H2 are KB5120701 and KB5120709 depending on which .NET version is installed, and Windows Server 2022 is KB5120705 or KB5120714. You do not need to memorise those. You need one thing from them, which is the date: if a computer stopped printing from one program on or shortly after August 11, 2026, this is your prime suspect, and the KB number just confirms it. To check, open Settings, go to Windows Update, then Update history, and look at what installed around that date. If you are not sure which Windows version you are on in the first place, our guide to finding your Windows version walks through it.

There is a workaround — and it is not yours to apply

This is the part where our advice diverges sharply from most of what is written about this defect, and we want to be clear about why.

Microsoft has published a workaround. It is an AppContext switch — for the font issue it is called Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection, and for the print-preview issue it is Switch.System.Windows.DisableXpsPackageBoundaryRestriction. Almost every news article and forum thread about this has reproduced those switches as "the fix," sometimes with the exact lines to paste in.

We are naming them but not publishing the edit, and here is the reason. Read the switch name slowly: it disables an overflow protection. Microsoft's own caution, attached to both switches, says it "disables security protections introduced in the August 2026 update and might increase exposure to the vulnerabilities addressed by that update," and that Microsoft "recommends using this workaround only as a temporary measure and only when required to address this issue." Those are the six vulnerabilities from earlier — including three remote code execution flaws. The workaround is not a fix. It is a decision to take the security update's protection back off so the printing works again.

And critically, that switch does not go into a Windows setting. It goes into the configuration file of the application itself — which means it belongs to whoever makes that application, not to you, and not to whoever you call for computer help. A software vendor can apply it deliberately, to their own product, temporarily, and take it out again when Microsoft ships a proper fix, because they are the ones who will know when that happens. A well-meaning person editing a config file inside a program they did not write, and then forgetting about it forever, is a different thing entirely — that is how a printing problem quietly becomes a security problem that outlives everyone's memory of why the file was edited.

There is one more detail that strengthens this, and it is the reason we think "ask your vendor" is a genuinely better answer rather than just a cautious one. For the second defect, Microsoft publishes an alternative for applications that can be rebuilt — changing how the program identifies its own in-memory document — and says explicitly that this "resolves the failure while keeping the protections introduced in the August 2026 update enabled." In other words, a proper fix exists that does not trade away any security at all. Your vendor can do that. You cannot. So if a vendor tells you to just turn the switch on and leave it, it is entirely fair to ask them whether the rebuild option applies to their product.

What to actually do on Monday morning

None of the above helps if it does not turn into something you can do before the invoices go out. Here is the order.

First, run the Notepad test and write down the result. It takes two minutes and it is the difference between troubleshooting a program and troubleshooting a printer. Do not skip it because you are already sure.

Second, find out whether it is font-specific. Take a document that fails, and try the same operation on a document in the same program that uses a plainly different font. If one prints and the other does not, you have confirmed the shape of the problem and you have something concrete to hand over. Treat this strictly as a diagnostic, not as a fix — rebuilding all your templates in a different font to dodge a bug that Microsoft is going to fix is a lot of work to throw away in a month.

Third, get the date and the KB number from Windows Update history, as above.

Fourth — and this is the actual deliverable — contact whoever makes the program, and be specific, because a vague "our printing is broken" ticket will get you a vague answer about drivers. Something like this works: "Since the August 11, 2026 .NET Framework update (KB number here), our application fails with a System.IO.FileFormatException when printing or generating a PDF. This matches the known issue Microsoft published in the August 2026 .NET Framework release notes. Are you tracking it, and do you have guidance for your customers?" That paragraph puts the ticket in front of someone who can act on it, and it tells the vendor you already know the workaround carries a security cost, which changes the conversation.

Fifth, in the meantime, keep the business running. If the program can export to a format another application opens, print it from there. If a different template in a different font works, use that one for now. These are not fixes and nobody should pretend otherwise, but they get the invoices out this week, which is the actual goal.

What not to do

Do not uninstall the August security update to make the symptom go away. This is the most tempting move and the worst one on the list. The switch, whatever else is wrong with it, is narrow — it affects one application. Removing the update takes the protection off the entire machine for all six vulnerabilities, including the three remote code execution ones, and it leaves the computer in a state where the next round of updates will reinstall it anyway and the problem will come back looking mysterious. If you have already done this, the honest advice is to put the update back and work the vendor route instead.

Do not reinstall printer drivers, reset the print spooler, remove and re-add the printer, or run the printer troubleshooter. On this defect all of those are guaranteed to accomplish nothing, because you already proved with Notepad that the printing path works. They are the right steps for a different problem.

Do not buy a printer. We say this as people who do not sell printers: we have seen this exact symptom turn into a new printer more than once, and the new printer does not fix it either, because the failure never reaches the printer.

And do not pay anybody to clean, tune or optimise the computer over this. If a repair shop responds to "one program will not print since August" by quoting for a general clean-up, they have not read the symptom. The correct first move costs nothing and takes two minutes.

Where this stands right now, and what to watch

As of the date on this article, September 9, 2026, Microsoft's published status on both known issues is the same single word: Investigating. There is no fix yet, and no announced date for one.

One piece of timing explains a lot of the confusion around this, and it is worth knowing. The update shipped on August 11, but Microsoft did not add these known issues to the release notes until September 2 — three weeks later. For those three weeks the official documentation for the update said nothing was wrong with it. That is why perfectly competent software vendors, IT people and repair shops were telling customers in late August that it must be a driver: the authoritative source had not said otherwise yet. If you were told that at the time, nobody was being careless. The information genuinely was not there.

What resolution will look like: a later .NET Framework cumulative update that fixes the font handling properly, delivered through Windows Update like any other. When that lands, a machine that is kept up to date gets it automatically and the printing simply starts working again. The thing to watch for is any workaround switch that was turned on in the meantime — that is the loose end, and it belongs on somebody's list to take back out, because leaving it in place after the fix arrives means running a repaired system with the repair disabled.

If you are reading this well after September 2026, check the current status before acting on any of it. A resolved status changes the right answer completely: at that point the correct move is simply to install the latest updates, not to chase a workaround at all.

When it's worth handing it over

A lot of this is genuinely a do-it-yourself job, and deliberately so. The Notepad test, the font check, the Windows Update history, and a well-written email to your software vendor are all things a capable office manager can do in half an hour, and together they solve most of the problem — or at least stop anybody wasting a day on the printer.

Where it is worth calling somebody is when the answer is not landing. A vendor who will not engage, or who tells you to edit a config file and does not mention what the switch turns off. An office where four computers are fine and two are not, and nobody can work out what is different about the two. A server that runs the application for everybody, where the stakes of getting an update decision wrong are higher and the machine cannot simply be experimented on. Or the case where the Notepad test comes back the other way and it turns out you had an ordinary printer fault all along, sitting underneath a very convincing news story.

We look after small-business IT across Southern California and the Coachella Valley — offices in Pasadena, Arcadia and Monrovia, contractors and clinics in Orange County and Riverside, and the storefronts and practices along Highway 111 in Palm Desert and Rancho Mirage that run their entire day on one piece of software. Because we do not sell that software and we do not sell printers, we have no reason to tell you the problem is anything other than what it is. Sometimes the most valuable thing we do on a call like this is tell a business that the fault is not theirs, not their printer's, and not something they should be spending money on this week.