Microsofts .NET‑Update hat das Drucken lahmgelegt. Die eigentliche Lektion.

WPF (Windows Presentation Foundation) ist ein von Microsoft entwickeltes Framework zur Erstellung von Windows-Desktop-Anwendungen und basiert auf dem .NET Framework. Typische WPF-Anwendungen umfassen Windows‑basierte ERP‑, Buchhaltungs‑, Logistik‑, Konstruktions‑, Verwaltungs‑ und andere Branchenanwendungen. WPF ist besonders in Unternehmenssoftware verbreitet, die über viele Jahre auf dem Microsoft .NET Framework entwickelt wurde.

Anwendungen, die Berichte, Etiketten, Rechnungen oder andere druckbare Dokumente erzeugen, insbesondere ERP‑, POS‑ und Lagersysteme, die unter Windows druckensollten zuerst überprüft werden. Microsofts kumulatives Update für das .NET Framework vom August 2026 führt dazu, dass einige WPF‑Anwendungen beim Drucken oder bei der Erstellung von PDF/XPS-Ausgaben mit bestimmten Schriftarten, einschließlich Calibri, fehlschlagen, wie „The Register“ berichtete zuerst.Wenn dein Team dieses Update eingespielt hat und beim Drucken plötzlich Fehler auftreten, ist das vermutlich die Ursache.

Woran es wirklich hakt

Microsofts .NET Framework‑Updates vom 11. August führen dazu, dass einige WPF‑Apps eine System.IO.FileFormatException Beim Drucken oder bei der Erstellung von PDF/XPS-Dateien liegt das an der Art, wie bestimmte Schriftarten verarbeitet werden – darunter Calibri, die seit 2007 Standardschriftart in Word ist. Der Fehler betrifft Windows 10, Windows 11 und alle unterstützten Versionen von Windows Server von 2012 bis 2025 – also sehr viele Systeme für ein Darstellungsproblem bei Schriftarten.

Microsofts eigener Fix ist ein Schalter in der Konfigurationsdatei: Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtectionDieser Schutz wurde im selben August‑Update ergänzt, um eine Sicherheitslücke zu schließen. Ihn zu deaktivieren, um das Druckproblem zu beheben, heißt also, einen Fix rückgängig zu machen, der bewusst erst wenige Tage zuvor ausgeliefert worden war. Microsoft weist in seinen Leitfaeden darauf hin, beschreibt den Schalter als Übergangslösung und warnt, dass dadurch die durch das Update geschlossenen Schwachstellen wieder offenliegen.

Microsoft sagt, das Problem werde weiter untersucht. Für einen echten Fix gibt es noch keinen Zeitplan.

Was das beim Patchen für dich bedeutet

Wenn deine Nutzer:innen auf dieses Problem stoßen, stellst du das Drucken wieder her, indem du Microsofts Konfigurationsschalter (siehe unten) aktivierst. Damit wird der neue Schutz für die Schriftartenverarbeitung abgeschaltet. Laut Microsoft ist das ein Rückschritt bei der Sicherheit und nur als Übergangslösung gedacht. Wenn du diesen Weg gehst, dokumentiere, auf welchen Rechnern die Änderung vorgenommen wurde, damit du sie rückgängig machen kannst, sobald ein endgültiger Fix verfügbar ist.

Schnelle Lösung. Füge Folgendes zur Konfigurationsdatei der betroffenen Anwendung hinzu, und zwar unter <runtime>Es handelt sich um eine anwendungsspezifische Einstellung, nicht systemweit. Wenn die Anwendung also bereits über einen <runtime> Füge stattdessen diese Zeile in den Abschnitt ein, anstatt die Datei zu ersetzen:

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

Langfristig geht es weniger um diesen einen Bug als darum, welche Rolle das Drucken in deiner Umgebung spielt. Jedes Mal, wenn Drucken vom gesamten Windows-Stack (Treiber, Print spooler, .NET, WPF und alles, was eine bestimmte App sonst noch einbindet) abhängt, ist es auch jedem Patchrisiko dieses Stacks ausgesetzt – unabhängig davon, ob der Patch etwas mit dem Drucken zu tun hat oder nicht.

Drucken, das nicht von Windows abhängt

Dieser Bug sitzt in der WPF-App selbst – noch bevor ein Druckauftrag nachgelagerte Systeme, einschließlich ezeep, erreicht. Das gilt trotz über 25 Jahren Erfahrung im Enterprise-Druck. Er reiht sich in das Muster von Änderungen am Windows-Print-Stack ein, das Microsoft seit dem Windows Protected Print Mode vorantreibt. Das ist ein Grund, zu prüfen, was und wie in deiner Organisation gedruckt wird und dort, wo es die Anwendung zulässt, die Abhängigkeiten vom Windows-System zu reduzieren.

Speziell bei WPF-Apps zeigt dieser Bug genau, wo das Risiko liegt. WPF liefert seine eigene Druck‑Pipeline mit (PrintDialog, FixedDocument, XpsDocument), die Inhalte rendert und in einem Schritt die Druck- oder PDF-Ausgabe erzeugt. Für Entwickler:innen ist das der Weg des geringsten Widerstands: keine zusätzliche Bibliothek, sofort einsatzbereit. Und genau dieser Code ist es, der jetzt fehlerhaft ist.

Wenn du die Ausgabe mit einer separaten PDF‑Bibliothek erzeugst, die das Font‑Subsetting und Rendering von WPF vollständig umgeht, hebst du die Abhängigkeit von diesem speziellen Code auf. Kombiniert mit der ezeep-API (oder dem MCP-Server, für Apps, die mit KI-gestützten Entwickler-Tools erstellt wurden), die das Drucken übernimmt, ist die App danach nicht mehr generell vom Windows-Print-Stack abhängig — und damit nicht mehr nur von diesem einen Bug betroffen: Lageretiketten lassen sich direkt aus Bestellereignissen drucken, Rechnungen aus der Buchhaltungssoftware und Berichte nach Zeitplan, und das alles ohne angemeldete Nutzer:innen oder einen Druckdialog.

Das löst zwar nicht die Probleme auf Geräten, auf denen das fehlerhafte Update bereits installiert ist. Es ist jedoch ein Argument dafür, die nächste Version der App so zu entwickeln, dass auch der nächste Bug im Windows-Print-Stack nicht mehr dein Problem wird.

Bereit, deinen Print-Stack zu vereinfachen?

Überzeuge dich jetzt.

Kostenlos Testen