1 20/05/2026 10 min

MSVCP140.dll mancante: cosa sta davvero mancando

Se Windows mostra un errore su MSVCP140.dll mancante, il punto non è quasi mai “recuperare quella singola DLL”. Quasi sempre il problema è il runtime Microsoft Visual C++ Redistributable installato male, incompleto o corrotto. La DLL fa parte del pacchetto di esecuzione usato da molte applicazioni compilate con Visual Studio; se il runtime non c’è, è danneggiato o non corrisponde all’architettura richiesta, l’applicazione si ferma prima ancora di avviarsi.

La distinzione importante è questa: l’errore riguarda la dipendenza dell’applicazione, non il sistema operativo in sé. In pratica il programma cerca una libreria runtime, non la trova nel posto giusto oppure trova una versione incompatibile. Per questo la soluzione corretta è quasi sempre reinstallare o riparare il pacchetto redistribuibile ufficiale, verificare se serve la versione x86 o x64 e controllare che non ci siano installazioni sporche o duplicate.

Perché compare l’errore

MSVCP140.dll appartiene alla famiglia delle librerie C++ distribuite da Microsoft. Non è una DLL “di Windows” in senso stretto, ma una componente runtime che molte applicazioni terze parti usano per funzioni standard del linguaggio C++. Se il pacchetto Visual C++ Redistributable manca, o se l’app è stata aggiornata e il runtime è rimasto vecchio, il caricamento fallisce.

Ci sono tre scenari tipici. Il primo: il pacchetto non è installato. Il secondo: è installato ma corrotto, magari dopo un crash, una rimozione incompleta o un intervento di “pulizia” troppo aggressivo. Il terzo: l’applicazione richiede l’architettura sbagliata rispetto a quella presente nel sistema, ad esempio un programma a 32 bit che cerca il runtime x86 su un sistema dove è stato installato solo il pacchetto x64.

Un caso frequente, e spesso sottovalutato, è l’installazione manuale di una DLL trovata su siti casuali. È una scorciatoia sbagliata: oltre al rischio di sicurezza, può creare una corrispondenza errata di versione e peggiorare il problema. La strada giusta è usare i pacchetti ufficiali Microsoft e lasciare che Windows gestisca il posizionamento delle librerie nel modo previsto.

Prima verifica: capire quale applicazione sta fallendo

Non tutte le segnalazioni “MSVCP140.dll mancante” richiedono la stessa azione. La prima cosa utile è identificare quale programma genera l’errore. Se l’errore appare all’avvio di un software specifico, la diagnosi è molto più semplice: quel software dipende dal runtime e va ripristinato sul sistema in cui gira. Se invece l’errore compare dopo un aggiornamento, una reinstallazione o un cambio macchina, la probabilità che manchi il pacchetto corretto aumenta.

Se hai accesso al messaggio completo, annota il nome dell’eseguibile, il percorso e l’eventuale codice di errore. Se l’applicazione non parte proprio, apri Visualizzatore eventi e cerca gli errori applicativi in Registri di Windows > Applicazione. In molti casi si vede il modulo difettoso, il nome del processo e una descrizione coerente con il mancato caricamento della DLL.

Se il sistema è gestito in ambiente aziendale, conviene anche verificare se il problema è comparso su più postazioni. Se sì, il difetto potrebbe stare nel pacchetto distribuito via software management, in una policy o in un aggiornamento applicativo che ha introdotto una dipendenza non presente sui client.

La soluzione corretta: riparare o reinstallare Visual C++ Redistributable

La correzione più affidabile è reinstallare il Microsoft Visual C++ Redistributable 2015-2022, che copre la maggior parte dei casi moderni legati a MSVCP140.dll. In molti ambienti è sufficiente riparare il pacchetto già presente, ma se l’errore persiste conviene una reinstallazione pulita del runtime corretto.

Qui il punto operativo è semplice: x86 e x64 non sono intercambiabili. Su Windows a 64 bit, molte applicazioni a 32 bit richiedono il pacchetto x86 anche se il sistema è 64 bit. Per questo, in caso di dubbio, spesso è sensato installare entrambi i redistributable ufficiali, sempre dalla fonte Microsoft e non da archivi di terze parti.

Passi pratici consigliati

Apri Impostazioni > App > App installate oppure Pannello di controllo > Programmi e funzionalità e cerca le voci relative a Microsoft Visual C++ 2015-2022 Redistributable. Se sono presenti, prova prima l’opzione di Modifica o Ripara, quando disponibile. È l’azione meno invasiva e spesso basta a ricostruire i file mancanti o le registrazioni danneggiate.

Se la riparazione non basta, disinstalla le istanze corrotte e reinstalla i pacchetti ufficiali. In molti casi conviene installare sia la versione x86 sia la x64, perché non sai ancora quale binario stia chiedendo la DLL. Dopo l’installazione, riavvia il sistema se l’app continua a mostrare l’errore: il reboot non è sempre obbligatorio, ma elimina conflitti residui e blocchi su file in uso.

Link ufficiale Microsoft per il download del runtime: Visual C++ Redistributable supportato.

Verifiche mirate: come capire se il problema è x86, x64 o corruzione

Se vuoi evitare tentativi alla cieca, fai una verifica ordinata. Il primo obiettivo è capire se il runtime esiste già. In un sistema Windows, puoi controllare l’elenco dei pacchetti installati e cercare le voci Microsoft Visual C++ corrispondenti. Se una versione è presente ma il programma continua a fallire, il sospetto si sposta su corruzione o mismatch architetturale.

Un controllo utile è l’event viewer, perché spesso riporta il percorso del modulo che non riesce a caricarsi. Se il messaggio cita un file in C:\Windows\System32 o C:\Windows\SysWOW64, il dettaglio dell’architettura può dirti molto. Su Windows a 64 bit, System32 ospita i binari a 64 bit, mentre SysWOW64 è usato per la compatibilità a 32 bit. Il nome delle cartelle trae spesso in inganno, quindi conviene leggere il contesto prima di intervenire.

Se l’applicazione è stata appena aggiornata, confronta la sua architettura con quella del runtime installato. Un software a 32 bit non risolve il problema con un pacchetto x64, e viceversa. Se non hai la documentazione del vendor, il modo più rapido è provare l’installazione del pacchetto corretto su entrambe le architetture, perché il rischio operativo è basso e la verifica è immediata.

Quando il problema non è la DLL, ma l’applicazione

Non tutti i casi si risolvono col runtime. Alcune applicazioni includono una loro copia delle dipendenze o richiedono versioni molto specifiche della libreria. Se il software è vecchio, può dipendere da una release diversa del runtime Visual C++ e non dalla più recente. In quel caso la soluzione migliore è reinstallare il programma dal pacchetto ufficiale del vendor, non forzare una DLL generica nel sistema.

Un altro scenario è il file eseguibile corrotto o rimosso da antivirus o endpoint protection. Se il software è stato isolato o parzialmente messo in quarantena, il messaggio su MSVCP140.dll può essere solo il sintomo finale. Qui vale la pena controllare i log della soluzione di sicurezza e verificare se il file dell’applicazione è stato bloccato, non solo se manca la libreria runtime.

In un contesto amministrato, controlla anche eventuali installazioni portabili o copie manuali del programma. Se l’app viene avviata da una cartella condivisa, da un file server o da un percorso non standard, potrebbe non trovare le dipendenze nel modo previsto. In questi casi il fix strutturale è rendere l’installazione locale e supportata, non inseguire la singola DLL mancante.

La tentazione di scaricare la DLL da Internet: perché evitarla

Molti tutorial online propongono di scaricare MSVCP140.dll e copiarla a mano nella cartella del programma o in System32. È una pratica da evitare. Primo, perché non risolve la causa: se il runtime è mancante o rotto, la DLL isolata non ricostruisce il pacchetto. Secondo, perché introduce un rischio serio di sicurezza: una DLL presa da fonti non affidabili può essere alterata, incompatibile o infetta.

Terzo, perché la corrispondenza tra versione, architettura e dipendenze collaterali conta. Una DLL “simile” non è automaticamente quella giusta. Il runtime Microsoft è distribuito come insieme coerente di componenti e va installato come tale. Se l’errore persiste dopo il redistributable ufficiale, la strada corretta è analizzare il programma e i log, non improvvisare con file singoli.

Scenario tipico: software che si apre su un PC e fallisce su un altro

Un caso classico è il programma che funziona su una macchina ma fallisce su un’altra con lo stesso messaggio. Questo di solito indica differenze di ambiente: runtime non installato, aggiornamenti Windows diversi, architettura del software diversa, o un’installazione precedente che ha lasciato residui. Se il software è in uso in ufficio, il confronto tra le due postazioni è spesso la via più rapida per chiudere il problema.

Confronta la presenza di Microsoft Visual C++ Redistributable, la versione di Windows, eventuali aggiornamenti recenti e la modalità di installazione del programma. Se il software è identico ma una macchina funziona e l’altra no, il runtime è il primo indiziato. Se invece le versioni dell’applicazione differiscono, la causa può essere un pacchetto incompleto o una build che richiede una dipendenza non ancora distribuita.

Ripristino pulito: quando conviene fare un reset dell’installazione

Se riparazione e reinstallazione del runtime non bastano, il passo successivo è un ripristino più pulito del software che genera l’errore. Disinstalla l’applicazione, riavvia se necessario e reinstallala da fonte ufficiale. Questo riduce il rischio di file residui, manifest corrotti o dipendenze non più allineate. È una misura più invasiva, ma ancora reversibile e con impatto limitato al singolo software.

Prima di farlo, annota la versione installata e conserva eventuali configurazioni locali, profili o database utente. Molte applicazioni salvano impostazioni in %APPDATA%, %LOCALAPPDATA% o in cartelle dedicate sotto ProgramData. Se non fai un controllo prima, puoi risolvere il problema della DLL e perdere i dati di configurazione del programma.

Se l’app è critica per l’utente, il ripristino va pianificato come change controllato: backup dei dati applicativi, verifica della versione corretta, reinstallazione, test di apertura e controllo delle funzioni principali. In ambienti di produzione desktop o VDI, questo evita di trasformare un errore di runtime in un fermo operativo più ampio.

Controlli finali dopo la correzione

Quando il runtime è stato riparato o reinstallato, riapri l’applicazione e verifica che l’errore non compaia più. Se il programma parte ma presenta altri messaggi, il problema iniziale è probabilmente risolto e ora stai vedendo una dipendenza successiva. È un buon segnale: il loader ha superato il primo blocco, quindi la diagnosi si sposta su altro componente o configurazione.

Controlla anche il Visualizzatore eventi per confermare che non compaiano nuovi errori applicativi. Se il software si avvia normalmente ma si chiude subito dopo, il runtime potrebbe non essere l’unico problema. In quel caso conviene raccogliere il nome del modulo che va in fault, il codice eccezione e l’orario preciso, così da distinguere tra dipendenza mancante, file di configurazione corrotto e bug applicativo vero e proprio.

Se il problema è stato risolto installando il pacchetto corretto, annota la causa per evitare recidive: pacchetto assente, architettura errata, installazione danneggiata o software ripristinato. In ambienti gestiti, questa nota è utile per uniformare le immagini base e i deployment futuri.

Regola pratica da tenere a mente

Se compare un errore su MSVCP140.dll, la domanda giusta non è “dove trovo quella DLL?”, ma quale runtime manca o è rotto. Nella maggior parte dei casi la risposta è il pacchetto Microsoft Visual C++ Redistributable corretto, installato nella versione giusta e verificato sul sistema. È una correzione semplice, ma va fatta nel modo giusto: fonte ufficiale, architettura corretta, controllo dei log e niente file presi a caso dal web.