Anwendung überwachen

Hallo,

Ich habe eine Anwendung für automatisierte Testabläufe. Die halt fleißig mehrere 1000 Test über Tage hinweg "durchrattert".

Es kann halt mal vorkommen das es einen Fehler/Exception oder Absturz gibt. Durch die vielen Threads ist es halt sehr schwierig inzwischen das dann zu beheben.

Deshalb möchte ich ein extra Überwacherprogramm schreiben, was zyklisch vom Testprogramm Meldungen erält ob es noch aktiv ist. Wenn das ausbleibt, soll es das Testprogramm beenden/killen. Dann aber neu starten und ab dem Testfall fortsetzen wo es hängen geblieben war.

Ich ware dankbar für ein paar Tipps wie man so was am besten umsetzt. Habe damit keine Erfahrung wie die beiden Programmen miteinander kommunizieren sollen (Windows Messages?) und wie ich vom Testprgramm die Einstellungen des Users in der GUI abspeicher damit der Überwacher das dann verwenden kann.

Weihnachtliche Grüße!

Ob ein Programm noch reagiert kannst du mit Process.Responding herausfinden. Sollte die Oberfläche nicht auf Benutzereingaben reagieren liefert es false. Wenn keine Oberfläche vorhanden ist liefert es immer true. Also geht es nur mit einem GUI. Beenden kannst du den Prozess dann einfach mit Process.Kill und starten mit Process.Start.

Hallo snowy,

da du ja wohl beide Anwendungen selber schreibst, steht dir dir volle Bandbreite der Interprozesskommunikation (IPC) zur Verfügung. Windows Message kannst du natürlich nehmen, aber weil Windows-Messages schicken auch ein beliebtes Angriffsszenario ist, ist es vielleicht auch nicht ganz so zukunftssicher. Eine Semaphore (im Sinne von WaitHandle) mit Timeout wäre sicher eine der einfachsten Möglichkeiten.

herbivore

Danke erstmal für die Infos.

@Corpsegrinder:
Mittels "Process.Responding" wäre es sicher am einfachsten herauszufinden ob das Testprogramm noch lebt. Der Nachteil wäre halt ich weiß nicht bis zu welchem Testfall er gekommen ist.

@herbivore:

aber weil Windows-Messages schicken auch ein beliebtes Angriffsszenario ist, ist es vielleicht auch nicht ganz so zukunftssicher

Wie genau meinst Du das? Angriffen von Hackern..? Das bräuchte ich nicht berücksichtigen, da der Rechner nicht am Netz ist.

Kann ich bei einer Windowsmessage ein Objet mitsenden, das dann immer den aktuellen Testfall enthalten würde.Dann wüsste ich wo das Programm stehen geblieben ist, falls keine Meldung mehr zyklisch an den Überwacher kommt.

[DllImport("user32.dll", CharSet=CharSet.Auto, SetLastError=true)]
public static extern int SendMessage(IntPtr hwnd, [MarshalAs(UnmanagedType.U4)] int Msg, IntPtr wParam, IntPtr lParam);

Mit Semaphoren usw. habe ich noch nicht gearbeitet. Über Windowsmessages scheint mir erstmal der leichteste Weg zu sein 😃

Hallo snowy,

Wie genau meinst Du das?

ich meine, dass ich mir vorstellen kann, dass zukünftige Windows Versionen das anwendungsübergreifende Versenden von Nachrichten be- oder verhindern.

herbivore

Ich habe mir mal einen Ablauf überlegt. Vielleicht habt Ihr Verbesserungsvorschläge.

1.Testprogramm starten
2.Nutzer stellt Einstellung ein
3.Teststart
3.1 GUI Einstellungen serialisieren (XML-File). Dazu Klasse schreiben die alle Einstellungen aufnehmen kann.
3.2. Diagnose startet Überwachungsprozess (ÜP)
4. ÜP wartet auf die zyklischen Messages vom Testprogramm. Diese enthalten immer den aktuellen Testfall als Objekt/Struktur (Wo ich nicht weiß ob das geht..)
5. Falls die Message ausbleibt -> Test wahrscheinlich abgestürzt. Mittels Prozess.Repsonding nochmals prüfen.
6. Prozess killen und Testprogramm neu starten. Warten bis es geladen ist.
7. Spezifische Botschaft (spezielle ID) an Testprogramm schicken. Anhand der ID weiß Testprogramm ich bin abgestürztz. Ereignise auslösen und XML-File deserialisieren und GUI einstellen und Test starten.

Keine Window-Messages... Wie herbivore bereits geschrieben hat ist das nicht zukunftssicher udn ausserdem gibt es bessere Mittel 😃. Ich habe dir hier mal ein kleines Tutorial gesucht: http://www.codeguru.com/csharp/csharp/cs_syntax/remoting/article.php/c9251/

Das sollte eigentlich reichen, um deine Anwendungen kommunizieren zu lassen.

Hallo,

Ich sehe das nicht so.
Microsoft wird vielleicht in Zukunft System Messages wie WM_Click blockieren, allerdings sicher nicht extra für diesen Zweck (IPC) geschaffene Nachrichten wie WM_COPYDATA oder WM_APP.
Abgesehen davon lassen sich mit der WM_COPYDATA-Nachricht sehr einfach Benachrichtigungen und auch .Net Objekte verschicken. Sollte es nur darum gehen einfache Nachrichten (Ping, Statusinformationen) auszutauschen, würde ich viel eher Windows-Messages als .Net Remoting verwenden.

Hallo marsgk,

das alle Nachrichten pauschal und unüberwindlich geblockt werden, halte auch ich für unwahrscheinlich. Aber was genau passieren wird, kann man nicht vorhersagen. Daher ist das ganze zwar nichts "zukunftsunmöglich", aber eben "zukunftsunsicher". Mehr wollte ich ja nicht sagen.

herbivore

Hallo herbivore,

Bei Standard-Windows-Messages gebe ich dir Recht, hier würde es mich auch nicht wundern. Aber bei extra für IPC geschaffenen Windows-Messages - und diese würde der Threadersteller ja sinnvollerweise verwenden - mache ich mir keine Sorgen.
Genautogut könnte man .Net Remoting als "zukunftsunsicher" bezeichnen, da sich hier seit .Net 2.0 nichts mehr getan hat, obwohl es noch einige verbesserungswürdige Punkte gibt.

Hallo marsgk,

Aber bei extra für IPC geschaffenen Windows-Messages - und diese würde der Threadersteller ja sinnvollerweise verwenden - mache ich mir keine Sorgen.

wenn mein warnender Hinweis dazu führt, dass er das tatsächlich so macht, wäre das ja schon ein Gewinn gewesen.

herbivore

Danke erstmal für eure Informationen.

Wie ich es verstanden habe sollte ich also IPC-Channel bevorzugen (basierend auf Pipes).

Ich verstehe aber das Tutorial von "Corpsegrinder" noch nicht 100 pro:

Muss ich ein Projekt erstellen für den Server und eins für den Cient (also 2 Applikationen).
Was ist mit "Shared Assembly", also das Interface und "Shared Assembly Implementation", wo kommt das hin?

In meinem Falle sind ja beide Applikationen mal Client mal Server. Muss ich dann 2 Kanäle implementieren? Also einen channel pro Anwendung ?

Vielen Dank!

[Edit]
Mittels Pipes habe ich für .NEt 3.5 ein Beispiel gefunden:

http://dotnet-snippets.de/dns/c-interprozesskommunikation-ueber-benannte-pipes---server-SID1056.aspx

Es kann halt mal vorkommen das es einen Fehler/Exception oder Absturz gibt. Durch die vielen Threads ist es halt sehr schwierig inzwischen das dann zu beheben.

Ich bin ja kein catch all Freund aber für so einen Fall würde ich bevor ich mit IPC etc. anfange erstmal schauen das du diese Fehler gefangen bekommst, protokollierst das dieser Test fehlgeschlagen ist und dann evtl. noch mal startest.

Das könntest du wunderbar mit einer Queue machen wo sich dann "worker"-Threads ihre Testfälle rausholen. Der Thread führt das Ding in einem großen Try..catch aus und gibt im finally einen evtl. Fehlgeschlagenen Test wieder in die Queue zurück.

@jaensen: die Idee ist sicher gut. Aber es gibt noch andere Sachen die parallel zu den Testfällen laufen. Das ist eine komplette Simulationsumgebung für ein DUT.

Ich werd das schon mit dem Überwachprogramm machen, häng aber grad dran wie ich jeden Prozess als Client UND Server arbeiten lasse, also Vollduplex.