WinForm Application stop running and freeze windows - winforms

Question

I'm new to Windows development.
I've developed a WinForm application that communicate with a serial device and plot data on a chart.
The application should run 24h a day 7/7. The code is executed correctly, but after some hours of execution the UI freeze with a non responsive OS (I have to turn off the pc and restart it).
Serial class (using System.IO.Ports) execute read and write operations on separate thread.
This scenario make me think to a non correct cross-thread call from my serial class to UI. Reading Microsoft documentation and other questions i think i fixed the error but no way, the app continue to freeze the OS.
Write operation send a request character every 100ms to the board via serial, i'm using System.Threading.Timer to do that cause this operation will not interact with UI.
//Initialization
WriteTimer = new Timer(Write, COMport.IsOpen, 5000, 100);
// callback function
public static void Write(object state)
{
if ((bool) state)
{
try
{
COMport.Write("^");
}
catch (Exception exc)
{
ErrorLogger.WriteTxtLog(DateTime.Now,exc.ToString());
}
}
}
The serial board reply to the request char with a string of 10 bytes, to read the message I'm using the DataReceived event handler form IO.Ports, that is also execute on a separated thread, the received data will be elaborated and than passed to UI with a event handler delegate with args declared on the main form class. I pass the form control to the serial class to make a safe thread call.
// FormControl is passed in the constructor of the serial class:
public Form1 FormControl;
private void COMport_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
SerialPort port = (SerialPort) sender;
byte[] buffer = new byte[10];
try
{
for (int i = 0; i < buffer.Length && buffer[i]!=3 ; i++)
{
buffer[i] = (byte) port.ReadByte();
}
SerialDataArgs args = checkDataReceived(buffer);
if (!args.error)
{
FormControl.Invoke(FormControl.drItem, new SerialDataArgs(...));
}
else
{
FormControl.Invoke(FormControl.drItem, new SerialDataArgs(0,0,true));
ErrorLogger.WriteTxtLog(DateTime.Now, "");
}
}
catch (Exception exc)
{
ErrorLogger.WriteTxtLog(DateTime.Now, exc.ToString());
}
}
UI thread (Form1 class):
SerialClass Serial = null;
public delegate void DataReceived(SerialDataArgs args);
public DataReceived drItem;
void ConnectCOM()
{
// COM READ
if (Serial == null)
{
Serial = new SerialClass(param.comName, this //this should be the FORM CONTROL);
if (Serial.Open)
{
...
drItem += HandleSeriaData;
}
else
{
...
}
}
}
//EventHandler
private void HandleSeriaData(SerialDataArgs args)
{
if (!args.error)
{
Work(args...); // in the work method i'll update labels, drawGraph,....
}
else
{
if (!Serial.Open) RecoverySerial();
}
}
Maybe the error is not here, but in front of Windows crashing it seems to me the only interested part. Sorry for my bad English, hope I made a correct/non duplicate question.

Answer 1

Use Control.BeginInvoke instead of Control.Invoke
From my experience, usually problems with System.IO.Ports.SerialPort cause only the UI to freeze, not the OS, and are caused by a deadlock when trying to update the UI from the SerialPort .DataReceived event using Control.Invoke and the UI thread itself tries to access the SerialPort object for example to close it. In this case there can be a deadlock when the UI thread is waiting for the SerialPort DataReceived thread to complete and the DataReceived thread is waiting for the UI thread to complete the Control.Invoke. To overcome these kinds of problems, it is better to use Control.BeginInvoke so the DataReceived thread does not wait for the UI thread.
Use lock to synchronize access to shared resources
When accessing the same object from different threads, use lock to synchronize data access. None synchronized data access can cause all different weird problems.
Check if the problem is with the serial port driver or connection
When the UI freezes and the OS becomes unresponsive, try to remove the serial-port device and see if the OS becomes responsive. If so, the problem may not be in the application but in the serial port driver or connection.
Hope this helps