Aktualizacja .NET Microsoftu zepsuła drukowanie. Oto prawdziwa lekcja

WPF (Windows Presentation Foundation) to framework stworzony przez Microsoft do tworzenia aplikacji desktopowych dla systemu Windows, oparty na .NET Framework. Typowe aplikacje WPF to systemy ERP, programy księgowe, rozwiązania logistyczne, narzędzia inżynieryjne, aplikacje administracyjne i inne krytyczne aplikacje biznesowe działające w środowisku Windows. WPF jest szczególnie powszechny w oprogramowaniu korporacyjnym rozwijanym przez lata na platformie Microsoft .NET Framework.

Warto najpierw sprawdzić aplikacje generujące raporty, etykiety, faktury i inne dokumenty do druku, zwłaszcza systemy ERP, POS i magazynowe, które drukują przez system Windows. Sierpniowa zbiorcza aktualizacja .NET Framework z 2026 roku od Microsoftu powoduje, że niektóre aplikacje WPF zgłaszają błędy podczas drukowania lub generowania plików PDF/XPS przy użyciu określonych czcionek, w tym Calibri — poinformował o tym jako pierwszy serwis The Register. Jeśli Wasz zespół zainstalował tę aktualizację i nagle pojawiły się błędy przy drukowaniu, to najprawdopodobniej dlatego.

Co właściwie się zepsuło

Aktualizacje .NET Framework z 11 sierpnia powodują, że niektóre aplikacje WPF rzucają wyjątek System.IO.FileFormatException podczas drukowania lub generowania PDF/XPS. Problem wiąże się ze sposobem przetwarzania niektórych czcionek, w tym Calibri — domyślnej czcionki w Wordzie od 2007 roku. Błąd dotyka Windows 10, Windows 11 oraz wszystkie wspierane wersje Windows Server od 2012 do 2025, co daje duży obszar wpływu jak na problem z renderowaniem czcionek.

Proponowane przez Microsoft rozwiązanie to przełącznik w pliku konfiguracyjnym: Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection. Ochrona ta została dodana w tej samej sierpniowej aktualizacji, by zamknąć lukę bezpieczeństwa. Wyłączenie jej, by przywrócić drukowanie, oznacza więc wyłączenie poprawki wdrożonej celowo kilka dni wcześniej. Microsoft zaznacza to w oficjalnych wytycznych, opisując przełącznik jako tymczasowe obejście i ostrzegając, że ponownie odsłania on podatności załatane przez aktualizację.

Microsoft informuje, że sprawa jest wciąż badana. Na razie nie podano terminu wydania trwałej poprawki.

Co to oznacza, jeśli stosujecie poprawki

Jeśli użytkownicy napotkają ten problem, włączenie przełącznika konfiguracyjnego Microsoftu (poniżej) przywróci im możliwość drukowania, wyłączając nową ochronę przetwarzania czcionek. Według samego Microsoftu to krok wstecz w zakresie bezpieczeństwa i ma być rozwiązaniem tymczasowym. Jeśli wybierzecie tę drogę, śledźcie, na których maszynach zmiana została zastosowana, aby móc ją cofnąć zaraz po udostępnieniu właściwej poprawki.

Szybka naprawa. Dodajcie to do pliku konfiguracyjnego dotkniętej aplikacji, w sekcji <runtime>. To ustawienie per‑app, nie globalne dla maszyny, więc jeśli aplikacja ma już sekcję <runtime>, wstawcie ten wiersz do niej zamiast zastępować cały plik:

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

W dłuższej perspektywie chodzi mniej o ten konkretny błąd, a bardziej o rolę, jaką drukowanie pełni w Waszym środowisku. Za każdym razem, gdy drukowanie zależy od pełnego stosu Windows (sterowniki, bufor wydruku, .NET, WPF i cokolwiek innego, z czego korzysta dana aplikacja), dziedziczy ono ryzyko związane z aktualizacjami tego stosu — nawet jeśli poprawka nie ma nic wspólnego z drukowaniem.

Zbudujcie drukowanie niezależne od Windows

Ten błąd dotyczy wszystkich korzystających ze standardowego potoku drukowania w Windows. Sposób na uniknięcie narażenia na podobne problemy to nie liczenie na lepszy system drukowania w Windows, lecz zmiana podejścia do tego, jak aplikacje wysyłają wydruki.

Dla aplikacji WPF oznacza to unikanie standardowego sposobu budowania dokumentów. PrintDialog, FixedDocument i XpsDocument przechodzą przez mechanizm podzbiorowania czcionek i renderowania WPF — dokładnie ten fragment kodu, który tu zawiódł. Zamiast tego wygenerujcie plik PDF za pomocą niezależnej biblioteki, która nie korzysta z tego potoku, i przekażcie go do ezeep przez API (albo przez jego serwer MCP, dla aplikacji tworzonych w narzędziach deweloperskich wspierających AI), omijając systemową ścieżkę drukowania. To obejmuje zadania backendowe, które nigdy nie trafiają na ekran — etykiety magazynowe z zamówień, faktury z systemów księgowych, raporty generowane według harmonogramu — ale działa też w codziennym scenariuszu: pracownik przy biurku klika „drukuj”, by otrzymać jedną stronę — bez konieczności uruchamiania okna dialogowego systemu operacyjnego.

Ready to Simplify Your Print Stack?

See how now.

Start Free Trial