A atualização .NET da Microsoft quebrou a impressão. Esta é a verdadeira lição

O WPF (Windows Presentation Foundation) é um framework desenvolvido pela Microsoft para criar aplicações para desktop no Windows, construído sobre o .NET Framework. Aplicações WPF típicas incluem sistemas ERP para Windows, contabilidade, logística, engenharia, administração e outras aplicações de linha de negócios. O WPF é particularmente comum em software empresarial desenvolvido na plataforma Microsoft .NET Framework ao longo de muitos anos.

Aplicações que geram relatórios, etiquetas, faturas ou outros documentos para impressão, especialmente ERP, POS e sistemas de armazém que imprimem pelo WindowsMerecem ser verificadas primeiro. A atualização cumulativa de agosto de 2026 da Microsoft para o .NET Framework está fazendo com que algumas aplicações WPF falhem ao imprimir ou ao gerar saídas em PDF/XPS com certas fontes, incluindo a Calibri, conforme O The Register foi o primeiro a relatarSe sua equipe aplicou essa atualização e a impressão de repente começou a apresentar erros, é provável que essa seja a causa.

O que realmente quebrou

Segundo a Microsoft as atualizações do .NET Framework de 11 de agosto fazem com que algumas aplicações WPF lancem uma System.IO.FileFormatException na impressão ou na geração de PDF/XPS, relacionado a como certas fontes são processadas, incluindo a Calibri, que é a fonte padrão do Word desde 2007. O bug atinge o Windows 10, o Windows 11 e todas as versões com suporte do Windows Server de 2012 a 2025, o que representa uma área de impacto muito ampla para um problema de renderização de fontes.

A própria correção da Microsoft é uma chave no arquivo de configuração: Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection. Essa proteção foi adicionada na mesma atualização de agosto para fechar uma brecha de segurança. Desativá‑la para fazer a impressão funcionar significa reverter uma correção que foi lançada, de propósito, dias antes. A Microsoft afirma isso em sua própria orientação, descrevendo a chave como uma medida temporária e alertando que ela reabre a exposição às vulnerabilidades que a atualização corrigiu.

A Microsoft diz que ainda está investigando. Ainda não há um cronograma para uma correção definitiva.

O que isso significa se você aplicar patches

Se seus usuários forem afetados por isso, ativar a chave de configuração da Microsoft (abaixo) permitirá que voltem a imprimir, ao desativar a nova proteção de processamento de fontes. Isso representa um retrocesso em termos de segurança, segundo a própria Microsoft, e a medida deve ser temporária. Se você seguir por esse caminho, monitore em quais máquinas a alteração foi aplicada para que possa ser removida assim que uma correção definitiva for lançada.

Correção rápida. Adicione isto ao arquivo de configuração do aplicativo afetado, sob <runtime>. É uma configuração por aplicativo, não para toda a máquina, então, se o aplicativo já tiver uma <runtime> Na seção, adicione esta linha em vez de substituir o arquivo:

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

A questão a longo prazo é menos sobre este bug específico e mais sobre o papel que a impressão ocupa no seu ambiente. Toda vez que a impressão depende da pilha completa do Windows (drivers, spooler, .NET, WPF e tudo o que um aplicativo incorporar), ela herda todos os riscos de atualização dessa pilha, mesmo que a atualização não tenha relação com impressão.

Construa uma solução de impressão que não dependa do Windows

Esse bug está no próprio aplicativo WPF, antes de um trabalho de impressão chegar a qualquer sistema a jusante, incluindo o ezeep. Isso acontece mesmo com mais de 25 anos de experiência em impressão empresarial por trás. É um exemplo do padrão mais amplo de mudanças na pilha de impressão do Windows que a Microsoft tem promovido desde o Windows Protected Print Mode. É um motivo para avaliar o que e como sua organização imprime e, sempre que o aplicativo permitir, reduzir as dependências do sistema Windows.

Para aplicativos WPF especificamente, este bug aponta exatamente onde está o risco. O WPF vem com seu próprio pipeline de impressão (PrintDialog, FixedDocument, XpsDocument) que renderiza o conteúdo e gera a saída de impressão ou o PDF na mesma etapa. É o caminho de menor resistência para um desenvolvedor. Não há biblioteca extra para adicionar e funciona imediatamente. E é exatamente esse código que quebrou.

Gerar essa saída com uma biblioteca de PDF separada — que nunca interfere no subconjunto de fontes nem na renderização do próprio WPF — elimina a dependência desse código específico. Combine isso com a API do ezeep (ou seu MCP server, para aplicativos criados com ferramentas de desenvolvimento assistidas por IA) para lidar com a impressão, e o aplicativo deixa de depender da pilha de impressão do Windows de modo geral, não apenas deste bug específico: etiquetas de armazém podem ser impressas diretamente a partir de eventos de pedido, faturas do software de contabilidade e relatórios agendadostudo isso sem um usuário logado nem uma caixa de diálogo de impressão.

Isso não corrigirá máquinas que já tenham a atualização com falha instalada. Serve como argumento para desenvolver a próxima versão do aplicativo, para que o próximo bug na pilha de impressão do Windows não seja um problema para você.

Pronto para simplificar sua pilha de impressão?

Veja como agora.

Teste grátis