Anwendung friert ein beim schließen

[Andreas L. (andreas_l441)]

Hallo,
ich habe das Problem, dass wenn ich in meiner Anwendung einen SerialPort 
erstelle und darüber Daten einlese und anschließend das Fenster 
schließe, das Programm hängen bleibt. Es lässt sich dann nur über den 
Taskmanager schließen. Anschließend kommt folgender Fehler:

"Ein Ausnahmefehler des Typs "System.ObjectDisposedException" ist in 
System.Windows.Forms.dll aufgetreten."

Das tritt nur auf, wenn der Port einmal offen ist.
Achja, ich arbeite mit Visual C#. Hier noch der Code, leider ein 
bisschen unübersichtlich:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;
using System.IO.Ports;
using CommandsPD4I;

namespace CSharpExample
{
    public partial class CSharpExample : Form
    {
        public ComMotorCommands motor1;
        
        int aktuellePosition = 0;
        int kraft = 0;
        int kraftOffset = 0;
        int maxKraft = 600;
        int modusValue = 0;
        int ose = 0;
        int originalKraft = 0;
        int startpos = 0;
        int use = 6000;
        int zyklenAnzahl = 1;
        int zyklusCount = 0;
        bool zyklusLaeuft = false;

        public CSharpExample()
        {
            InitializeComponent();
            motor1 = new ComMotorCommands();

            //Comboboxen befüllen 
            foreach (var item in SerialPort.GetPortNames())  
            {
                cbArduinoConnect.Items.Add(item);
                cbMotorConnect.Items.Add(item);
            }
            cbArduinoConnect.Text = cbArduinoConnect.Items[0].ToString();
            cbMotorConnect.Text = cbArduinoConnect.Items[0].ToString();
        }

        delegate void InvokeLB(string Data);
        InvokeLB lbRecievedDelegate;

        private void btnArduinoVerbinden_Click(object sender, EventArgs e)
        {
            arduino.PortName = cbArduinoConnect.Text;
            arduino.Open();
            if (arduino.IsOpen)
            {
                lblArduinoConnectStatus.ForeColor = System.Drawing.Color.FromArgb(((int)(((byte)(0)))), ((int)(((byte)(200)))), ((int)(((byte)(0)))));
                lblArduinoConnectStatus.Text = "Arduino verbunden mit " + arduino.PortName;
            }
            lbRecievedDelegate = new InvokeLB(InvokeLBRecieved);
            arduino.DataReceived += new SerialDataReceivedEventHandler(arduino_DataReceived); //DataRecieved Event abonnieren
        }

        private void arduino_DataReceived(object sender, SerialDataReceivedEventArgs e)
        {
            string RecievedLine = " ";
            while (RecievedLine != "")
            {
                RecievedLine = arduino.ReadLine();
                lblKraft.Invoke(lbRecievedDelegate, new object[] { RecievedLine });
            }
        } 

        void InvokeLBRecieved(string Data)
        {
            string origKraft = Data;
            Int32.TryParse(origKraft, out originalKraft);
            toolStripStatusLabelKraft.Text = Convert.ToString(originalKraft - kraftOffset);
            kraft = originalKraft - kraftOffset;
            if (kraft >= maxKraft && cbZyklenmodi.Text == "Max. Kraft [N]:" && zyklusLaeuft)
            {
                motor1.StopTravelProfile();
                motor1.SetPositionType(2);
                motor1.SetSteps(startpos);
                motor1.SetMaxFrequency(1000);
                motor1.StartTravelProfile();
                zyklusLaeuft = false;
            }
        }

        private void handsteuerungOeffnen(object sender, EventArgs e)
        {
            Handsteuerung handsteuerung = new Handsteuerung(motor1);
            handsteuerung.Show();
        }

        private void motorVerbinden(object sender, EventArgs e)
        {
            //Motoreinstellungen
            motor1.SelectedPort = cbMotorConnect.Text;
            motor1.Baudrate = 115200;
            motor1.MotorAddresse = 1;
            if (motor1.ErrorFlag)
            {
                lblMotorConnectStatus.Text = motor1.ErrorMessageString;
            }
            else
            {
                lblMotorConnectStatus.ForeColor = System.Drawing.Color.FromArgb(((int)(((byte)(0)))), ((int)(((byte)(200)))), ((int)(((byte)(0)))));
                lblMotorConnectStatus.Text = "Motor verbunden mit " + motor1.SelectedPort;
                timer.Enabled = true;
                toolStripStatusLabelPos.Text = Convert.ToString(motor1.GetPosition());
            }
        }

        private void timer_Tick(object sender, EventArgs e)
        {
            aktuellePosition = motor1.GetPosition();
            toolStripStatusLabelPos.Text = Convert.ToString(motor1.GetPosition());
            lblZyklusCount.Text = Convert.ToString(zyklusCount);
            chart1.Series["Kraft"].Points.AddXY(aktuellePosition, kraft);
            if (aktuellePosition == startpos)
            {
                if (zyklusCount > 0 && zyklusCount < zyklenAnzahl)
                {
                    startZyklus();
                }
                else if (zyklusCount == zyklenAnzahl)
                {
                    zyklusCount = 0;
                }
            }
            if (aktuellePosition == modusValue && cbZyklenmodi.Text == "Position:" && zyklusLaeuft)
            {
                motor1.SetPositionType(2);
                motor1.SetSteps(startpos);
                motor1.SetMaxFrequency(1000);
                motor1.StartTravelProfile();
                zyklusLaeuft = false;
            }
        }

        private void toolStripBtnStartposUebernehmen_Click(object sender, EventArgs e)
        {
            startpos = motor1.GetPosition();
        }

        private void toolStripBtnStartPos_Click(object sender, EventArgs e)
        {
            motor1.SetSteps(startpos);
            motor1.SetMaxFrequency(1000);
            motor1.SetPositionType(2);
            motor1.StartTravelProfile();
        }

        private void toolStripBtnStop_Click(object sender, EventArgs e)
        {
            motor1.StopTravelProfile();
            chart1.Series["Kraft"].Points.Clear();
            zyklusCount = 0;
        }

        private void toolStripBtnZurueck_Click(object sender, EventArgs e)
        {
            motor1.SetMaxFrequency(1000);
            motor1.SetDirection(0);
            motor1.SetPositionType(4);
            motor1.StartTravelProfile();
        }

        private void btnUebernehmen_Click(object sender, EventArgs e)
        {
            if (Int32.TryParse(tbOSE.Text, out ose)           && Int32.TryParse(tbUSE.Text, out use) && 
                Int32.TryParse(tbModus.Text, out maxKraft)    && Int32.TryParse(tbZyklenAnzahl.Text, out zyklenAnzahl) &&
                Int32.TryParse(tbModus.Text, out modusValue))
            {
                MessageBox.Show("Werte wurden übernommen!");
            }
            else
            {
                MessageBox.Show("Fehler!");
            }  
        }

        private void toolStripBtnKraft_0_Click(object sender, EventArgs e)
        {
            kraftOffset = originalKraft;
        }

        private void toolStripBtnStart_Click(object sender, EventArgs e)
        {
            startZyklus();
        }

        private void startZyklus()
        {
            motor1.SetMaxFrequency(100);
            motor1.SetDirection(1);
            if (cbZyklenmodi.Text == "Max. Kraft [N]:")
            {
                motor1.SetPositionType(5);
            }
            else if (cbZyklenmodi.Text == "Position:")
            {
                motor1.SetPositionType(2);

                int modus;
                if (Int32.TryParse(tbModus.Text, out modus))
                {
                    motor1.SetSteps(modus);
                }
                else
                {
                    MessageBox.Show("Falsche Eingabe!");
                }
                
            }
            motor1.StartTravelProfile();
            zyklusLaeuft = true;
            chart1.Enabled = true;
            zyklusCount++;
        }

        private void beendenToolStripMenuItem_Click(object sender, EventArgs e)
        {
            this.Close();
        }

        
    }
}

[Rufus Τ. F. (rufus)]

Wusstest Du, daß das Visual Studio, das Du zum Erstellen Deines 
C#-Programmes verwendest, auch einen Debugger enthält?

[Karl H. (kbuchegg)]

Andreas L. schrieb:

> "Ein Ausnahmefehler des Typs "System.ObjectDisposedException" ist in
> System.Windows.Forms.dll aufgetreten."
>
> Das tritt nur auf, wenn der Port einmal offen ist.


Da würde ich doch glatt als Arbeitshypothese annehmen, dass an der 
Reihenfolge beim Aufräumen etwas nicht stimmt.

Meine Arbeitshypothese wäre, dass versucht wird einen Eventhandler (das 
Port Objekt drängt sich da förmlich auf) für ein Objekt aufzurufen, das 
schon zerstört wurde.


Das ist halt die Krux in einer Sprache mit Garbage Collection. Man macht 
sich keinerlei Gedanken mehr darüber, dass irgendwer auch hinter einem 
aufräumen muss und das es dafür oft sinnvolle Reihenfolgen gibt.

[c-hater (Gast)]

Karl H. schrieb:

> Da würde ich doch glatt als Arbeitshypothese annehmen, dass an der
> Reihenfolge beim Aufräumen etwas nicht stimmt.

So ist es höchstwahrscheinlich auch. Allerdings anders, als du denkst...

> Meine Arbeitshypothese wäre, dass versucht wird einen Eventhandler (das
> Port Objekt drängt sich da förmlich auf) für ein Objekt aufzurufen, das
> schon zerstört wurde.

Das könnte eigentlich nicht passieren, weil der Handler ja nur in 
einer vom lebenden Objekt selber ausgelösten Ereignisbehandlung 
aufgerufen wird.

Das "eigentlich" ist aber genau der springende Punkt. Der Code von 
System.IO.Ports.Serialport ist leider ganz allgemein katastrophal mies, 
insbesondere ist er aber nicht vollständig threadsicher. Die 
Winzigweich-Spacken haben in der Geschichte von .Net obendrein mehrfach 
unsachgerecht dran rumgefrickelt, um die schlimmsten Probleme zu 
"beheben", so daß eine Anleitung zur Behebung des Problems die genaue 
Versionsangabe des verwendeten Frameworks erfordert, denn der Workaround 
muß an die jeweils aktuellen Winzigweich-Fehler angepaßt sein...

Übrigens: Wenn es sich bei dem verwendeten Port um einen virtuelle Port 
handelt (z.B. USB), multiplizieren sich die Probleme noch einmal. So ein 
Ding kann nämlich auch mal einfach so verschwinden (z.B. wenn jemand den 
Stecker zieht). Bis .Net 4 warf der Winzigweich-Müll in diesem Fall eine 
"uncatchable" Exception, d.h.: die Anwendung stürzte unrettbar ab und es 
gab kein Mittel, um das zu verhindern. Bei .Net 4 haben dann die 
Winzigweich-Spacken mal wieder eins ihrer tollen Bugfixes gemacht, was 
dazu führt, daß es zwar nicht mehr zu diesem Super-GAU kommt, aber dafür 
die Anwendung im Wald steht, auch wenn der COM-Port wieder "da" ist. 
Schlicht und einfach deshalb, weil sie nunmehr garnicht mehr bemerken 
kann, daß er mal "weg" war...

Superpeinlich, weil man ja mittlerweile die .Net-Quelltexte auch als 
Normalsterblicher problemlos einsehen kann...

Nö, den Trouble will man sich auf Dauer nicht antun. Es gibt mehrere 
SerialPort-Klassen von 3rd-Party-Anbietern, die zeigen, wie man sowas 
richtig umsetzt. Die setzen genauso wie MS auf's WinAPI auf, machen das 
aber im Gegensatz zu MS einfach mal nur richtig.

Ich persönlich benutze allerdings meine eigene Klasse, die schon zu 
.Net1.1-Zeiten entstanden ist, damals noch nicht deswegen, weil die 
MS-Umsetzung so furchtbar verbugged war, sondern deshalb, weil es vor 
.Net2.0 die Serialport-Klasse überhaupt noch nicht gab. Das hat 
allerdings auch die Folge, daß meine ein völlig davon abweichendes 
"Interface" hat.

Auf die o.g. 3rd-Party-Klassen trifft das nicht zu. Die sind 
(offensichtlich nach .Net2.0) mit dem Ziel entwickelt worden, möglichst 
kompatibel zum obermiesen "Original" zu sein, aber dessen abstruse 
Fehler zu vermeiden.

> Das ist halt die Krux in einer Sprache mit Garbage Collection.

Die taucht zwar in einigen KB-Artikeln in diesem Zshg. auf, hat aber de 
facto mit den SerialPort-Problemen rein garnix zu schaffen. Die Existenz 
dieser KB-Artikel zeigt eigentlich nur sehr deutlich, wie sehr die 
"Entwickler" bei MS eigentlich im Nebel des unverstandenen Codes 
stochern. Und diese Typen dürfen garantiert den gesamten .Net-Code 
(incl. Marshalling!!!) einsehen und wahrscheinlich auch wesentlich mehr 
Code des Win-API, als er mir und den anderen 3rd-Parties zur Verfügung 
steht...

Wahrscheinlich irgendwelche billigen Inder, die nur C# können...

MS muß sich wohl derzeit auf so grundlegende Probleme wie die 
Entwicklung von "gekachelten" Benutzeroberflächen konzentrieren. Da 
bleibt für Randprobleme wie funktionierenden Basiscode wohl echt wenig 
Zeit...

[Matthias L. (Gast)]

c-hater schrieb:
> MS muß sich wohl derzeit auf so grundlegende Probleme wie die
> Entwicklung von "gekachelten" Benutzeroberflächen konzentrieren. Da
> bleibt für Randprobleme wie funktionierenden Basiscode wohl echt wenig
> Zeit...

Leider scheint das auch für Googles android zu gelten...

[Andreas L. (andreas_l441)]

Hmm.. habt ihr eine Idee wie ich das Problem lösen könnte?
Ich weiß leider garnicht so genau, was Eventhandler sind.. Den Code zum 
Daten empfangen über den SerialPort habe ich aus dem Netz übernommen.
Wenn da das Problem liegt wüsste ich nicht so genau wie das zu 
verhindern ist.

[Noch einer (Gast)]

Ach - halb so wild. Verstehst ja inzwischen schon einiges - kannst ja 
die Klasse in dein Programm einbauen. In den Debugger einarbeiten und 
Tutorials für solche Konzepte durcharbeiten ist auch nicht mehr der 
große Aufwand.

Wenn wir hier im Nebel stochern und du alle Tipps ausprobierst - das 
dauert länger.

[Karl H. (kbuchegg)]

c-hater schrieb:

> facto mit den SerialPort-Problemen rein garnix zu schaffen.

Danke für die Aufklärung. Ich bin in der glücklichen Lage, das .Net 
Geraffel links liegen lassen zu können. Ja, ich weiss: ich manövriere 
mich damit selbst ein wenig ins Abseits.
Mein einziger Ausflug zu C# (Pflege eines existierenden Programms) hat 
mir allerdings auch gezeigt, das Garbage Collection auch nicht der 
Wunderwuzzi ist, als der es so gerne angepriesen wird. Drum bin ich da 
ein bischen 'vorbelastet'.

Wundert mich aber eigentlich. Das Serial Objekt hat in VB6.0 meinere 
Erinnerung nach eigentlich recht gut funktioniert.

> Bis .Net 4 warf der Winzigweich-Müll in diesem Fall eine
> "uncatchable" Exception, d.h.: die Anwendung stürzte unrettbar ab
> und es gab kein Mittel, um das zu verhindern.

Das erinnert mich irgendwie an die Fehlermeldung, die im seligen DOS vom 
Treiber direkt ausgegeben wurde, wenn man eine Diskette während eines 
Zugriffs aus dem Laufwerk rausnahm. Das war besonders bei 
Graphikprogrammen recht 'interessant', wenn dann irgendwo am Monitor ein 
paar Pixelhaufen auftauchten.

Die lernens einfach nicht.

> MS muß sich wohl derzeit auf so grundlegende Probleme wie die
> Entwicklung von "gekachelten" Benutzeroberflächen konzentrieren. Da
> bleibt für Randprobleme wie funktionierenden Basiscode wohl echt wenig
> Zeit...

Da sind wir einer Meinung.
D.h. fast. Ich war ja viele Jahre lang der Meinung, das MS nach dem 
Motto vorgeht: Was Excel nicht braucht, braucht auch sonst keiner.

[Jim M. (turboj)]

Andreas L. schrieb:
> Hmm.. habt ihr eine Idee wie ich das Problem lösen könnte?

Gar nicht. Man stellt das Projekt auf WinUSB um, dabei wird man die 
ganzen Probleme mit den COM Ports auf einmal los. Diese Krücke hat in 
moderner Software nichts mehr zu suchen.

Der WinUSB Treiber kann ab Windoof 8.1 automagsich installiert werden, 
wenn das USB Gerät korrekt programmiert wurde. Siehe auch:
https://github.com/pbatard/libwdi/wiki/WCID-Devices

[Rufus Τ. F. (rufus)]

Und mit WinUSB kommunizierst Du mit Geräten, die z.B. eine 
USB-Seriell-Bridge von FTDI, SiLabs oder Prolific haben?

[Borislav B. (boris_b)]

Wie wäre es denn, wenn du vor dem Schließen der Form erst mal die Timer 
stoppst, ggf. Threads beendest und deinen Port ordentlich schließt?

[Peter II (Gast)]

Jim M. schrieb:
> Gar nicht. Man stellt das Projekt auf WinUSB um, dabei wird man die
> ganzen Probleme mit den COM Ports auf einmal los. Diese Krücke hat in
> moderner Software nichts mehr zu suchen.

und warum nicht? So ziemlich jede andere Anwendung bekommst es ja auch 
hin, also wird das Problem wohl nicht grundsätzlicher Natur sein.

Die COM port haben eine definierte API mit Timeout Events uä. Das biete 
WinUSB nicht an, das muss man dann alles selber passend zur Hardware 
implementieren.

[Peter II (Gast)]

Boris P. schrieb:
> Wie wäre es denn, wenn du vor dem Schließen der Form erst mal die Timer
> stoppst, ggf. Threads beendest und deinen Port ordentlich schließt?

ich glaube mich zu erinnern, das eine C# Anwendung sich nicht beendet 
wenn noch ein Thread aktiv ist. Kann also sehr gut sein.

[Andreas L. (andreas_l441)]

Ich habe schon versucht den Port zu schließen bevor er beendet.
Jedoch sieht es so aus, als würde er immer noch den DataReceived 
Eventhandler aufrufen, da immernoch Daten eintreffen.
Wie verhindere ich das?

[Andreas L. (andreas_l441)]

Habe es jetzt gelöst:
Das "einfrieren" der Anwendung konnte ich verhindern, indem ich Tipp 3 
von hier befolgt habe:

http://blogs.msdn.com/b/bclteam/archive/2006/10/10/top-5-serialport-tips-_5b00_kim-hamilton_5d00_.aspx

Danach kamen trotzdem noch zwei weitere Exceptions, die ich dann 
abgefangen habe:

try
                {
                    RecievedLine = arduino.ReadLine();
                }
                catch (System.IO.IOException)
                {
                    return;
                }
                catch (System.InvalidOperationException)
                {
                    return;
                }

[bluppdidupp (Gast)]

ReadLine in DataReceived ist schonmal falsch, wenn dann ReadExisting 
dort nutzen.
Wenn DataReceived ausgelöst wird, aber noch gar keine vollständige Zeile 
angekommen ist, wird ReadLine im Event-Handler hängen bleiben.

Ich würde einfach einen BackgroundWorker nutzen, dort den Port öffnen 
und dort normal ReadLine() nutzen und auf DataReceived ganz verzichten.
BackgroundWorker sind als Hintergrund-Threads markiert und werden 
automatisch gekillt:
[code]Background threads are identical to foreground threads with one 
exception: a background thread does not keep the managed execution 
environment running. Once all foreground threads have been stopped in a 
managed process (where the .exe file is a managed assembly), the system 
stops all background threads and shuts down.[/quote]
https://msdn.microsoft.com/en-us/library/h339syd0(v=vs.110).aspx