Zusi-Forum

Zusätzlich zu der in o.a. Beiträgen beschriebenen Meldung bekam ich soeben die folgende reproduzierbare Meldung kurz nach dem Aufgleisen von Zug ERB 39831vor Salzkotten aus dem Fahrplan "Salzkotten-Kassel-Pad_Pyrmont_2011_12-22Uhr"




EDIT: Bei meinem Versuch nach Update des Paketes 201 ist der Fehler nicht aufgetreten.

Kann ich bestätigen - ebenfalls 64 bit.

Tritt das mit der aktuellen Beta auch noch auf? Bei mir läuft es nämlich.

Carsten

Ist mit ZusiSim 3.5.3.0 verschwunden.

Kriege den Fehler nach Steam Update auch 32/64bit, als Admin, Avast ausgeschaltet -

Funktioniert jetzt - Habe in Einstellungen Standardwerte auf allen Karten eingestellt - Nach lesen von Eintrag von 2022 von "RolliWolli"

Hatte diesen Fehler definitv nach dem letzten HotFix gestern (10.2.) auf der Strecke Salzkotten-Hameln ( Fpl Salzkotten-Kassel-Pad_Pyrmont_2011_12-22Uhr) IC 1943 zwischen Paderborn und Altenbeken.
Versuche das soeben zu reproduzieren und poste das Fehlerfenster wenns gelingt. War bei mir eine andere Hexadresse (fing mit 5 an).
Edit:
Die selbe Fahrt wiederholt und diesmal ist kein Fehler aufgetaucht. Zwei Dinge waren aber anders:
1) diesesmal Tfz 101. Gestern beim Crash war es Tfz 120 ( Fahrplan kann beide spawnen)
2) Vor der Crash-Fahrt gestern hatte ich Zusi mindestens 3x via Steam-UI zwangsbeendet und neu gestartet, heute nur einmal gestartet.
Bei allen Versuchen ZusiDisplay/Buchfahrplan mitlaufen lassen.

Es kommt immer noch vor, leider...

Fahrlplan: Kassel-Hildesheim_Expo_2000_05-15Uhr

Zug:

Ist es reproduzierbar?

Carsten

Jetzt habe ich gelesen, dass es schon eine neue Version 3.5.3 gibt. Das war noch bei mir mit 3.5.2, also Entwarnung. Auf 3.5.3 muss ich noch warten.

Woher kommen eigentlich diese Zugriffsverletzung Fehler?
Habe ich noch nie bei einem anderen Spiel oder Programm gesehen obwohl ich seit Jahrzehnten mit PC's zu tun habe.

Leider sind die Fehler ja immer noch in 3.5 vorhanden (Steam Version)

Florian15 hat geschrieben: ↑12.03.2023 15:27:15 Habe ich noch nie bei einem anderen Spiel oder Programm gesehen obwohl ich seit Jahrzehnten mit PC's zu tun habe.

Hast Du noch nie ein anderes Computerspiel abstürzen sehen? Das passiert denen genauso. Häufig ist es allerdings so gelöst: Andere Spiele behelligen den Nutzer nicht mit der Fehlermeldung, sondern fangen sie ab, und dann gibt es einen "Crash to Desktop". Das in Zusi auch so zu machen würde dem Nutzer zumindest das oftmals notwendige Gehampel mit dem Taskmanager ersparen, um den dysfunktionalen Prozess abzuräumen.

Das fände ich allerdings eher nervig, weil meistens, wenn ich eine Zugriffsverletzung bekomme, läuft Zusi danach problemlos weiter und lässt sich auch problemlos beenden.

(Eine Option wäre allerdings, dass wenn man Zusi über Beenden beenden will, er sich merkt, dass der Nutzer das schon ein 1. Mal versucht hat, und wenn er es dann noch ein 2. Mal versucht, hat das 1. mal nicht geklappt, und versucht dann, sich selbst zu killen.)

F. Schn. hat geschrieben: ↑12.03.2023 16:30:12 Das fände ich allerdings eher nervig, weil meistens, wenn ich eine Zugriffsverletzung bekomme, läuft Zusi danach problemlos weiter und lässt sich auch problemlos beenden.

Das kann ich absolut nicht bestätigen. Wenn die Zugriffsverletzung kommt, hilft nur der Abbruch per Task-Manager.

Allerdings stelle ich die Zugriffsverletzungen seit 3.5 im Wesentlichen nur noch bei schnellem Vorlauf fest, was in mir den bereits geäußerten Verdacht erhärtet, daß es in irgendeiner Weise mit dem Zeitsprung respektive schnellem Vorlauf zu tun hat. Da ich aber keine Ahnung habe und die Experten diese Möglichkeit ausschließen, bleibt es bei einem Verdacht.

F. Schn. hat geschrieben: ↑12.03.2023 16:30:12 Das fände ich allerdings eher nervig, weil meistens, wenn ich eine Zugriffsverletzung bekomme, läuft Zusi danach problemlos weiter und lässt sich auch problemlos beenden.

Ich fände es noch nerviger, wenn sich jedwede Software in einem solch undefinierten Zustand undefiniert (destruktiv) verhalten würde. Zuverlässig Wissen oder Verhindern lässt sich das nicht.

Daher ist Schnell-Aus der beste Weg. Es wäre allerdings schön, wenn sich die zurückgebliebenen ZusiDisplay-Instanzen ebenfalls selbsttätig beenden würden.

Die Möglichkeit selbst oder via Microsoft Error Reporting Speicherabbilder (Crash Dumps) auszuwerten und dem tatsächlichen Problem nachzugehen, scheint ja mit Delphi nicht praktikabel zu sein.

Ich habe mit der 3.5.3.0 (Stick) im Fpl Erfurt-Theuern 2019 4-10 Uhr und der Tfzf 83026 beim Beenden nach Fahrtende immer Windows Error Reporting am "Fehler suchen". Daher wäre mir ein automatisches Beenden schon nützlich. Kann aber auch an meinen TCP-Client-Experimenten liegen und ist daher ein eher individuelles Problem.

Maxx hat geschrieben: ↑12.03.2023 17:02:45

F. Schn. hat geschrieben: ↑12.03.2023 16:30:12 Das fände ich allerdings eher nervig, weil meistens, wenn ich eine Zugriffsverletzung bekomme, läuft Zusi danach problemlos weiter und lässt sich auch problemlos beenden.

Das kann ich absolut nicht bestätigen. Wenn die Zugriffsverletzung kommt, hilft nur der Abbruch per Task-Manager.

So ist es bei mir auch, nach der Fehlermeldung geht gar nix mehr.

Hallo Zusammen,

ich habe selbiges Problem dass sich Zusi sofort beim Starten abschmiert mit einer Zugriffsverletzung. Auch der Datei Manager findet keine Updates mehr.
Vielleicht mache Ich auch etwas falsch. Nutze Windows 11 mit 64 Bit Zusi.

lg Kevin

Bei allen fahrplänen und allen Zügen? Etwas mehr Details bei Fehlerbeschreibungen wären shon gut.

Carsten

Hallo,

leider bekomme ich seit dem Wechsel meines Rechners immer diese Fehlermeldung, wie im Screenshot zu sehen ist. Ich habe Zusi bereits mehrfach neu installiert, aber es hat nichts gebracht. Das Problem trat bereits nach dem ersten Download auf. Ich habe auch schon alle Einstellungen zurückgesetzt. Das Problem tritt bei allen Zügen und allen Fahrplänen auf. Vielleicht habt ihr eine Idee wie man Zusi wieder zum laufen bekommt.

LG

Lucio Heinz