TS-Abstürze auf Münster-Bremen [gelöst]


Abonniere unseren Kanal auf WhatsApp (klicke hier zum abonnieren).

    Hallo zusammen,


    wie viele andere hier wahrscheinlich auch bekomme ich im TS19 in der 64-Bit-Version ab und zu gefühlt zufällig und nicht reproduzierbar “Access Violation”-Fehlermeldungen auf verschiedenen Strecken (auf Freiburg-Basel gefühlt häufiger als auf DTG-Strecken).
    So weit, so ärgerlich. Man sollte halt regelmäßig zwischenspeichern und muss dann eben mal neu laden. Kennt man aus anderem Grund ja schon aus den vorherigen TS-Versionen.


    Auf Münster-Bremen jedoch verzweifle ich mittlerweile komplett am TS19:


    Das mitgelieferte(!) RE9-Szenario funktioniert problemlos. Andere Szenarien hingegen stürzen jedes Mal ab. Konkret handelt es sich um die Szenarien IC 2218 von luckygod, EC9 von TrainFW und RB 12819 von Konny. Der IC2218 stürzt kurz nach dem Start oder beim Ladevorgang sowohl in 64 als auch in 32 Bit mit “Access Violation” oder “Unknown” ab. Der EC9 stürzt bereits während des Ladevorgangs mit “Unknown” ab. Die RB12819 funktioniert zunächst, stürzt dann aber rund um Westbevern mit “Out of video memory” ab. Für mich als relativen PC-Laien scheint das zu heißen, dass der Grafikspeicher voll ist. Das kann ich mir angesichts von GTX-770 und 8 GB RAM allerdings nicht wirklich vorstellen. Falls das jedoch durchaus der Grund (vielleicht sogar für die anderen Fehlermeldungen?) sein kann, so möge man mich bitte darauf hinweisen.


    Nach dem letzten Absturz des IC2218 zeigte mir der Task-Manager übrigens eine RAM-Belegung des TS von knapp 3,5 GB an. Im TS19 gehe ich aber mal davon aus, dass das noch im grünen Bereich ist. Wobei es mich schon wundert, dass der TS quasi schon beim Start bei diesem Wert ist.


    Ich habe ein wenig dieses Forum, das Steam-Forum etc. durchforstet und bin neben Grafik als möglicher Ursache auf das Thema Sound gestoßen.
    Anscheinend gibt es wohl Probleme rund um den Sound des TS19. Daher solle man in der Setup_Audio.bat den TS-Sound auf 32-Bit umstellen. Gesagt, getan, leider nicht geholfen.


    Auch die Installation der neusten Audio-Treiber hat nicht geholfen.


    Dann habe ich testweise mal in der Windows-Sound-Regelung (die, die man in der Startleiste aufrufen kann) unter “Lautsprecher” den Sound ausgeschaltet, sprich “Realtek High Definition Audio” deaktiviert. Der EC9 kam diesmal über den Ladevorgang hinaus. Leider stürzte das Szenario dann kurz nach dem Losfahren mit “Access Violation” ab. Beim IC2218 brachte die Audiochip(?)-Deaktivierung leider keine Veränderung.


    Außerdem habe ich mal versucht, den TS19 nur mit den Assets zu starten, die ich für das EC9-Szenario brauche. Leider hat auch das beim EC9 nicht geholfen.


    Wenn die Fehlermeldungen in diesen Szenarien auf Münster Bremen unregelmäßig und gefühlt zufällig auftreten würden, wie sonst im TS19 bei mir und anderen, oder wenn ich hier im Forum und auf YouTube nicht Leute sehen würde, die diese und andere Szenarien ohne die genannten Probleme fahren würden, würde ich das Problem wahrscheinlich, wie die unregelmäßigen “Access Violation”-Fehler auf anderen Strecken, schlicht auf den TS19 und irgendeinen bislang nicht gefundenen Fehler im Spiel an sich schieben. Da aber andere z. B. die von mir genannten Szenarien offensichtlich ohne die gleiche Problemlage fahren können, hoffe ich darauf, dass das Problem irgendwo in meinem PC bzw. TS zu finden ist.


    Dass die eingangs erwähnten, zufälligen "Access Violation"-Fehler auf Freiburg-Basel häufiger als auf DTG-Strecken und auf Münster-Bremen die Fehler bei den genannten Szenarien sogar jedes Mal auftreten, noch dazu in performance-lastigeren Szenarien als den Standardszenarien, lässt mich vermuten, dass Grafikprobleme am ehesten die Ursache sein könnten. Wie oben schon erwähnt, bin ich bisher davon ausgegangen, dass meine Grafikkarte und RAM (s. u.) ausreichend sind. Wie gesagt: Falls dem nicht so sein sollte, bitte ich darum, mich darauf hinzuweisen.


    Nochmal kompakt ein paar Infos zu meinem PC (sorry, falls eine bestimmte/notwendige Angabe fehlt, dann bitte einfach Bescheid sagen):


    Intel i5 4570 3,2 GHz
    Nvidia GTX 770
    8 GB RAM
    Audio-Chip: Realtek ALC892
    Windows 7


    Ich bin für jede Hilfe dankbar. Auch Leute mit der gleichen oder einer sehr ähnlichen Situation (d. h. “Access Violation”, “Unknown”- oder "Out of video memory"-Fehlermeldungen, die nicht einfach zufällig oder unregelmäßig auftreten, ggf. auf Münster-Bremen) mögen sich bitte melden. Vielleicht sind ja irgendwelche Parallelen hinsichtlich unserer Systemeinstellungen, TS-Setups o. ä. festzumachen.


    Beste Grüße


    Michael

    Mir hat es an Neujahr meinen TS auch komplett zerlegt, weiter wie ins Menü kam ich nicht mehr, dort konnte ich dann langsam von 5 runterzählen bis der Absturz kam... Bei mir half nur
    noch eine komplette Neuinstallation! Hab echt alles versucht, no chance... Der Witz ist, ich weiss bis heute nicht warum von der einen auf die andere Minute alles im A**** war! :thumbdown:


    Um eine Neuinstallation wirst auch du wohl nicht herum kommen, bei mir läuft seitdem wieder alles. Ich habe mir mein Backup (92GB) vom Gaming Laptop zuhause drauf gepackt und
    dann Steam neuinstalliert. Seitdem läuft wieder alles...


    Was deine Hardware angeht hast du natürlich auch nicht das gelbe vom Ei am Start, eine 770er und 8GB RAM sind definitiv ausbaufähig, besonders der RAM seit 64bit, denn da haben
    manche Szenarien locker über 5GB am Start und dann kommste schnell zum Ende. Die Grafikkarte kann man durch runterdrehen der Einstellungen ausgleichen, dennoch empfehle ich dir
    ganz klar eine 1060 mit 6GB oder was vergleichbares.

    Ich sag nur die "64 Gründe" .... und der 64. ist eben doch der Griff ins Klo, also doch besser 32 zu verwenden. Auch wenns bei mir der Streckenbau und nicht der Fahr-/Szenariofrust war, start ich nur mehr in 32 und warte die langen Wochen bis DTG endlich den 64er fixt ... es gibt ja genug womit man sich sonst beschäftigen kann, Schonkost-Strecken, Repaints, Bin Spielereien usw.

    Nur am Rande, einige Probleme müssen nicht direkt mit dem TS zu tun haben. Offene Systeme heist auch, es gibt eine Vielzahl von möglichen Problemen und Unverträglichkeiten. Und, das der TS plötzlich zerschossen wird, bei mir hatte der letzte Windows Update hineingefunkt (habe aber auch ein sehr altes System!).
    Access Violation ist ja immer ein Fehler, der Auftritt, wenn der TS in bereits belegte Speicherbereiche schreiben will - ist also eigentlich eine Windows-Fehlermeldung. Die kommt bei mir standardmäßig, wenn in der 32bit-Version der Speicher am Ende ist, also irgendwo um die 3,65 GB. Der Fehler spricht dafür, das Dein @xxmichaelxx327 System dann möglicherweise doch zu knapp ausgelegt ist der i5 mit 8GB Ram ist für die mächtigen Strecken - wie gerade Freiburg-Basel und Bremen-Münster vielleicht zu wenig. Das ein mitgeliefertes Scenario funktioniert und andere nicht, hat erst einmal nichts zu sagen. Wenn beim mitgelieferten wenig KI dabei ist, bei den anderen aber viel, dann kann es schon den von Dir beschriebenen Effekt geben. Im Ergebnis kann Dir nur jemand etwas konkret sagen, der ein ähnliches System hat, wie Du es nutzt.


    Gruß Bernd

    System: HP Z800, 2 x Xeon 5550 2,66 Ghz, 96 GB RAM, Nvidia Quadro 4000

    Danke 1
    Zitat von bernd_NdeM

    Access Violation ist ja immer ein Fehler, der Auftritt, wenn der TS in bereits belegte Speicherbereiche schreiben will - ist also eigentlich eine Windows-Fehlermeldung.

    Das hat mit Windows aber nicht viel zu tun, sondern liegt viel mehr an schlechter Programmierung. Sowas kann eigentlich nur bei unsauberer Programmierung passieren, bei einem ordentlichen und gut getesteten Speichermanagement kann es gar nicht passieren, daß in den geschützten Speicher geschrieben wird.
    Halt wieder mal ein typischer TS-Bug..
    Ich hatte solche Access Violations auch schon. Einen wirklichen Zusammenhang konnte ich noch mit nichts feststellen, außer daß es, zumindest bei mir, nur bei manchen Routen aufzutreten scheint. Manche Routen scheinen da besser, manche schlechter mit dem neuen TS64 zu funktionieren.

    Da jeder PC ein Unikat hinsichtlich seiner Hardware, der installierten Software und dem Aktualisierungsstand der Software ist, kann man bei solchen Fehlern, die eben nicht bei allen Nutzern eines Programms auftreten, leider keine allgemein gültigen Lösungsansätze bieten.
    Meine Empfehlungen:
    - Einfach mal die Windows-Ereignisanzeige nach kritischen Fehlern nach einem solchen Absturz durchforsten - hier bekommt man öfters etwas genauere Infos bezüglich des abgestürzten Programms.
    - Des weiteren dafür sorgen, dass alle Runtime-Bibliotheken, die der TS braucht, in der neuesten Version installiert sind. Hier meine Empfehlung: All-in-One-Runtimes von Sereby komplett installieren. Wichtig ist auch, dass Windows, der Grafikkartentreiber und sonstige systemrelevanten Treiber aktuell sind.
    - Wenn ihr eine Software-Firewall installiert habt (z.B. irgend eine Internet-Securety oder Ähnliches) mal schauen, ob hier Programme geblockt werden, die der TS vielleicht für die Ausführung benötigt.
    - eventuell mal vor dem Starten des TS alles an Programmen zumachen/beenden (auch was sich unten rechts hinter den Symbolen versteckt) was man nicht notwendiger Weise zum Start des TS benötigt (auch den Internet-Browser, Drucker-Programme, Java, Office, Steam etc. pp.) - Gemachte Einstellungsänderungen immer notieren, damit der Originalzustand wieder hergestellt werden kann.
    - in Windows 10 kann man dazu auch mal im Taskmanager den Tab "Autostart" durchforsten und alles, was nicht dringend benötigt wird auf "inaktiv" stellen (kann man danach wieder aktivieren) - auch hier notieren, welche Programme auf aktiv standen um diese später wieder aktivieren zu können.
    Mit diesem verschlankten System dann noch mal des TS starten und gucken, ob sich was am Verhalten ändert.
    Wenn der TS dann ordnungsgemäß startet, kann man dann nacheinander die einzelnen Programme wieder aktivieren und dann immer den TS wieder starten, bis der TS wieder einen Fehler ausgibt. Das zuletzt aktivierte Programm dann wieder deaktivieren und dann trotzdem die anderen Programme einzeln weiter aktivieren. Es ist nicht gesagt, das es nur ein unverträgliches Programm gibt.


    Vielleicht hilft diese Wall of Text dem Einen oder Anderen weiter. :)

    Wer andauernd begreift, was er tut, bleibt unter seinem Niveau.

    Danke 2

    Das problem ist gerade bei zu wenig RAM; das anscheinend der TS 19 64 bit Probleme hat mit ausgelagerten RAM Speicher klar zu kommen. Die 3,5 GB RAM im Task Manager sind nur die, die der TaskManager anzeigt, aber nicht wirkliche RAM Auslastung. Was noch wichtig wäre, hast du eine oder mehrere Festplatten?! Wie schaut es mit den Einstellungen des Virtuellen Speichers aus? Usw. Ich hoffe nicht ausgeschaltet. Ich habe selbst nur 4 GB RAM, der TS läuft, natürlich langsam und mit weniger FPS ;) ...


    Dürfte also nicht unbedingt an den 8 GB liegen, aber man muss natürlich gucken, was läuft noch im Hintergrund alles, wie Anti Viren Software usw?! Alleine Windows 10 64 Pro braucht seine 1,3 GB im Minimum. Udn um so mehr verbaut ist, um so mehr Speicher wird auch vom Virtuellen Speicher verlangt, was die Festplatte verlangsamen kann. Und dadurch auch der Content wiederum langsamer geladen werden kann... Bei meinem Szenario bastel ich gerade dran und habe laut Process Explorer 64 (der genauer sit als der Task Manager) ~9 GB RAM Verbrauch im virtuellen Speicher und aktiven Verbrauch zwischen 5-6 GB RAM. Vielleicht damit auch noch mal testen?!

    Manchmal kann man sich einfach nur an den Kopf fassen, was man doch für ein Blindfisch ist...


    Mein Absturz-Problem ist gelöst. Woran hat's gelegen? Nun ja, wie mir leider nach dem Release des TS19 entgangen war, wird nach dem Neustart der 64-Bit-Version (nach dem Leeren des Cache oder nach der Veränderung bestimmter Grafikeinstellungen) nicht der 64-Bit-TS gestartet, sondern der 32-Bit-TS. Der TS startet die Datei, die Railworks.exe heißt, und so heißt nach dem Release der 64-Bit-Version weiterhin die 32-Bit-Version.


    Ich habe also sage und schreibe 3 Monate gebraucht, bis der Groschen fiel, dass ich praktisch die ganze Zeit unbewusst im 32-Bit-TS unterwegs war. Da ich eigentlich jedes Mal vor dem Starten eines Szenarios oder des Editors den Cache leere, wurde dabei eben jedes Mal der 32-Bit-TS gestartet. Hätte man sehen können, wenn man mal z.B. in den Einstellungen nachgeschaut hätte. Natürlich hätte man auch stutzig werden können, dass der vermeintliche 64-Bit-TS immer ungefähr bei der RAM-Auslastung abgeschmiert ist, bei der der 32-Bit-TS immer abgeschmiert ist. Hätte, hätte, Fahrradkette.


    Zum Glück habe ich mir heute mal beim Versuch, den IC2218 ans Laufen zu bekommen, das Leeren des Cache gespart. Et voila, ohne Absturz von Münster bis Bremen durchgefahren. Der Zusammenhang ist mir allerdings erst später aufgefallen, als ich wieder einmal in den Einstellungen unterwegs war und mir dann doch endlich mal das fehlende "x64" bei der Versionsnummer aufgefallen ist. Danke an dieser Stelle an @ber10lin, der in diesem Thread (TS startet jedesmal nach leeren des Cache im 32-Bit-Modus) die Lösung für das genannte Problem erklärt hat.


    Langer Rede kurzer Sinn: Es läuft. Dennoch möchte ich mich nochmal bei allen bedanken, die Lösungsvorschläge gemacht haben. Der Hinweis auf meine suboptimale Hardware ist natürlich berechtigt, immerhin habe ich weiterhin regelmäßig Frameeinbrüche. Angesichts meines näher rückenden Geburtstags wird aber vielleicht auch dem durch neue Hardware beizukommen sein.


    In diesem Sinne beste Grüße und einen schönen Rest-Sonntag


    Michael

    Das sollte man dann doch spüren :D . Ich hatte mir damals auch gleich mal die 32er mit der 64 im railworks verzeichnis überschrieben (umbenannt), so start er automatisch im 64er. Aber nach dem ganzen Mist das DTG da produziert hat und dem völligen Versagen der Editoren in 64bit, hab ich diese wieder verbannt. Wenn man nur Szenarien abfährt kann man die 64 natürlich nutzen.

    [Ironie on]
    Wer gerne auf den Start der Strecke oder eines Szenarios wartet, löscht regelmässig den Cache!
    Was sollen auch die ganzen blueprint.pak Dateien, die braucht der Ts nur um schnell neu zu starten. Weg damit.
    [Ironie off]
    Wer nicht so gerne wartet, löscht den Cache nur, wenn er selbst was in den Daten des TS reinkopiert oder was verändet hat. Ansonsten Finger weg.

    Keine Hilfe und Auskunft per PN, da meist von allgemeinem Interesse. Diese Fragen bitte im Forum stellen.

    Danke 2
    Zitat von StS

    Wer nicht so gerne wartet, löscht den Cache nur, wenn er selbst was in den Daten des TS reinkopiert oder was verändet hat.

    Selbst dann ist es normalerweise nicht nötig. Denn der Cache wird seit dem TS2015 (soweit ich das mitbekommen habe) automatisch erneuert, wenn Änderungen detektiert wurden. Es kommt vor, dass eine Änderung nicht erkannt wird, vor allem, wenn Daten älteren Datums rein kopiert werden. Dann sollte man den Cache des Ordners per Hand entfernen, also .pak Datei des Produkt-Ordners löschen, nicht alle von allen Produkten.

    Ja, so mache ich das auch.
    Ich ändere irgendwas und befinde mich ohnehin dort im Ordner, dann fliegt die Blueprints.pak sofort raus.


    Keine Ahnung, wann ich das letzte mal über den Menüpunkt des TS den Cache geleert habe.

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

    Danke 2