Hallo zusammen,
Bisher lief bei uns BosMon eigentlich immer extrem reibungslos auf einem Windows Server 2016.
Soundkarte ist integriert und darüber wird analoger Funk ausgewertet.
Nachdem heute keine Alarme funktioniert haben, wollte ich in BosMon schauen was los ist. Das Programm ist eingefroren und zwei Popups wurden angezeigt. Ein "GDI" Fehler und einmal System Out Of Memory. Wir haben einen Fujitsu Server, daher sollte RAM genügend da sein.
Jemand ne Idee woran es liegen kann? Das System lief Wochen oder vlt Monate ohne Neustart.
Gibt es Log Dateien wo man schauen könnte?
Bin leider in der Thematik nicht viel drin da es bisher immer einfach lief.
Danke
Simon
GDI und OutOfMemory Fehler verursacht BosMon Absturz
Re: GDI und OutOfMemory Fehler verursacht BosMon Absturz
Hallo,
ich konnte diesen Fehler schon einmal beobachten, dazu muss folgendes zusammenkommen:
- seeeehr lange Laufzeit des Programms
- Telegrammfenster vorhanden
- Spalte "Typ" (also die Typ-Bilderchen) ist eingeblendet
Für mich sieht es nach einem Bug im .Net-Framework aus. Lösung bisher: die Spalte Typ ausblenden oder BosMon so 1x im Monat neu starten.
Grüße
Thimo Eichstädt
ich konnte diesen Fehler schon einmal beobachten, dazu muss folgendes zusammenkommen:
- seeeehr lange Laufzeit des Programms
- Telegrammfenster vorhanden
- Spalte "Typ" (also die Typ-Bilderchen) ist eingeblendet
Für mich sieht es nach einem Bug im .Net-Framework aus. Lösung bisher: die Spalte Typ ausblenden oder BosMon so 1x im Monat neu starten.
Grüße
Thimo Eichstädt
-
alamos_gmbh
Re: GDI und OutOfMemory Fehler verursacht BosMon Absturz
Fatale Erweiterung zu diesem Problem:
Der Absturz war genau zum Zeitpunkt des Probealarms. Die gingen natürlich alle nicht an FE2 weiter. Damit kann ich leben.
Problem: durch "killen" des Programms (oder eventuell drucken der Fehlerboxen, oder durch anschließenden Neustart von BosMon) wurden auf einmal alle in der Pipeline stehenden Netzwerk Ereignisse an FE2 verteilt. Waren vermutlich so 50 Alarme.
FE2 hat dann korrekt reagiert und alle Alarme ausgelöst. Dadurch, daß ich bosmon erst knapp ne halbe Stunde nach probealarm neugestartet hab, haben alle Probealarm Regeln in FE2 logischerweise nicht mehr gegriffen und der vermeintliche Probealarm ging als realer Alarm an dutzende Feuerwehren und hunderte Mitglieder raus.
Puffer BosMon eventuell Netzwerkereignisse?
Alle drei deiner Punkte kann ich bestätigen. Kann es sein, daß die Bilder im Laufe der Zeit zu viele GDIs belegen und der Vorrat erschöpft ist? Ist zumindest bei Java SWT irgendwann so. Eventuell müsstest du die Anzahl der Elemente im Telegram Fenster begrenzen bzw die beim scrollen dynamisch nachladen
Der Absturz war genau zum Zeitpunkt des Probealarms. Die gingen natürlich alle nicht an FE2 weiter. Damit kann ich leben.
Problem: durch "killen" des Programms (oder eventuell drucken der Fehlerboxen, oder durch anschließenden Neustart von BosMon) wurden auf einmal alle in der Pipeline stehenden Netzwerk Ereignisse an FE2 verteilt. Waren vermutlich so 50 Alarme.
FE2 hat dann korrekt reagiert und alle Alarme ausgelöst. Dadurch, daß ich bosmon erst knapp ne halbe Stunde nach probealarm neugestartet hab, haben alle Probealarm Regeln in FE2 logischerweise nicht mehr gegriffen und der vermeintliche Probealarm ging als realer Alarm an dutzende Feuerwehren und hunderte Mitglieder raus.
Puffer BosMon eventuell Netzwerkereignisse?
Alle drei deiner Punkte kann ich bestätigen. Kann es sein, daß die Bilder im Laufe der Zeit zu viele GDIs belegen und der Vorrat erschöpft ist? Ist zumindest bei Java SWT irgendwann so. Eventuell müsstest du die Anzahl der Elemente im Telegram Fenster begrenzen bzw die beim scrollen dynamisch nachladen
-
alamos_gmbh
Re: GDI und OutOfMemory Fehler verursacht BosMon Absturz
Nachtrag:
In den Telegrammereignissen kommt kein Zeitstempel mit (zumindest im einfachen Modus). Wäre es möglich, den Versand Timestamp zu integrieren? Dann könnte man beim Empfang prüfen, ob der Alarm neu (und zum Beispiel nicht X Minuten zu spät) kommt?
In den Telegrammereignissen kommt kein Zeitstempel mit (zumindest im einfachen Modus). Wäre es möglich, den Versand Timestamp zu integrieren? Dann könnte man beim Empfang prüfen, ob der Alarm neu (und zum Beispiel nicht X Minuten zu spät) kommt?