4D Client v17 64 Bit Windows Crash

Hallo Liste

Wir sind bei der Konvertierung einer Client-Server Applikation von 4D V16.1 nach 4D V17.0 HF4 auf erhebliche Stabilitätsprobleme mit dem 4D V17 64 Bit Client gestossen.
Systemumgebung: Windows Server 2012 R2, 4D V17 HF4 Server 64 Bit, Windows 7 und Windows 10 Workstations.
Legacy network ist deaktiviert.

Eine Stored Procedure auf dem Server melded in der Nacht alle noch verbundenen 4D Clients ab (Execute on Client).
Sind 64 Bit 4D Clients am Server angemeldet klappt das Abmelden häufig nicht. Die Fenster werden abgebaut, aber kurz vor dem Beenden kommt ein Windows Meldung (Client has stopped Working…). Dies passiert nicht immer, aber sehr oft. Werden auf den gleichen Workstations die 32 Bit Versionen des 4D Clients gestarted funktioniert das Abmelden einwandfrei.

Das gleiche Phänomen mussten wir auch im GUI feststellen. Es tritt nur beim 64 Bit Client auf. Häufig crashed der 4D Client beim beenden eines Prozesses. Der Prozesses startet die Dateneingabe in einem Formular (FORM SET INPUT…, Open Window…, Modify Recorc…, Close Window). Man kann bis und mit “Close Window” tracen. Danch folgt nichts mehr und der Prozess sollte sich beenden. Der 64 Bit Client stürzt hier sofort ab. Beim 32 Bit Client konnten wir noch keine Abstürze feststellen.

Wir haben schon mit dem Stack Space rumprobiert. Das hat nichts gebracht. Der 64 Bit Client stürzt ab, auch wenn der Stack massiv erhöht wird (1024*1024).

Hat jemand mit dem 64 Bit V17 Client auf Windows ähnliche Erfahrungen gemacht? Was muss noch beachtet werden, damit auch der 64 Bit Client zuverlässig läuft?

Danke für sachdienliche Hinweise!

Bitte wenden SIe sich an die Hotline von Ajar, bzw öffnen dort einen TAOW Fall.
Ich vermute es werden diverse Logs benötigt (wie Debug-Logs des ausführenden Codes auf dem Client, sowie die Windows Crash Logs, ggf erweiterte). Bitte besprechen Sie das mit der Hotline.

Hello Franco,

Could you post this case on TAOW ?

Best regards

Maurice

Our messages crossed paths! :slight_smile:

Danke für den Hinweis Herr Maul.
Ajar hat mich bereits darauf angesprochen. Ich werde baldmöglichst einen TAOW erstellen. Wollte zuerst noch ein wenig weiter testen mit dem 32 Bit Client um sicherzustellen, dass die Probleme dort nicht auftauchen. Bisher sieht es ganz danach aus.

: Franco ZARABARA

Legacy network ist deaktiviert.

Und auf Legacy Network zurückzugehen ist keine Option?

Wir wollen auch in Kürze auf v17 gehen (64-Bit-Server, 64-Bit-Client), aber wir bleiben erst mal auf Legacy Network.

wäre es nicht sinnvoller zu untersuchen warum diese Anwendung auf diesen Rechnern ein Problem hat?

wer sagt das es irgend etwas mit dem Layer zu tun hat, ohne es zu untersuchen?

Legacy Network erlaubt keinen Sleep Mode. Kein SSO. Kein StartTLS. Kein IPv6. Weniger Info in den Diagnostic Logs. Keine preemptive Clients.

Wenn es wirklich daran läge, wäre es ein Workaround aber nicht die Lösung. ich kann mich aber nicht an Client Abstürze erinnern, die mit dem Network Layer zusammengehangen hätten.

Defekte Bilder, ja. Defekte Plugins. Defekte Schriften. Fehler im Code (unseren oder dem vom Entwickler). Alle möglichen Ursachen. Close Window führt zu einem Redraw Event der darunter liegenden Fenster, siehe oben.
Aber Network Layer? Wenn dann wäre einfach die Verbindung weg, aber hier heißt es Crash.

Deshalb vermutete ich das man Logs benötigt, um dies zu analysieren. Alles andere ist Ratespiel und nicht wirklich zielführend.

Wir haben auch mit Legacy Network getestet. Das Resultat war ähnlich. Gefühlt gab es etwas weniger Abstürze, aber was heisst schon “gefühlt”.
Bei einem Test (Legacy Deaktiviert, 64 Bit Client) kam es zu folgender Konstellation:
Am Server angemeldet waren 4 Clients. Das Abmelden der Clients führte zu folgendem Ergebnis:
Ein Client der auf einem Windows 2012 R2 Server ausgeführt wurde, terminierte korrekt.
Zwei Clients (Windows 10 und Windows 7) blieben mit einem Task Pending Dialog hängen. Der Task war aber vorher eindeutig geschlossen worden. Ein beenden der Clients war nur noch über eine Benutzer Interaktion möglich (Klick auf “Cancel”).
Ein Client blieb mit einem Runtime Error stehen “Error Code 203 (xbox)”. Da war der besagte Client schon in der On Exit Methode drin.

Das Abmelden der Clients erfolgt schon seit Jahren gleich (Server Task - Execute on Client). Bis und mit Version 16.1 hatten wir nie Probleme damit. Wir sind darauf angewiesen, dass dies einwandfrei funktioniert und keine Benutzeraktion nötig ist. Das Abmelden erfolgt in der Nacht vor einem grösserne “Houskeeper” Task, der anschliessend auf dem Server startet.

Die Fragen, die sich mir stellen sind:
Weshalb kommt dieser “Pending Task” Dialog, obwohl die Clients alle Fenster abgebaut haben und vermutlich schon in der On Exit Methode waren?
Wieso kann dieser “Pending Task” Dialog nur mit Cancel verlassen werden? Wieso gibt es nicht einen Counter der nach 20 Sekunden endgültig terminiert ohne Benutzerinteraktion?. Ein Klick auf OK bewirkt eine Endlosschlaufe. Der Dialog wird immer wieder angezeigt.
Was bedeutet der Fehler “Error Code 203 (xbox)”? Das kann eigentlich nur was mit dem Netzwerk zu tun haben, oder?

Das Verhalten konnten wir in unseren Tests bisher einmal feststellen. Daran beteiligt waren immer 64 Bit Clients.
Mit 32 Bit Clients haben wir weniger oft getestet, dort ist das oben beschriebene Verhalten aber nie vorgekommen.

Da wir für die Produktion absolut darauf angewiesen sind, dass sich die Clients korrekt beenden lassen, werde ich hierfür einen separaten TAOW erstellen. Vorderhand werden wir den Rollout mit 32 Bit Clients machen.