La actualización .NET de Microsoft ha roto las impresiones. Esta es la verdadera lección

WPF (Windows Presentation Foundation) es un marco desarrollado por Microsoft para crear aplicaciones de escritorio para Windows, basado en .NET Framework. Las aplicaciones WPF típicas incluyen ERP, contabilidad, logística, ingeniería, administración y otras aplicaciones empresariales verticales basadas en Windows. WPF es especialmente habitual en software empresarial que se ha desarrollado sobre Microsoft .NET Framework a lo largo de muchos años.

Merece la pena comprobar primero las aplicaciones que generan informes, etiquetas, facturas u otros documentos imprimibles, especialmente los sistemas ERP, TPV y de almacén que imprimen a través de Windows. La actualización acumulativa de agosto de 2026 de Microsoft para .NET Framework está provocando que algunas aplicaciones WPF fallen al imprimir o al generar archivos PDF/XPS con determinadas fuentes, incluida Calibri, como informó primero The Register. Si tu equipo instaló esta actualización y la impresión empezó a dar errores de repente, es probable que esa sea la razón.

Qué se rompió realmente

Las actualizaciones del 11 de agosto para .NET Framework de Microsoft provocan que algunas aplicaciones WPF arrojen un System.IO.FileFormatException al imprimir o generar archivos PDF/XPS, ligado a cómo se procesan ciertas fuentes, incluida Calibri, la fuente por defecto en Word desde 2007. El fallo afecta a Windows 10, Windows 11 y a todas las versiones compatibles de Windows Server desde 2012 hasta 2025, lo que supone una superficie muy amplia para un problema de renderizado de fuentes.

La propia solución de Microsoft es un interruptor en el archivo de configuración: Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection. Esa protección se añadió en la misma actualización de agosto para cerrar una brecha de seguridad. Desactivarla para arreglar la impresión significa anular una corrección que se implementó a propósito días antes. Microsoft lo reconoce en sus directrices, presentando el interruptor como una medida temporal y advirtiendo que vuelve a exponer el sistema a las vulnerabilidades que la actualización había parcheado.

Microsoft afirma que sigue investigando. Todavía no hay fecha para una solución definitiva.

Qué significa esto si estás parcheando

Si tus usuarios se topan con esto, activar el interruptor de configuración de Microsoft (más abajo) les permitirá volver a imprimir apagando la nueva protección de procesamiento de fuentes. Según la propia descripción de Microsoft, es un retroceso en seguridad y debe ser temporal. Si optas por esta vía, controla qué equipos lo tienen aplicado para retirarlo en cuanto se publique una solución definitiva.

Solución rápida. Añade lo siguiente al archivo de configuración de la aplicación afectada, en la sección <runtime>. Es una configuración por aplicación, no para todo el equipo, así que si la aplicación ya tiene una sección <runtime>, añade esta línea en ella en lugar de reemplazar el archivo:

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

A largo plazo, la cuestión no es tanto este error concreto, sino el lugar que ocupan las impresiones en tu entorno. Cada vez que las impresiones dependen de toda la pila de Windows (controladores, print spooler, .NET, WPF y cualquier otra cosa que utilice una aplicación) heredan todos los riesgos de los parches de esa pila, tengan o no relación con la impresión.

Crea un sistema de impresión que no dependa de Windows

Este error afecta a cualquiera que dependa del proceso de impresión estándar de Windows. La forma de evitar la exposición a errores como este no es esperar a un sistema de impresión de Windows mejor, sino cambiar la manera en que tu aplicación imprime desde el principio.

Para las aplicaciones WPF, eso significa evitar la forma estándar de generar documentos. PrintDialog, FixedDocument y XpsDocument pasan por el subconjunto de fuentes y el renderizado propios de WPF, el código exacto que falló aquí. En su lugar, crea un PDF con una biblioteca independiente, que nunca toque ese canal, y entrégaselo a ezeep a través de la API (o a través de su servidor MCP, para apps creadas con herramientas de desarrollo asistidas por IA) en lugar de usar la ruta de impresión del sistema operativo. Así cubres trabajos de backend que nunca ven una pantalla, como etiquetas de almacén generadas por eventos de pedido, facturas desde software de contabilidad e informes programados, y también el caso cotidiano: un empleado en su escritorio hace clic en imprimir la página que necesita, sin que aparezca el cuadro de diálogo de impresión del sistema operativo.

Ready to Simplify Your Print Stack?

See how now.

Start Free Trial