Августовский Patch Tuesday 2026 принёс Microsoft ещё одну неприятную историю для корпоративной разработки: после установки кумулятивных обновлений .NET Framework у части WPF-приложений ломаются печать и экспорт в PDF/XPS. Для команд, у которых десктопный Windows-софт до сих пор держит документооборот, отчёты и внутренние формы, такой сбой печати WPF выглядит не как досадный баг, а как вполне прикладной инцидент.
О проблеме сообщает BleepingComputer со ссылкой на уведомление Microsoft в Windows Release Health. Компания подтвердила, что ошибка затрагивает приложения, использующие Windows Presentation Foundation, то есть классический UI-фреймворк для настольных Windows-клиентов. После установки августовского кумулятивного обновления .NET Framework некоторые такие программы падают с System.IO.FileFormatException при печати или генерации PDF/XPS-контента с определёнными шрифтами, включая Calibri. Формулировка важная: речь не о произвольной деградации интерфейса, а о воспроизводимом сбое в конкретном сценарии, который для многих бизнес-приложений вообще-то основной.
Список затронутых платформ у Microsoft получился широким. Под удар попали клиентские версии Windows, включая актуальные сборки Windows 10 и Windows 11, а также серверные редакции от Windows Server 2012 до Windows Server 2025. Иными словами, история не про один неудачный апдейт для домашнего ПК, а про проблему, которая может одновременно задеть старые внутренние системы, терминальные фермы, VDI-контуры и вполне свежие рабочие станции разработчиков и сотрудников бэк-офиса. Для компаний, где WPF-приложения живут годами и обновляются осторожно, такой охват особенно неприятен: баг проявляется в самом скучном и потому самом критичном месте, где пользователи ждут просто работающую кнопку «Печать».
Постоянного исправления пока нет. Microsoft пишет, что продолжает расследование и в качестве временной меры предлагает включить специальный AppContext switch — Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection — через конфигурационный файл приложения. На бумаге это выглядит как типичный обходной путь из серии «пока так, потом починим нормально». На практике всё жёстче: вместе с этим переключателем отключаются защитные механизмы, которые как раз были добавлены августовским обновлением .NET Framework. То есть разработчику и администратору предлагают очень знакомый выбор из мира enterprise Windows: либо печать снова работает, либо остаётся защита от уязвимостей, закрытых в свежем security update. Microsoft отдельно предупреждает, что использовать такой workaround стоит только временно и только там, где без него нельзя обойтись.
С технической точки зрения это особенно показательный эпизод. Ошибка завязана на обработку шрифтов и проявляется при работе с определёнными гарнитурами, включая Calibri, то есть с чем-то максимально банальным для офисного документооборота. Отсюда неприятный вывод для команд сопровождения: даже если приложение почти не менялось, а код давно считается стабильным, внешний фактор в виде платформенного обновления способен внезапно сломать сценарии, которые никто не считает рискованными. В мире WPF это не новость, но каждый такой случай напоминает, что зрелость стека и годы в продакшене не равны иммунитету от регрессий, особенно когда в дело вмешиваются рендеринг, шрифты, печатные пайплайны и системные компоненты.
Контекст у истории тоже говорящий. Примерно пять лет назад, в феврале 2021 года, Microsoft уже закрывала известную проблему, из-за которой WPF-приложения и Visual Studio могли падать после установки кумулятивных обновлений Windows 10. Теперь картина повторяется в другой форме: не краш среды разработки, а поломка печати и экспорта документов. Параллельно в августе 2026 года компания уже публиковала временное решение для другой проблемы Patch Tuesday — с вылетами и зависаниями игр на Windows 11, включая ARC Raiders, MARVEL Tōkon: Fighting Souls и The Finals. Это не значит, что у Microsoft внезапно развалился весь контроль качества. Но это точно значит, что даже крупные вендоры всё чаще выпускают обновления, после которых «known issue» становится почти обязательным жанром сопровождения релиза.
Для русскоязычной IT-аудитории здесь несколько вполне практичных выводов. Если у вас есть WPF-приложения с печатью договоров, счетов, маршрутных листов, складских документов или любых PDF-выгрузок, августовские обновления .NET Framework нужно проверять не только по чек-листу «запускается или нет». Нужны отдельные тесты на печать, XPS и PDF, причём со штатными корпоративными шрифтами и реальными шаблонами документов. Если проблема уже проявилась, решение через AppContext switch надо рассматривать как временное и только после оценки рисков: вы буквально отключаете часть защит, внедрённых security-патчем. Для продуктовых команд это повод заранее подготовить коммуникацию с поддержкой и бизнесом, а для инфраструктурных команд — решить, где допустим временный workaround, а где безопаснее ждать официальный фикс.
История с сбоем печати WPF ещё и хорошо показывает текущее положение старых, но живых Windows-стеков. WPF никуда не делся: его продолжают использовать в корпоративных системах, толстых клиентах, инженерном софте и внутренних инструментах, которые не переедут в браузер только потому, что кому-то так красивее на архитектурной схеме. Значит, проблема не в том, что стек «старый», а в том, что его владельцам приходится жить между безопасностью и совместимостью. Августовский кейс Microsoft неприятен именно этим: он снова напоминает, что в enterprise-разработке уязвимость и сломанный бизнес-процесс нередко прилетают одним и тем же обновлением, а выбор между ними всё ещё приходится делать вручную.