L'aggiornamento .NET di Microsoft ha bloccato la stampa. Ecco la vera lezione

WPF (Windows Presentation Foundation) è un framework sviluppato da Microsoft per la creazione di applicazioni desktop per Windows, basato su .NET Framework. Tra le applicazioni WPF più comuni ci sono ERP, software di contabilità, soluzioni per la logistica, l'ingegneria, l'amministrazione e altre applicazioni gestionali per Windows. WPF è particolarmente diffuso nel software aziendale sviluppato su Microsoft .NET Framework nel corso degli anni.

Le applicazioni che generano report, etichette, fatture o altri documenti stampabili, in particolare i sistemi ERP, POS e di magazzino che stampano tramite Windows, sono le prime da verificare. L'aggiornamento cumulativo di agosto 2026 di Microsoft per .NET Framework sta causando errori in alcune applicazioni WPF durante la stampa o la generazione di output PDF/XPS con determinati font, tra cui Calibri, come The Register è stato il primo a segnalarlo.Se il vostro team ha installato questo aggiornamento e la stampa ha improvvisamente iniziato a generare errori, è probabilmente questo il motivo.

Cosa è effettivamente andato storto

Gli aggiornamenti Microsoft per .NET Framework dell'11 agosto causano, in alcune app WPF, un'eccezione di tipo System.IO.FileFormatException Durante la stampa o la generazione di file PDF/XPS, il problema è legato al modo in cui vengono elaborati alcuni font, tra cui Calibri — il font predefinito di Word dal 2007. Il bug interessa Windows 10, Windows 11 e tutte le versioni supportate di Windows Server dal 2012 al 2025: un'area di impatto molto ampia per un problema di rendering dei font.

Microsoft stessa propone una soluzione: un'impostazione nel file di configurazione: Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtectionQuesta protezione era stata aggiunta con l'aggiornamento di agosto per chiudere una falla di sicurezza. Disattivarla per risolvere i problemi di stampa significa annullare una correzione rilasciata intenzionalmente pochi giorni prima. Microsoft lo segnala nelle proprie linee guida, definendo l'impostazione una misura temporanea e avvertendo che riapre l'esposizione alle vulnerabilità corrette dall'aggiornamento.

Microsoft dichiara di essere ancora in fase di indagine. Non c'è ancora una tempistica per una correzione definitiva.

Cosa significa se applicate le patch

Se i vostri utenti incontrano questo problema, l'attivazione dell'impostazione di Microsoft (vedi sotto) permette loro di tornare a stampare disattivando la nuova protezione per l'elaborazione dei font. È un passo indietro dal punto di vista della sicurezza, come segnala la stessa Microsoft, e va considerata temporanea. Se scegliete questa strada, tenete traccia delle macchine su cui l'attivate, così da rimuoverla non appena sarà disponibile una correzione definitiva.

Soluzione rapida. Aggiungetela al file di configurazione dell'applicazione interessata, nella sezione <runtime>Si tratta di un'impostazione per singola applicazione, non a livello di sistema, quindi se l'app ha già una <runtime> Nella sezione <runtime>, aggiungete questa riga invece di sostituire l'intero file:

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

Il punto, a lungo termine, riguarda meno questo singolo bug e più il ruolo della stampa nel vostro ambiente. Ogni volta che la stampa dipende dall'intero sistema di stampa di Windows (driver, spooler, .NET, WPF e qualsiasi altro componente richiamato da un'app), eredita tutti i rischi legati alle patch di quel sistema, indipendentemente dal fatto che la patch riguardi o meno la stampa.

Create un sistema di stampa che non dipenda da Windows

Questo bug risiede nell'app WPF stessa, prima che il processo di stampa raggiunga qualsiasi destinatario a valle, compreso ezeep. Accade nonostante oltre 25 anni di esperienza nella stampa per le grandi aziende. È solo un esempio del più ampio insieme di modifiche al sistema di stampa di Windows che Microsoft ha avviato fin dai tempi di Windows Protected Print Mode. È un buon motivo per verificare cosa e come si stampa nella vostra organizzazione e per ridurre le dipendenze da Windows dove l'app lo permette.

Per le app WPF in particolare, questo bug indica esattamente dove risiede il rischio. WPF include una propria pipeline di stampa (PrintDialog, FixedDocument, XpsDocument) che esegue il rendering del contenuto e produce l'output di stampa o PDF in un unico passaggio. È la via di minor resistenza per uno sviluppatore: nessuna libreria aggiuntiva da integrare e funziona subito. Ed è proprio quel codice che si è rotto.

Generare l'output con una libreria PDF separata — che non incide sul sottocampionamento dei font né sul rendering nativo di WPF — elimina la dipendenza da quel codice specifico. Abbinate questo approccio all'API di ezeep (o al suo MCP server, per le app create con strumenti di sviluppo assistiti dall'IA) per gestire la stampa, e l'applicazione cessa di dipendere dall'infrastruttura di stampa di Windows in generale, non solo da questo bug: etichette di magazzino stampate direttamente dagli eventi d'ordine, fatture generate dal software di contabilità, report pianificati, il tutto senza un utente autenticato né una finestra di dialogo di stampa.

Non risolverà le macchine che hanno già installato l'aggiornamento difettoso. È però un buon motivo per sviluppare la prossima versione dell'app, così il prossimo bug dello stack di stampa di Windows non sarà più un vostro problema.

Pronti a semplificare la vostra infrastruttura di stampa?

Scoprite subito come.

Provate gratuitamente