Windows 11 + WinForms: perché AxMSCommLib.AxMSComm smette di funzionare (e come risolvere)
Se hai un progetto WinForms in VB.NET (o C#) che su Windows 10 funzionava perfettamente e su Windows 11 invece “non apre nemmeno il form”, è molto probabile che il colpevole sia lui:
Me.com = New AxMSCommLib.AxMSComm()
Questo articolo nasce da un caso reale: su Windows 11 l’app andava in errore durante l’inizializzazione del form, impedendo l’avvio dell’interfaccia e quindi di tutta l’applicazione.
Vediamo perché succede e soprattutto come sistemarlo in modo definitivo.
Il problema: il form non si apre e l’app sembra “bloccata”
Il comportamento tipico è questo:
- l’app parte, ma il form non viene mostrato
- a volte si vede una finestra di errore (o niente, se l’eccezione non viene gestita)
- l’errore avviene all’avvio, prima che l’utente possa fare qualsiasi cosa
La riga incriminata è quasi sempre dentro InitializeComponent() e riguarda la creazione del controllo ActiveX:
Me.com = New AxMSCommLib.AxMSComm()
Perché su Windows 11 succede e su Windows 10 no?
AxMSCommLib.AxMSComm è un wrapper .NET del vecchio controllo MSComm32 (ActiveX, era molto usato in VB6).
Punti chiave:
- MSComm32.OCX è 32-bit
- Windows 11 (come Windows 10) è spesso installato in versione 64-bit
- se il progetto viene eseguito a 64-bit (AnyCPU/64-bit), l’ActiveX 32-bit non viene caricato
- inoltre, il file
.OCXdeve essere presente e registrato nel sistema
Su Windows 10 può capitare che:
- il componente fosse già presente e registrato (magari per installazioni precedenti)
- il progetto fosse già “di fatto” in x86 senza che ce ne accorgessimo
Su Windows 11, spesso, queste condizioni non ci sono.
Soluzione passo-passo
1) Registrare correttamente l’OCX (32-bit)
Il file corretto, in un sistema 64-bit, si trova (di solito) qui:
C:\Windows\SysWOW64\MSCOMM32.OCX
La registrazione va fatta usando regsvr32 a 32-bit (quello in SysWOW64):
C:\Windows\SysWOW64\regsvr32.exe C:\Windows\SysWOW64\MSCOMM32.OCX
Attenzione: usare
regsvr32inSystem32può portare a registrazioni non coerenti o errori “strani”.
Se durante la registrazione compare “operazione riuscita”, significa che il sistema lo vede.
2) Compilare ed eseguire l’app in x86 (fondamentale)
Questa è la parte che spesso manca: anche se l’OCX è registrato, se l’app gira a 64-bit continuerà a fallire.
In Visual Studio:
- Vai su Proprietà progetto
- Sezione Build/Compilazione
- Imposta Target CPU / Platform target = x86
- Fai Clean e poi Rebuild
Inoltre, controlla Configuration Manager:
- la Solution Platform deve essere x86
- evita Any CPU se stai usando MSComm
Perché così si risolve?
Perché stai allineando tutte le “dimensioni”:
- OCX = 32-bit
- runtime COM ActiveX = 32-bit
- applicazione = 32-bit (x86)
Quando questi tre elementi sono coerenti, New AxMSCommLib.AxMSComm() non fallisce più e il form si apre regolarmente.
Consiglio finale: soluzione “definitiva” senza ActiveX
MSComm è un pezzo di storia. Funziona, sì, ma porta sempre con sé questi problemi:
- dipendenza da OCX esterni
- registrazioni di sistema
- incompatibilità 32/64-bit
- distribuzione più complessa ai clienti
Se stai mantenendo o aggiornando l’app, valuta seriamente di sostituirlo con System.IO.Ports.SerialPort, che è la gestione seriale nativa .NET (senza ActiveX).
Checklist rapida
Se su Windows 11 il form non parte e usi MSComm, verifica:
✅ MSCOMM32.OCX presente in C:\Windows\SysWOW64\
✅ registrato con C:\Windows\SysWOW64\regsvr32.exe
✅ progetto compilato in x86 (non AnyCPU/64)
✅ Clean + Rebuild dopo la modifica
Conclusione
Quando un progetto WinForms “si rompe” passando da Windows 10 a Windows 11, spesso non è colpa del codice: è un problema di compatibilità e architettura legato a componenti legacy come MSComm.
La combinazione vincente è:
- registrazione corretta dell’OCX
- build in x86
E l’app torna a vivere.
Se vuoi, posso anche prepararti una sezione “Troubleshooting” con gli errori più comuni (Class not registered, License, wrapper Interop mancanti) da aggiungere in fondo all’articolo.