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

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

Aplicativos que geram relatórios, etiquetas, faturas ou outros documentos para impressão, especialmente sistemas de ERP, POS e de armazém que imprimem pelo Windows, devem ser verificados 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 gerar saídas em PDF/XPS com certas fontes, incluindo a Calibri, conforme relatado primeiro pelo The Register. Se sua equipe instalou essa atualização e a impressão começou a apresentar erros de repente, esse provavelmente é o motivo.

O que realmente quebrou

As atualizações de 11 de agosto do .NET Framework da Microsoft fazem com que algumas aplicações WPF lancem um System.IO.FileFormatException na impressão ou na geração de PDF/XPS, ligado à forma como certas fontes são processadas, incluindo a Calibri, fonte padrão do Word desde 2007. O bug atinge o Windows 10, o Windows 11 e todas as versões suportadas do Windows Server de 2012 a 2025, o que representa uma grande superfície 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 restaurar a impressão significa reverter uma correção que foi disponibilizada intencionalmente dias antes. A Microsoft diz isso em sua orientação, enquadrando 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ê estiver aplicando patches

Se seus usuários enfrentarem esse problema, ativar a chave de configuração da Microsoft (abaixo) fará com que eles voltem a imprimir, desativando a nova proteção de processamento de fontes. Isso é um retrocesso em segurança, segundo a própria Microsoft, e a intenção é que seja temporário. Se você seguir por esse caminho, monitore em quais máquinas a alteração foi aplicada para que ela possa ser revertida assim que uma correção definitiva for lançada.

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

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

A questão a longo prazo tem menos a ver com este bug específico e mais com o papel da impressão no seu ambiente. Toda vez que a impressão depende de toda a pilha do Windows (drivers, print spooler, .NET, WPF e tudo o mais que um determinado aplicativo utiliza), ela herda todos os riscos introduzidos por patches nessa pilha, mesmo que o patch não tenha relação com impressão.

Implemente impressão que não dependa do Windows

Este bug alcança todos que dependem do pipeline de impressão padrão do Windows. A forma de evitar a exposição a bugs como este não é esperar por um sistema de impressão do Windows melhor; é mudar a maneira como seu aplicativo imprime desde o início.

Para aplicativos WPF, isso significa evitar a forma padrão de montar documentos. PrintDialog, FixedDocument e XpsDocument passam pelo próprio processo de subsetting e renderização de fontes do WPF — exatamente o código que quebrou aqui. Em vez disso, gere um PDF com uma biblioteca independente que nunca toque nesse pipeline e entregue-o ao ezeep pela API (ou pelo MCP server, para aplicativos criados com ferramentas de desenvolvimento assistidas por IA) em vez de usar o caminho de impressão do SO. Isso cobre trabalhos de backend que nunca passam por uma tela, etiquetas de armazém geradas a partir de eventos de pedido, faturas geradas por software de contabilidade, relatórios agendados, e também cobre o caso do dia a dia: um funcionário na mesa clicando para imprimir a única página de que precisa, sem a caixa de diálogo de impressão do SO em nenhum dos casos.

Pronto para simplificar sua pilha de impressão?

Veja agora como.

Teste grátis