Chiamare SerialPort.Close() frequentemente è un errore. Avere un'altra app che ti ruba la porta non è esattamente molto desiderabile. Ma più problematico, e il problema che stai riscontrando, è che Close() non attende l'uscita di un thread di lavoro avviato da SerialPort. Quel thread di lavoro genera gli eventi DataReceived, PinChanged ed ErrorReceived. Ci vuole "un po' di tempo" per uscire, potrebbe essere compreso tra millisecondi e secondi. La chiamata di nuovo a Open() fallirà fino a quando non sarà completata.
È un difetto nella classe, ma indotto dall'uso comune delle porte seriali. Le app normalmente non le chiudono fino al termine dell'app. Compreso mai, evitando uno scenario di deadlock comune. Tieni presente che l'articolo MSDN per Chiudi avverte di questo:
Se sei preoccupato per l'apertura/chiusura e altre app che rubano la porta COM, puoi utilizzare l'approccio utilizzato da Microsoft per il driver intermedio GPS in Windows embedded, ovvero per scrivere un aggregatore, uno che apra la porta, la mantenga apri, quindi fornisce punti di connessione per la connessione di altre app.
Il modo in cui crei le connessioni dipende da te:puoi approfondire l'hardware e scrivere un driver della porta COM virtuale condivisibile, oppure puoi fare quello che ho fatto e scrivere un semplice servizio socket win32 che consenta ai programmi client di connettersi tramite normali connessioni socket di Windows.
Forse non una risposta diretta, ma spunto di riflessione.