Laufzeitfehler beim Speicher wenn KEIN Projekt gestartet ist

[gwanjek]

Hallo,
folgender schwerer Laufzeitfehler:

Voraussetzung:
Kein Projekt aktuell gestartet, aber seit ca. 1-2 Std. am Editieren in Makros / zwischenspeichern, wechseln (Laden) in andere Projekte, um von dort per Copy/Paste Teile zu übernehmen...

Plötzlich (kurz nach Speicher-Vorgang, der nach einigen Minuten Pause zur vorherigen Aktivität ausgeführt wird): Laufzeitfehler-Meldungen, ca. im Sekundentakt:

(sinngemäß / abgeschrieben, denn MsgError-Dateien werden zwar angelegt, aber 0Byte lang):
Laufzeitfehler in Modul Definition bei Adresse 005A2BF2 .... TTimer ... Lesen v. Adresse B4E9030C

Mehrere weitere Fehler-Fenster (möglicherweise bei -vergeblichem- Versuch des Starts des Task-Managers per Rechtsklick auf leeren Bereich der Toolbar):
Runtime err 216 ... 00404CF6

Betriebssystem: Win2K-Server im aktuellen Patchlevel

FHZ 1300 PC WLAN

Studio-SW: Identischer Fehler je einmal unter Rel. 61210 als auch ca. einen Tag später unter Rel. 70107 (komplett neu installiert, vorher alte Rel per Win-Systemsteuerung/SW deinstalliert / *.ini-Dateien in WINNT-Verz. gelöscht / Registry-Einträge HKLM/Software/contronics gelöscht)

Beide Rel. funktionierten bis dahin anstandslos / auch mit der neuen Rel seit mehreren Stunden gearbeitet.

Weiteres Fehlerbild (beide Rel.) nach erneutem Start, selbst nach erneutem Rechnerstart nach Neuinstallation der neuen Rel:

In der Visualisierung kann anstandslos gearbeitet werden (Programmieren, Projekt starten, PC-seitige Aktionen im Projekt durchführen). Jedoch erfolgt offenbar keinerlei Funkkommunikation zu Aktoren/Sensoren. Die Studio-SW meldet den Client nach jedem Projektstart als normal angemeldet.

Erst nach Aufruf "Hardware-Schnittstelle / Client prüfen" kommt Meldung "Client nicht angemeldet" o.ä. und Client wird autom. abgemeldet. Löschen / neue Schnittstellendefinition auch ohne Erfolg.

Das Projekt selbst ist offenbar nicht die Ursache (Testprojekt mit einer Schaltsteckdose, einem UP-Schalter, einem Uhr-Objekt mit gleichem Effekt: Uhr läuft und Objekte schalten in Visualisierung / nichts schaltet real)

Vermutung, da ja offenbar Rel.- und Projektunabhängig: das WLAN-Modul. ABER: Das Modul ist ganz normal über WLAN und dessen Web-Schnittstelle erreichbar! Reset des Moduls per Web-Schnittstelle wird durchgeführt bringt aber KEIN Erfolg.

Positiv-Log der PC-Firewall zeigt, daß ganz normal Paket-Bursts gesendet werden vom FHZ-Modul, sobald die Studio-SW nicht gestartet ist / Bursts aufhören, sobald Studio-SW gestartet ist (offenbar Kommunikation erfolgt), Bursts sofort wieder einsetzen, sobald Studio-SW wieder aus ist.

Next Step der Fehlersuche: Anderer PC mit Studio-SW (Laptop mit XP): Gleiches Verhalten!!! (FHZ-Modul kann von da ebenfalls normal per Web erreicht werden, umkonfiguriert und resettet werden, aber gestartetes Projekt schaltet nicht / Client als angemeldet erkannt usw.)

Lösung: Power-On-Reset am FHZ-Modul. (Netzteil kurz ziehen) Danach geht alles wieder!

Also offenbar FHZ-Modul FS20-seitig aufgehängt gewesen / Folgefehler dann in der Studio-SW bei (erfolgloser) weiterer Kommunikation. WLAN- und webserverseitig ist es dabei weiter erreichbar und sogar resetbar (dauert auch kurzen Moment, bis wieder per Browser erreichbar, also offenbar wirklich Reset durchgeführt)

Die Studio-SW sollte aber dringend derartige Fehler abfangen, denn auffallenderweise traten beide Fehler
- bei Speicher-Versuchen des Projektes auf,
- während kein Projekt aktiv lief
- nach mehreren Minuten Inaktivität bei gestarteter Studio-SW

Im ersten Fehlerfall führte das zum Totalverlust der Projektdatei! Rel. 61210 kannte ja leider noch keine SPB-Dateien. Ausgerechnet beim Speichern sind derartige Fehler natürlich tödlich!

Der zweite Fehler trat dann übrigens beim Restaurationsversuch des ehemaligen Projektstandes auf. Deshalb auch das stundenlange zusammen suchen / wechseln in andere Projektdateien. Schöne Grüße von McMurpy...

Ich will natürlich nicht ausschließen, daß mein FHZ-Modul doch ein Problem hat. Wenn, dann ist das aber 1. neu, 2. tritt nur auf bei eingeschaltetem Kommunikationspartner-PC OHNE das dort ein Projekt läuft (PC mehr als Woche aus / FHZ-Modul problemlos. 2 Tage vor dem Fehler durchgehend Projekt gestartet: FHZ-Modul problemlos.) Das FHZ-Modul lief vor dem Fehler problemlos mehrere Monate seit Kauf/Konfiguration durch.

Ich behaupte also mal als These, daß das FHZ-Modul intakt ist, aber das o.g. Verhalten ebenfalls schon ein FOLGEFEHLER ist, entstanden aus der vorherigen Kommunikation, bei der irgendein Stack vollief o.ä., ggf. verursacht durch ähnliche Paket-Fluten wie hier bereits beschrieben?

Gruß Gerd

[gwanjek]

Vielleicht hilft folgendes noch bei der Fehlereingrenzung:

Beim heutigen 2. Auftreten des Fehlers (Speichern bei Studio Rel 70107) ist folgendes aufgefallen:
Offenbar ist in der originalen Projektdatei alles ordnungsgemäß enthalten bis auf eins:

Ich hatte einen eigenen Objekttyp "HKklein" angelegt (="Heizkörper klein") mit den Zuständen "aus" und "an" (in dieser Reihenfolge) und den jeweils zugewiesenen Bitmaps aus BMP\Heizk_ka.bmp sowie BMP\Heizk_ke.bmp. Dazu existierten im Projekt 6 Objekte dieses Typs, die jeweils in 2 Ansichten verwendet, sowie aus Makros anderer Objekte gesetzt wurden (per "einschalten" / "ausschalten").

Nach dem Speichervorgang, der den oben beschriebenen Fehler zur Folge hatte, ist dieser Objekttyp als solcher im Projekt verschwunden. Alle Objekte dieses Typs sind nur noch vom Typ "Makro". Nach erneutem Anlegen der Typdefinition "HKklein" sind die Objekte anschließend wieder von diesem Typ (so sie nicht zwischenzeitlich selber gespeichert wurden).

Interessanterweise ist identisches Verhalten (HKklein als Typdefinition verschwunden / Objekte nun vom Typ "Makro") auch bei einer alten Projektdatei zu sehen, welche kurz vor dem ersten Auftreten des Fehlers noch unter Rel. 61210 gespeichert wurde.

Vielleicht besteht da ja ein Zusammenhang (oder noch ein anderer Bug)?

Gruß Gerd

[gwanjek]

Soeben erneuter Fehler:
1. in einem Projekt ein wenig in der Ansicht mit UP-Schalter hin und her geschaltet, dann gespeichert, Projektausführung beendet

2. anderes Projekt geladen, da was nachgesehen, NICHT gestartet!

3. ursprüngliches Projekt wieder geladen mit Ablehnung der dort kommenden Frage nach Speicherung des Projektes 2. (hatte "Einstellungen" dort einmal offen, was als Änderungskennzeichen offenbar ausreicht), ebenfalls NICHT gestartet

Besonderheit: Das ganze habe ich ziemlich schnell hintereinander ausgeführt.

Fehler: Alle Objekte weg!

Studio-SW sofort beendet (per "x") BEVOR irgendwelche Laufzeitfehler kommen / OHNE irgendwelche weiteren Klicks o.ä.

Projektdatei hat noch Länge von 100 Byte. (später erneutes Öffnen: nur noch "Uhr")

Testprojekt geladen (s.o., das mit Schaltsteckdose, UP-Schalter und Uhr): Diesmal kann noch real geschaltet werden!

SPB-Datei in SPG umbenannt und geladen: Läuft, auch die Typdefinition ("HKklein") ist noch da.

Vermutung: Offenbar die ursprüngliche Fehlerquelle? Irgendwas nicht fertig / durch schnelles Speichern / Projektwechsel gehts verloren?
In Folge dessen fliegt dann bei anschließender Weiterarbeit die Kommunikation weg / hängt sich das FHZ-Modul auf? Beim nächsten Mal laß ichs mal drauf ankommen und klicke noch ein wenig rum nach Fehler.

Nebenbei: Tausend Dank für die SPB-Datei!!!! Ohne die hätt ich jetzt wohl endgültig entnervt aufgegeben!

Auf jeden Fall scheidet das FHZ diesmal als Primär-Ursache aus, denn das läuft jetzt noch problemlos.

Dieses Verhalten deckt sich mit dem 1. Auftreten des Fehlers. Auch da enthielt das Projekt nur noch ein "Uhr"-Objekt. Beim 2. Auftreten war die Datei bzgl. des selbstdefinierten Objekttyps offenbar ebenfalls fehlerhaft gespeichert!

Alles auf Speicherfehler zurückzuführen? Das Verhalten "Nach Wegfall der Kommunikation" bei Fehler 1 und 2 ähnelt sehr dem einer Studio-SW, die nicht freigeschaltet / der Testzeitraum abgelaufen ist. War da auch nur "was nicht sauber gespeichert worden" und nach Power-On-Reset des FZH-Moduls wurde die Freischaltung von dort aus neu initiirt? Dafür spricht auch, daß bei Fehler 1 und 2 in der Hardware-Schnittstellen-Configseite ein Knopf "auf Profiversion updaten" auftauchte bzw. in der Client-Ändern Seite des WLAN-Dialogs unten bei "S-Nr./Info" "keine Verbindung" stand statt der Nummer.

Vielleicht hilft das ja weiter.

Gruß Gerd

[Familienvater]

Hallo "Leidensbruder",

hallo Contronics:

vielleicht hilft es ja beim Fehlereingrenzen: (Muss um 08:00:10 abgestürzt sein, bin um 17 und wieder gekommen...)

Code: Alles auswählen

15.01.2007 09:24:46 > Timeout RM_OG_Flur
15.01.2007 09:26:58 > Timeout TS_EG_FBH_RL
15.01.2007 09:28:04 > Timeout TS_OG_FBH_VL
15.01.2007 09:29:43 > Timeout TS_EG_FBH_VL
15.01.2007 09:31:22 > Timeout TS_OG_FBH_RL
15.01.2007 17:43:28 >Laufzeitfehler in Modul Exec-Engine bei Objekt Sending
 Klasse:TCommConF->
Zugriffsverletzung bei Adresse 005988A5 in Modul 'homeputerStudio-70105.exe'. Lesen von Adresse 00133000
15.01.2007 17:43:30 >Laufzeitfehler in Modul Exec-Engine bei Objekt Sending
 Klasse:TCommConF->
Zugriffsverletzung bei Adresse 005988A5 in Modul 'homeputerStudio-70105.exe'. Lesen von Adresse 00133000
15.01.2007 17:43:32 >Laufzeitfehler in Modul Exec-Engine bei Objekt Sending
 Klasse:TTimer->
Zugriffsverletzung bei Adresse 005988A5 in Modul 'homeputerStudio-70105.exe'. Lesen von Adresse 00133000
15.01.2007 17:43:34 >Laufzeitfehler in Modul Exec-Engine bei Objekt Sending
 Klasse:TApplication->
Zugriffsverletzung bei Adresse 005988A5 in Modul 'homeputerStudio-70105.exe'. Lesen von Adresse 00133000
15.01.2007 17:43:32 >Laufzeitfehler in Modul Exec-Engine bei Objekt Sending
 Klasse:TTimer->
Zugriffsverletzung bei Adresse 005988A5 in Modul 'homeputerStudio-70105.exe'. Lesen von Adresse 00133000
15.01.2007 17:43:49 >Laufzeitfehler in Modul Exec-Engine bei Objekt Sending
 Klasse:TMainF->
Zugriffsverletzung bei Adresse 005988A5 in Modul 'homeputerStudio-70105.exe'. Lesen von Adresse 00133000

Ich glaube/hoffe, es hat nichts damit zu tun, das bei mir die Studio-Version "nur" in einer VMware läuft, da ich zum Glück von 4 laufenden Rechnern (486er mit TELES-PABX, Pentium-II 500 MHz mit Novell 5, Pentium II-500 mit Linux, Pentium 500 II-500 mit Windows) auf nur noch 2 laufende (486er und AMD64-3400+ m. 6x160GB im Raid5 unter Linux mit VMware für Windows FHZ 1000 PC, PC-Wetterstation, Virendef. Master etc.), der Novell wurde wegrationalisiert und der alte 500er Linux (4x60GB Raid5) fährt jede Nacht um 1 Uhr per WOL hoch und macht per rsync ein Backup der wichtigsten Dateien und fährt nach 1,5h wieder friedlich in den digitalen Tiefschlaf... Das ganze hat den Stromverbrauch doch merklich reduziert. 486er, Linux-Gurke, Switch und DSL-Router ziehen mit dicker APC USV zwischen 200 und 220 Watt, wenn der kleine zum Backup läuft gehen ca. 330 W durch den "Stromzähler" vor der USV...

Wenn es in der VMware weiter Ärger macht (lief seit 1,5 Jahren sehr gut, bis ich wg. der Abstürze wg. neuer Grafiken bei HMS-Sensoren das ganze komplett neu Programmiert habe), probiere ich noch mal das alte Notebook unter Windows...

Ausgeschweift und weg,

der Familienvater

[Familienvater]

Moin,

wollte mal kurz einen Zwischenstand abgeben: Mit der 70107 ist jetzt die Haussteuerung 24h ohne Absturz auf der VMWare gelaufen, hoffe das bleibt so


Der Familienvater

[gwanjek]

Moin,

wollte mal kurz einen Zwischenstand abgeben: Mit der 70107 ist jetzt die Haussteuerung 24h ohne Absturz auf der VMWare gelaufen, hoffe das bleibt so

Ich wünsche es dir. Ehrlich. Das Problem ist bei mir zumindest bisher auch noch nicht bei einem laufenden Projekt aufgetreten, sondern IMMER bei NICHT gestartetem Projekt, aber gestarteter Studio-SW. Sehr ärgerlich, wenn einem das beim Entwickeln ständig um die Ohren knallt und sogar die Quellen wegbeamt! Und unter diesen Bedingungen treten die Laufzeitfehler immer wieder auf!

Habe aber auch was Neues zu vermelden:

Dem Fehler auf der Spur!
Nach ganz oben von mir gegebener Fehlerbeschreibung scheint es ja ein Kommunikationsproblem zwischen der Studio-SW und dem FHZ-Modul zu geben. Dafür habe ich jetzt ein weiteres und recht einfach aber stabil reproduzierbares Indiz!

Zum Glück hat das 1300 PC WLAN ja eine Web-Schnittstelle, die ja wie oben beschrieben auch bei Fehler (abgestürzte Studio-SW oder Zustand danach mit nicht funktionierender Funk-Kommunikation zu den Aktoren und Sensoren) normal funktioniert. Was ich da nicht getestet hatte, ist der Aufruf des Web-Interfaces des FHZ-Moduls VOR auftreten eines Fehlers, also solange aus Sicht der Studio-SW noch alles "normal" geht:

- Es dauert mehrere Sekunden bis zu einer Minute, bis im Browser eine angeforderter Webseite wirklich beginnt aufgebaut zu werden!

- dieser Zustand ist immer so vorhanden, egal ob ein Projekt gestartet ist oder nicht

- dieser Zustand ist sofort aufgehoben (wieder normaler Seitenaufbau in normaler Geschwindigkeit), sobald die Studio-SW am PC komplett beendet wird / tritt sofort wieder auf, sobald die Software wieder gestartet wird

Das riecht erstmal nach Überlastung der WLAN-Strecke. Ist aber nicht so! Die Activity-LEDs am Accesspoint blinken weiter so ein- bis dreimal auf je Sekunde, bei erstmal erfolglosem Seitenabruf auffallend rhythmisch (logisch, Wiederholung der erfolglosen Seitenanforderung)

Aber offenbar ist innerhalb der FHZ was böse blockiert und verursacht dort irre Last, die die (logischerweise unterpriorisierte?) WWW-Kommunikation stark verzögert.

Denken wir mal weiter: Tritt gleiches (unnormal verlangsamte Kommunikation) dann bei irgendwelchem "normalen Gesprächen" zwischen Studio-SW und FHZ auf, kann es dort dann vielleicht zu unabgefangenen "Verbindungsabrissen" und in deren Folge wiederum zu den bewußten Laufzeitfehlern der grad anstehenden Aktionen kommen usw. usf.

Ursache ist aber eindeutig die Existenz der Client-Kommunikation zwischen Studio-SW und FHZ-Modul, wie die davon unabhängige "Teststrecke" Webbrowser <--> FHZ-Webinterfache reproduzierbar zeigt!

Hoffe, das hilft nochmals weiter bei der Fehlereingrenzung und -Beseitigung.

Achja, was ist das nun mit den auf den Download-Seiten angebotenen Rel.-Ständen? Am Wochenende stand da noch 70107, wie jetzt auch in meiner Studio-SW Installation unter "Hilfe" | "Info". Heute steht in den Kästchen der Download-Seite aber wieder 70106! Muß ich nun downgraden? Läuft die 70106 denn stabil? Die hier genannten Probleme traten ja schon bei 61210 auf!

Gruß Gerd

PS: Falls noch nicht bemerkt: Es gibt noch einen weiteren recht merkwürdigen, aber reproduzierbaren(!) Fehler, der zum Absturz der SW führt. Habe ihn in einem anderen Thread beschrieben, und heute nochmals eingegrenzt auf ein kleines reproduzierbares Projekt.

Sicher ist der nicht ganz so dringend, wie hier erstmal überhaupt eine stabil laufende Studio-SW sicherzustellen. Aber falls das doch damit zu tun hat, evtl. einen entscheidenden Hinweis auf eine gemeinsame Ursache geben kann (ist ja für sich auch reproduzierbar!), wollt ichs nur nochmal hier genannt haben.

[contronics-RK]

Wenn während des Editierens von Projekten die Ausführung aktiv ist kann es zu solchen Abstürzen kommen. Die Bearbeitungsmöglichkeit von Objekten während der Ausführung wird in einer der nächsten Versionen abgeklemmt. Kann es daran gelegen haben?
Verwenden Sie momentan die neuste Version (70107)?
Lässt es sich reproduzieren?

Es kann durchaus sein, dass die FHZ bei aktiver Verbindung mit der Software Zeitprobleme mit der HTTP-Funktion bekommt - das wäre aber eine Hardwaregeschichte der FHZ - das können wir mit der PC-Software nicht beeinflussen.

Mit freundlichem Gruss
contronics - Ralph Krapoth

[gwanjek]

Hallo,
die Antworten auf die Fragen folgen gleich. Aber erstmal

Es gibt aber seit heute eine neue Fehlermeldung:
Konstant bei jedem Starten des Projektes, egal ob Studio-SW neu gestartet oder nur Projekt neu geladen:

Code: Alles auswählen

Der Prozedureinstiegspunkt "LoadCur3orW" wurde in der DLL "USER32.dll" nicht gefunden.

Der blaue Kopfbereich dieser Fehlermeldung lautet:
"homeputer Studio: homputerStudio.exe-Einstiegspunkt nicht gefunden"

Nach Klick auf "ok" ist das Projekt trotzdem da und Lampen können auch geschaltet werden.

Wenn während des Editierens von Projekten die Ausführung aktiv ist kann es zu solchen Abstürzen kommen. Die Bearbeitungsmöglichkeit von Objekten während der Ausführung wird in einer der nächsten Versionen abgeklemmt. Kann es daran gelegen haben?

Wenn, dann nur initial vor dem eigentlichen bemerkbaren Auftreten des Fehlers. Ich bearbeite durchaus öfter mal Objekte, während das Projekt noch läuft, und speichere/stoppe/starte dann kurz hintereinander um die Änderungen zu laden. Die oben beschriebenen Fehler traten alle auf, als dann kein Projekt mehr lief. Aber durchaus denkbar, das das der initiale Auslöser war.

Verwenden Sie momentan die neuste Version (70107)?

Ja, am 13.1.2007 gegen 23:50 runtergeladen. Inzwischen ist auf dem Server ja wieder die Nr. 70106 zu sehen, zumindest in den Texten der Kästchen. Oder ist das was dort liegt nun trotz niedrigerer Rel.-Nr. aktueller?

Lässt es sich reproduzieren?

Der neue Fehler von heute: Ja, bei JEDEM Projektstart.

Der Laufzeitfehler indirekt. Tritt nach gewisser Zeit immer wieder auf. Einmal auch Dateiverlust beim Speichern, s.o.

Das HTTP-Abruf-Problem läßt sich sehr gut reproduzieren! Studio-SW starten, --> Abruf sofort langsam. Gegentest: Abruf einer Seite (ewiges warten), dann Studio-SW beenden --> sofort ist die vorher angeforderte Seite da. Und das nicht zufällig, sondern stets reproduzierbar!

Es kann durchaus sein, dass die FHZ bei aktiver Verbindung mit der Software Zeitprobleme mit der HTTP-Funktion bekommt - das wäre aber eine Hardwaregeschichte der FHZ - das können wir mit der PC-Software nicht beeinflussen.

Komisch ist nur, daß sowas VOR auftreten der o.g. Laufzeitfehler nicht auftrat. Sollte ja auch nur ein Hinweis auf eine möglicherweise tiefer steckende Ursache sein.

Noch eine Idee: Es läuft ständig eTrust-Antivirus auf dem Rechner als Dienst mit, inkl. Echtzeit-Option, d.h. jede angefaßte Datei wird immer wieder gescannt, auch Zip-Archive usw.. Könnte das evtl. irgendwelche Aufrufe zu stark verzögern und damit das Programm zu stark ausbremsen? Wäre aber das erste Mal, daß sowas firmenweit auftritt...

Gruß Gerd

[gwanjek]

Zusatz wg. dem neuen User32-Fehler:

Mein System enthält genau eine aktive Datei USER32.dll (eine 2. im DLL-Cache von Win2k). Länge: 420112 Bytes vom 2.6.2005 23:44

Diese Datei enthält intern an genau einer Stelle die Hex-Code-Entsprechung für "LoadCursorW", jedoch KEIN mal "LoadCur3orW".

Die gesamte Festplatte enthält nirgends in irgendeiner Datei die Hex-Entsprechung für "LoadCur3orW". Also kann diese offenbar fehlerhafte Schreibweise wohl zur Laufzeit durch Verfälschung dieses Strings im RAM erzeugt worden sein, was ja auch mit den Laufzeitfehlern bzw. der "PHP-Längenbegrenzungen" als Fehlerbild korreliert, so man das alles mal mit einem Speicherverwaltungsfehler zur Laufzeit zu erklären versucht...

[squeeezer]

hallo allerseits ...

das gleiche tritt bei mir gelegentlich auch auf. nachdem ich einige objekt-makros erneut programmieren musste (weil spg-datei nach speichern leer war :-) ...), kopiere ich des öfteren die spg-files weg ... keine lösung, aber bisher umgehung ...

das ganze trat definitiv erst auf, als ich zusätzlich zur fhz 1350pc (usb) eine fhz 1300 wlan mit im system hatte. und dann bei genau den selben symptomen, die gwanjek geschildert hatte, also längere arbeiten am projekt ohne, dass die ausführung aktiv war.

kann es sein, dass die fhz 1300 wlan irgendwelche timeouts kriegt, wenn das projekt nicht gestartet ist und dann das ganze hervorruft? bei änderungen am projekt bei laufender ausführung scheint das problem nicht aufzutreten ...

viele grüße ...