Zugriffsverletzung im Modul Hamburg Kassel

[Tilman Schenk]

Können alle hier bitte rhetorisch etwas abrüsten? Ich finde schade, wenn Leute, die hier Fehler melden, so rundgemacht werden. Es entsteht der Eindruck, man dürfe Fehler nur melden, wenn man die Lösung gleich mitliefert.

Stattdessen führen wir seit Jahren immer dieselben Diskussionen. Ich sehe, dass bei Fragen zu den Programmen und ihrer Bedienung oft und gerne und ausführlich geholfen wird. Das ist anerkennenswert. Aber aus irgendeinem Grund reagieren die vielen Experten sehr empfindlich, wenn jemand meldet, das etwas nicht funktioniert oder Fehlermeldungen kommen. Und dann hacken 3-5 Leute auf den einen meldenden User ein, das Muster ist immer gleich: Man könne nicht helfen, sicher sei der PC des Users kaputt, die gegebenen infos reichten nicht aus, um etwas dazu zu sagen. Ich finde das einfach nicht fair vom Umgang her.

Ich weiß, dass die Hobby-User nicht die erste Zielgruppe von Kunden sind. Und noch dazu sind sie "speziell", weil die PC-Kenntnisse sehr unterschiedlich ausgeprägt sind. Gäbe es die Möglichkeit, bei gravierenden Fehlermeldungen (das müsste definiert werden, was das sein soll), mit Einwilligung des Users einen Fehlerreport an jemandem aus dem Entwicklerteam zu senden (das machen ja viele andere Programme auch so), der alle relevanten Informationen enthält? Dann ließe sich vermutlich schneller eingrenzen, ob tatsächlich ein Programmfehler vorliegt. Mich nerven die Zugriffsverletzungen, die bei mir häufig vor Start der Zugfahrt oder nach Beendigung der Fahrt (da macht es ja nix) auftreten, auch. Aber ich halte normalerweise artig die Klappe, weil ich nicht den Eindruck habe, dass man Lust hat dem nachzugehen.

[Alwin Meschede]

Ohne den Fehler in der Programmierumgebung zu haben, ist eine Fehlersuche sinnvoll nicht möglich.

^^Das ist leider absolut richtig. Abstürze während der Fahrt sind halt die undankbarste Sorte Fehler überhaupt. Das Programm hat in dem Moment gigabyteweise Daten im Speicher. Das ist dann wie die Suche nach einer Nadel im Heuhaufen. Da nützt auch eine wie auch immer geartete "Fehlerberichtsfunktion" dann wohl kaum was. Am ehesten hätte man vielleicht noch eine Chance, wenn einer der Betroffenen sich seinen Computer unter den Arm klemmt und damit nach Braunschweig fährt.

[Johannes]

Gäbe es die Möglichkeit, bei gravierenden Fehlermeldungen (das müsste definiert werden, was das sein soll), mit Einwilligung des Users einen Fehlerreport an jemandem aus dem Entwicklerteam zu senden (das machen ja viele andere Programme auch so), der alle relevanten Informationen enthält?

Das wäre überaus sinnvoll, aber man müsste diese relevanten Infos erst einmal bekommen. Delphi hat so was auch in neueren Versionen nicht eingebaut, man müsste es selbst programmieren oder eine Drittanbieter-Komponente wie MadExcept einbauen, die nicht ganz billig ist. Allein ein Call stack wäre bei vielen Meldungen schon sehr hilfreich.

[F(R)S-Bauer]

Ich weiß, dass die Hobby-User nicht die erste Zielgruppe von Kunden sind.

Diese Aussage ist so unvollständig. Carsten hat selbst gesagt, dass über 50 der Arbeit in den Hobbybereich gehen, das tut man nicht bei einer Rand-Zielgruppe.

Das eigentliche Problem ist die nicht definierte Umgebung von privat-PCs, ein älter Ausdruck war "DLL-Hölle" für das Dateichaos aus der Frickelprogramierung insbesondere im frühen Windows. (*)
Wenn Carsten einen Firmenkunden betreut bekommt der Kunde einen genau abgegrenzte Leistung, die in allen Punkten in seine Hand ist. Und genau nur die eine Anforderung muss er erfüllen.
Er hat genau eine Strecke, einen PC Type, und eine Anzahl von genau X-Szenarien, die er austesten kann.

Das alles ist bei einem Privat-PC nicht vorhanden.

Ich kann nur aus den Software-Deployment-Prozessen berichten, die ich selbst habe und hatte: Du hast eine sorgsam getestete Master Installation, hast 100 PC von der gleichen Palette mit fortlaufenden Seriennummern eines namhaften Herstellers... und 5% der PC laufen nicht oder sind komisch, wenn du Deployt hast.

Daran gemessen haben wir sehr wenige Probleme.

Gruß

Ralf

(*) Ich empfehle anstelle x*mster mal YouTube in der CCC Ecke zu besuchen, Gulasch Programmierer Nacht, da wird viel über die Probleme bei realer Software gesagt, gerade wenn Sie eine Geschichte hat. Auch dieser Link ist zu empfehlen: Disintegrating Rockets

[MaikistimForum]

Am ehesten hätte man vielleicht noch eine Chance, wenn einer der Betroffenen sich seinen Computer unter den Arm klemmt und damit nach Braunschweig fährt.

Ich finde das ist eine Super Idee da freut sich der Carsten bestimmt, wenn man zum Käffchen vorbei kommt

Aber Spaß bei Seite, ich finde hier wird größtenteils echt super Support geliefert und auch regelmäßig kommen neue Updates, Erweiterungen usw & all das für "Lau" weil es keine DLC gibt. Meinen vollsten Respekt habt ihr!

[Thomas U.]

Wäre doch die Idee für's nächste Zusi-Treffen. Ein Fehlersuchworkshop, zu dem jeder, der Probleme hat, seinen PC mitbringen kann

[F(R)S-Bauer]

Aber nur wenn er auch eine Windows Quelle und Key dabei hat, das geht am schnellsten...

[Robinio9900]

Irgendwie muss sich ein Fehler der bei vielen auftritt reproduzieren lassen. Vielleicht wenn man mal an den Einstellungen etwas ändert, so wie ich sie bei mir habe.
Kann mir ehrlich gesagt nicht vorstellen dass dieser Fehler beim Entwickler nie auftritt. Bin diesen Zug mindestens 3 mal Probe gefahren, und der Fehler trat alle 3 mal an der selben Stelle auf. Sowas hatte ich auf anderen Zusi-Modulen noch nie. Vielleicht mal die Einstellungen von denen übernehmen die das Problem haben, und dann diesen IC aus dem Fahrplan einfach mal abfahren.
Kein Grund mich jetzt blöd anzumachen, ist ja nur ein Vorschlag.

Gruß

[Alwin Meschede]

und der Fehler trat alle 3 mal an der selben Stelle auf.

Dann würde es uns weiterbringen, wenn Du mal erforschst ob man die Stelle wo es auftritt irgendwie verschieben kann, indem Du an deinen Einstellungen spielst. Beispiele: Hängt es von der Sichtweite ab? Hängt es vom Laderadius ab? Ändert sich was, wenn der Simulator als Fenster statt als Vollbild betrieben wird?

Dann weiter die Frage: Was macht der Simulator eigentlich in dem Moment unmittelbar vor dem Absturz? Laufen Ladevorgänge? Stellvorgänge des Stellwerks? Das kann man prüfen, indem man kurz vor der Stelle des Absturzes mal die weißen und grünen Warnmeldungen einschaltet.

[Robinio9900]

Also habe jetzt mal ein bisschen rumprobiert. Der Fehler scheint (zumindest bei mir) unabhängig von den Einstellungen aufzutreten.

Hier die Meldungen unmittelbar vor dem Error:


Gruß

[Alwin Meschede]

Hier die Meldungen unmittelbar vor dem Error:

Der Scrollbalken auf dem Screenshot steht nicht am oberen Rand. Es könnte sein dass also nicht die letzten Meldungen auf dem Bild zu sehen sind.

[Robinio9900]

Habe es nochmal versucht. Ist immer ein bisschen schwierig alle Meldungen drauf zu bekommen. Das Fenster verschwindet nämlich mit der Zugriffsverletzung.

[Carsten Hölscher]

Lass und mal auf 3.5 warten, bevor hier mehr Energie verbraten wird.

Carsten

[Iarnród]

Mir ist dasselbe in Orxhausen passiert (mit IC 2083 im Beta-Fahrplan Kassel-FGTB-Lehrte_2020_06Uhr-10Uhr.fpn), Zusi 3.4.6.0 USB-Version, Windows 10.00.19042 64bit:


Tschüss

Iarnród

[Rainer Wefeld]

Mojn zusammen,

auch auf die Gefahr, daß ich nerve..., aber beim frischaufgesetzen Rechner (Probleme bei einer anderen ebenfalls perfekt performenden Simulation) ist bei ICE 973 im Modul Orxhausen folgender schon bekannter Fehler aufgetreten



Grüße
Rainer

[Michael Springer]

Ausgehende Systemressourcen. 64bit Version verwenden, Sichtweise und Laderadius reduzieren, ...

[Rainer Wefeld]

es ist die 64bi-Version und Zusi ist auf Standard-Einstellungen

[Michael Springer]

Gehts mit halber Sichtweite und halbem Lade-Radius?

[Rainer Wefeld]

Ich habe heute, bzw. das WE keine Zeit mich nochmals (sinnlos) an den Rechner zu setzen, evtl. ab Mintag

[Reaktor]

Ich bekomme die Meldung auch immer an dieser Stelle (auf dieser Brücke ungefähr). Das sollte aber mit der Version 3.5.3 verschwunden sein oder was.