La mise à jour .NET de Microsoft a cassé l'impression. Voici la vraie leçon

WPF (Windows Presentation Foundation) est un framework développé par Microsoft pour créer des applications de bureau sous Windows, reposant sur le .NET Framework. Les applications WPF typiques incluent des ERP fonctionnant sous Windows, ainsi que des logiciels de comptabilité, de logistique, d'ingénierie, d'administration et d'autres applications métier. WPF est particulièrement répandu dans les logiciels d'entreprise développés sur le .NET Framework de Microsoft depuis de nombreuses années.

Les applications qui génèrent des rapports, des étiquettes, des factures ou d'autres documents à imprimer, en particulier les systèmes ERP, POS et de gestion d'entrepôt qui impriment via Windowsméritent d'être vérifiés en priorité. La mise à jour cumulative d'août 2026 du .NET Framework de Microsoft entraîne l'échec de certaines applications WPF lors de l'impression ou de la génération de fichiers PDF/XPS avec certaines polices, dont Calibri, comme The Register a été le premier à le rapporter. Si votre équipe a déployé cette mise à jour et que des erreurs d'impression sont soudainement apparues, c'est probablement la raison.

Ce qui a réellement posé problème

de Microsoft Mises à jour du .NET Framework — 11 août provoquent dans certaines applications WPF la génération d'une System.IO.FileFormatException Il survient lors de l'impression ou de la génération de fichiers PDF/XPS ; il est lié à la façon dont certaines polices sont traitées, notamment Calibri, la police par défaut de Word depuis 2007. Le bogue affecte Windows 10, Windows 11 et toutes les versions prises en charge de Windows Server de 2012 à 2025, ce qui représente une large surface d'impact pour un problème de rendu des polices.

Le correctif proposé par Microsoft est une bascule dans un fichier de configuration : Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtectionCette protection a été ajoutée dans la mise à jour d'août pour corriger une faille de sécurité. La désactiver pour résoudre les problèmes d'impression revient à annuler un correctif déployé volontairement quelques jours plus tôt. Microsoft le reconnaît dans ses propres recommandations : il s'agit d'une mesure temporaire qui réexpose les systèmes aux vulnérabilités que la mise à jour avait corrigées.

Microsoft indique que l'enquête est toujours en cours. Aucun calendrier n'a encore été annoncé pour un correctif définitif.

Ce que cela signifie si vous déployez les correctifs

Si vos utilisateurs rencontrent ce problème, activer la bascule de configuration de Microsoft (ci‑dessous) leur permettra d'imprimer à nouveau en désactivant la nouvelle protection du traitement des polices. C'est un recul en matière de sécurité, d'après Microsoft lui‑même, et cette mesure est conçue pour être temporaire. Si vous choisissez cette solution, consignez les machines concernées afin de retirer la bascule dès qu'un correctif définitif sera publié.

Solution rapide. Ajoutez ceci au fichier de configuration de l'application concernée, sous <runtime>Il s'agit d'un paramètre par application, et non à l'échelle de la machine, donc si l'application possède déjà un <runtime> Dans la section <runtime>, ajoutez cette ligne plutôt que de remplacer le fichier :

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

Il s'agit moins de ce bug ponctuel que de la place qu'occupe l'impression dans votre environnement. Chaque fois que l'impression dépend de la pile Windows complète (pilotes, spouleur d'impression, .NET, WPF, et tout ce qu'une application donnée peut utiliser), elle hérite de tous les risques liés aux correctifs de cette pile, qu'ils concernent l'impression ou non.

Construisez une solution d'impression indépendante de Windows

Ce bug se situe dans l'application WPF elle‑même, avant qu'une tâche d'impression n'atteigne quoi que ce soit en aval — ezeep inclus. Cela reste vrai même après plus de 25 ans d'expérience dans l'impression d'entreprise. Ce cas s'inscrit dans un mouvement plus large de modifications de la pile d'impression Windows engagé par Microsoft depuis Windows Protected Print. C'est une raison de faire le point sur ce qui s'imprime dans votre organisation et sur la manière dont cela se fait, puis de réduire les dépendances au système Windows partout où l'application le permet.

Pour les applications WPF en particulier, ce bug montre exactement où se situe le risque. WPF embarque son propre pipeline d'impression (PrintDialog, FixedDocument, XpsDocument) qui rend le contenu et produit l'impression ou le PDF en une seule étape. C'est la voie de moindre résistance pour un développeur : aucune bibliothèque supplémentaire à ajouter, et ça fonctionne immédiatement. Et c'est précisément ce code qui s'est avéré défaillant.

Générer ce rendu avec une bibliothèque PDF distincte — qui n'interagit jamais avec le sous-ensemble de polices ni le rendu propres à WPF — supprime la dépendance à ce code spécifique. Combinez cela avec l'API d'ezeep (ou son MCP server, pour les applications développées avec des outils de développement assistés par IA) pour gérer l'impression, et l'application cesse de dépendre de la pile d'impression Windows en général, et pas seulement de ce bug : les étiquettes d'entrepôt peuvent s'imprimer directement à partir d'événements de commande, les factures depuis un logiciel de comptabilité, et les rapports selon un calendrier, le tout sans utilisateur connecté ni boîte de dialogue d'impression.

Cela ne résoudra pas les machines qui exécutent déjà la mise à jour défaillante. C'est un argument pour concevoir la prochaine version de l'application afin que le prochain bug de la pile d'impression Windows ne soit pas non plus votre problème.