Aktualizacja .NET firmy Microsoft zepsuła drukowanie. Oto prawdziwa lekcja

WPF (Windows Presentation Foundation) to framework opracowany przez Microsoft do tworzenia aplikacji desktopowych dla systemu Windows, oparty na .NET Framework. Typowe aplikacje WPF to systemy ERP, księgowe, logistyczne, inżynieryjne, administracyjne oraz inne aplikacje biznesowe działające w systemie Windows. WPF jest szczególnie powszechny w oprogramowaniu dla dużych przedsiębiorstw, które było rozwijane przez wiele lat na platformie Microsoft .NET Framework.

Aplikacje, które generują raporty, etykiety, faktury lub inne dokumenty do druku, w szczególności systemy ERP, POS i magazynowe, które drukują za pośrednictwem systemu Windows, warto sprawdzić w pierwszej kolejności. Sierpniowa aktualizacja zbiorcza Microsoftu dla .NET Framework z 2026 roku powoduje, że niektóre aplikacje WPF zgłaszają błędy podczas drukowania lub tworzenia plików PDF/XPS z użyciem określonych czcionek, w tym Calibri, o czym jako pierwszy poinformował serwis The Register. Jeśli wasz zespół wdrożył tę aktualizację, a drukowanie nagle zaczęło zgłaszać błędy, to jest to najprawdopodobniejsza przyczyna.

Na czym polega problem

Aktualizacje Microsoftu z 11 sierpnia dla .NET Framework powodują, że niektóre aplikacje WPF wyrzucają wyjątek System.IO.FileFormatException podczas drukowania lub tworzenia plików PDF/XPS, związany ze sposobem przetwarzania niektórych czcionek, w tym Calibri — domyślnej czcionki w programie Word od 2007 roku. Błąd dotyczy Windows 10, Windows 11 oraz wszystkich wspieranych wersji Windows Server od 2012 do 2025 roku, co oznacza duży zasięg problemu z renderowaniem czcionek.

Własna poprawka Microsoftu to przełącznik w pliku konfiguracyjnym: Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtectionOchrona ta została dodana w tej samej sierpniowej aktualizacji, aby zamknąć lukę w zabezpieczeniach. Wyłączenie jej, by naprawić drukowanie, oznacza wyłączenie poprawki, która została celowo wdrożona zaledwie kilka dni wcześniej. Microsoft sam o tym informuje w swoich wytycznych, określając przełącznik jako środek tymczasowy i ostrzegając, że ponownie naraża on system na luki, które aktualizacja miała załatać.

Microsoft informuje, że nadal bada sprawę. Na razie nie podano harmonogramu udostępnienia właściwej poprawki.

Co to oznacza, jeśli stosujecie poprawki

Jeśli wasi użytkownicy napotkają ten problem, włączenie przełącznika konfiguracyjnego Microsoftu (poniżej) przywróci możliwość drukowania przez wyłączenie nowej ochrony przetwarzania czcionek. To krok wstecz w kwestii bezpieczeństwa, jak przyznaje sam Microsoft, i ma być rozwiązaniem tymczasowym. Jeśli zdecydujecie się na to, monitorujcie, na których maszynach zostało zastosowane, aby móc je usunąć w momencie udostępnienia właściwej poprawki.

Szybkie rozwiązanie. Dodajcie ten wpis do pliku konfiguracyjnego aplikacji, której dotyczy problem, w sekcji <runtime>. Jest to ustawienie dla konkretnej aplikacji, a nie dla całego komputera, więc jeśli aplikacja ma już <runtime> W sekcji dodajcie ten wiersz, zamiast zastępować cały plik:

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

W szerszej perspektywie nie chodzi tylko o ten jeden błąd, lecz o to, jaką rolę drukowanie pełni w waszym środowisku. Za każdym razem, gdy drukowanie zależy od pełnego stosu Windows (sterowników, bufora wydruku, .NET, WPF i wszystkiego, co dana aplikacja wykorzystuje), przejmuje ono każde ryzyko związane z poprawkami w tym stosie — niezależnie od tego, czy poprawka ma cokolwiek wspólnego z drukowaniem.

Stwórzcie drukowanie niezależne od Windows

Ten błąd występuje wewnątrz samej aplikacji WPF, zanim zadanie drukowania dotrze do jakiegokolwiek systemu downstream, wliczając w to ezeep. Dzieje się tak mimo ponad 25 lat doświadczenia w druku korporacyjnym stojącego za technologią. To jeden przejaw szerszego wzorca zmian w stosie drukowania Windows, które Microsoft wprowadza od czasu Windows Protected Print Mode. To dobry powód, by przeanalizować, co i jak drukujecie w organizacji, a następnie ograniczyć zależności od Windows tam, gdzie pozwala na to aplikacja.

W przypadku aplikacji WPF ten błąd wskazuje dokładnie, gdzie leży ryzyko. WPF dostarcza własny potok drukowania (PrintDialog, FixedDocument, XpsDocument), który w tym samym kroku renderuje zawartość i tworzy wydruk lub plik PDF. Dla dewelopera jest to ścieżka najmniejszego oporu: nie trzeba dodawać żadnych bibliotek i działa to od razu. I to właśnie ten kod uległ awarii.

Generowanie wydruku za pomocą oddzielnej biblioteki PDF — takiej, która nie wykorzystuje mechanizmów WPF do osadzania czcionek i renderowania — eliminuje zależność od tego konkretnego fragmentu kodu. Połączcie to z ezeep's API (lub jego MCP server, w przypadku aplikacji tworzonych w narzędziach deweloperskich wspomaganych przez AI) do obsługi drukowania — i aplikacja przestanie polegać na stosie drukowania Windows w ogóle, nie tylko na tym jednym błędzie: np. etykiety magazynowe drukowane bezpośrednio po zdarzeniach zamówień, faktury z systemu księgowego oraz raporty według harmonogramu, i to wszystko bez zalogowanego użytkownika ani okna dialogowego drukowania.

To nie naprawi maszyn, które już mają tę wadliwą aktualizację. To argument za tym, by zaprojektować kolejną wersję aplikacji tak, aby kolejny błąd w stosie drukowania Windows również nie był Waszym problemem.

Gotowi, aby uprościć swój stos drukowania?

Przekonajcie się sami.

Wypróbujcie bezpłatnie