Lösungsansätze bei Absturz Problemen


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

    Richtig, aber der OOM lässt nur den TSC Abstürzen. Die Ursache ist aber der Fatale Error. Er kann ein Objekt nicht laden was den TSC mit einem OOM Abstürzen lässt.

    Wenn der TSC die biege macht, bekommt man immer ein OOM.

    Jetzt ist die Frage was den OOM auslöst.

    Zitat von Kanao Tsuyuri

    seit ein paar Tagen besitze ich das Cloud Enhancement Pack von AP. Bei der RSSLO Ostbahn kommt es seitdem immer zu folgendem Absturz (siehe Anhang).

    Entferne mal das AP Cloud Enhancement Pack die RSSLO Ostbahn. Dazu einfach mal den Assets Ordner der Strecke aus der TSC Installation rausholen.

    Danach mal die ganzen Cache Dateien im Content Ordner löschen und probieren ob es geht.

    Verschwundene Strecken im TS-Menü - Rail-Sim.de - Die deutsche Train Simulator Community

    OOM gibts auch manchmal beim Tauschen mit Locoswap..und zwar auch, wenn man das Szenario "abrüstet", also Züge löscht oder kürzt.

    OOM hat nichts damit zu tun, dass der Speicher voll ist. Es ist nur die gemeinsame Endstrecke von Fehlern, die den Code zum Absturz bringen.

    Keine Readme für den Support, der klar in den Dingen steht.


    - Viele Fehler...siehe Logmate -

    Einmal editiert, zuletzt von Broflugo ()

    Bei einer Fehlermeldung mit dem Code 0xc0000005, liegt oft ein Problem beim Datenzugriff vor.

    Dabei kann dieSoftware nicht auf den Speicher zugreifen, der für die Ausführung benötigt wird.

    Der Grund kann viefältig sein, voller Speicherbereich, fehlerhafte Speicheradresse, ungültige Speicherzweisung usw.
    Am Ende steigt daß Programm mit einen OOM aus. Der OOM kommt von der Datenzugriffsberechtigungsüberwachung.

    Unter Windows10 passiert das oft.



    Seit ich Train Sim Classic 2024 habe stürzt der TS nach wenigen Minuten ab,(manchmal schwarzer Bildschirm,manchmal friert es ein). Mit 32 BIt läuft es. Habe MS Defender abgeschaltet,VPN aus, half nix, Vorher lief alles auf meinem Laptop mit 64 bit!!, der ist nicht das Problem (Win 11 Pro 64 bit,1 TB Festplatte,32 GB RAM, Intel Core i7,Think Pad P16 Gen1 von LENOVO,GraKa NVIDIA RTX A2000 mit 8GB)

    Was kann da die Absturzursache sein?

    Danke für einen TIPP

    Andrea

    • Neu

    Wollte hier mal meinen Senf beigeben.


    Meine Hauptbeschäftigung ist Fehlerbehebung. Aus Erfahrung kann ich sagen, dass 99,9% aller Abstürze von fehlerhaften Blueprints kommen.


    Eine grosse Fehlerquelle sind händisch bearbeitete xmls, da kann schon mal eine doppelte ID reichen um Fehlverhalten auszulösen (jede ID muss einmalig sein innerhalb eines Blueprints). Wer sich mal die Texturing.bin von Bessemer & Lake Erie ansieht dem kommt das Grausen, Copy Paste und mehrfach vergebene IDs. Erst nachdem ich die neugebaut hatte lief die Strecke absturzfrei.


    Es exisitiert sogar eine template bin von JustTrains die beim unSerzen die festplatte füllt bis sie platzt oder man mit Ctrl+C abbricht. Das Fehlen einer klitzekleinen spitzen Klammer kann ausreichen. JustTrains ist ein eigenes (gut erforschtes) Thema - bitte nicht auf Steam kaufen. DTG haben da Mist gebaut - die packen die .aps, und es können sich mehrere .aps in einem Asset Ordner befinden mit identischen Inhalten, was nicht geht, weil der Cache Generator keine von beiden priorisieren kann und aussteigt. Wenn also der TS OHNE Fehlermeldung zum Desktop crasht, sucht nach einer blueprints.pak mit 0 bytes - löschen alleine reicht nicht, sondern schauen was in betreffendem Assetordner los ist. Das passiert leider auch bei Tehachapi wo die gleichen Assets zweimal (mit und ohne BNSF logo verschickt werden - es kann nur einen geben.) In dem Fall muss man die Unbranded ES44 per Steam DLC Manager deaktivieren.


    Ich hatte mir letztens mal die ungarische MAV70 vorgeknöpft (nix spektakuläres, noch im Bau). Neben massenweise Fremdassets im Kuju Ordner (kann praktisch nur der Autor selbst spielen) hab ich mir dann auch die RouteProperties mal angeschaut. Näheres dazu im DTG Forum "'t Hart van Nederland & Freeware", hab mir die Finger wundgeschrieben.


    Kurz gesagt, es ist extrem wichtig dass Assets korrekt preloaded werden. Wenn eine Route ewig lädt trotz SSD kommt das davon dass verwendete Assets nicht im <BlueprintSetPreload> tag der RouteProperties stehen. In diesem Fall lädt der TS scheinbar nicht die extrem wichtige blueprints.pak, sondern sucht jedes Asset einzeln als wenn es keinen Cache gebe. Habe mir von TSTools alle verwendeten Assets listen lassen und die RouteProperties.xml manuell restrukuriert. Ergebnis - keine Abstürze nach Erstellen eines Szenarios und Play klicken, und extrem reduzierte Ladezeit. Seht die Blueprints.pak als Equivalent und Mischung aus Unreal AssetRegistry.bin und uasset. Der Trick hier ist einen Index aller Assets zu haben so dass quasi Addressierung an einem Stück gelesen werden anstatt Header-Data-Header-Data (und blueprints.pak werden komplett in den Speicher gelesen, die Assets selbst nur wenn benötigt und wieder entfernt wenn nicht benötigt.)


    Der oft verbreitete Mythos, eine .ap werde in den Speicher geladen stimmt nicht. Das ist ein virtueller Pfad den zlib.dll verwaltet und völlig transparent an TS weitergibt, der davon garnix weiss. Die .ap hat ihre Existenzberechtigung weil a) Moderne Dateisystem grosse Dateien lieben und zehnmal schneller verarbeiten als die gleiche Datenmenge in losen Files (ist wie Bierkasten holen statt jede Flasche einzeln zu kaufen, bezahlen und nach Hause bringen, dann das gleiche Spiel wieder.), b) ein Prüfsummencheck in Sekundenbruchteilen erfolgt und c) zerstörungsfreies Modden möglich wird (Override statt Overwrite). Ich brauche keine bak. Dateien da das Original geschützt im unkomprimierten .ap Container liegt und ich bloss die Mod löschen muss um zurückzugehen. Prinzip von John Carmack eingeführt in Doom, mit IWAD und PWAD Dateien.


    Ebenso falsch ist der Mythos Steam würde Dateien löschen nach einer Überprüfung. Steam löscht niemals Daten die es nicht selbst angelegt hat, nicht mal durch eine komplette Deinstallation. Wer hier löscht ist eine Routine im TS die ausgelöst wird wenn die Überprüfung den Core (appid 24009) neu herunterlädt aufgrund von Unterschieden zum Originaldepot nach Verifikation - getriggert durch eine dort befindliche Datei namens verify_cache_key. Trifft TS auf diese, vergleicht es den Inhalt von .ap Archiven mit losen Dateien im gleichen Pfad und löscht Duplikate um dem Tech Support ein Werkssystem zum arbeiten zu geben. Steam selbst kümmert der Inhalt von .ap Dateien wenig, es kann sie gar nicht lesen. Nach der Löschung die sich durch eine lange Startphase deutlich macht, wird verify_cache_key auch wieder gelöscht.


    Wer seine RailWorks Installation also im Steam Pfad hat (muss man nicht, läuft von überall sogar mehrfach Instanzen), kann sich eine .bat Datei schreiben die auf Vorhandensein dieser kleinen Triggerdatei prüft, ggf löscht und dann RailWorks startet. Nur soviel dazu.


    Wenn QDs crashen, lasst mal LogMate mitlaufen - es finden sich zahlreiche korrupte consist preloads - alles was LogMate als INVALID DATA moniert muss gelöscht werden.


    Fragwürdig aber vom TS verdaut werden immer noch falsche CabOcclusion blueprints von DigitalTrainModel (der nimmt Tunnel Occlusion blueprints und ist nicht lernfähig wie es scheint.).


    Habe mittlerweile ne 1.6 TB Installation mit aller erdenklicher Freeware, und manches muss aussortiert werden und oder kann repariert werden. Ganz selten bleibt was "unerklärlich". Was bleibt sind Fehler im Streckenbau (wenn logmate haufenweise network ribbon synched meldungen ausgibt - der TS handelt dass jedoch ziemlich gut und macht oft noch das beste aus der Situation, bis es halt knallt.


    Will sagen, der Grund kann meistens lokalisiert werden. An Hardware oder Pagefile rumzuspielen ist nicht der Weg. Es ist der Content.


    Es sind ganze zwei DTG Szenarien bekannt die das Core Update nicht verdaut habe, für beide habe ich Patches (keine Klone, also Achievement und XP tauglich) auf trainsimcommunity hochgeladen. Grund sind striktere Assertions (Annahmen) beim Platz zum Rangieren, die den Editor und Szenarien stabiler gemacht haben. Mittendrinabstürze habe ich nicht mehr erlebt. Da Szenarios alle Dispatcher Berechnungen fertig in der scenario.bin haben, funktionieren diese nun nicht mehr. (Dispatching geschieht im Szenarioeditor, Signalisierung im Spiel).


    Fast vergessen, Workshop: Immernoch passiert es, dass bei Mehrfachabos die ScenarioProperties.xml zerschossen wird.


    Das läuft so. Du klickst den Abo Knopf, Steam lädt den Inhalt als .zip herunter nach steamapps\workshop\content\24010. TS kriegt nen Ping daß er da nachgucken soll. Er entpackt das zip und schiebt es nach RailWorks\temp. Dort fügt er drei Workshop Tags in die xml ein die den Inhalt als "Workshop" kennzeichnen. Danach kopiert er den Inhalt in den Content Ordner. Bei jedem Start werden die Inhalte des workshop ordners mit dem lokalen Inhalt verglichen und bei bemerkten Änderungen das Workshop file neu kopiert.


    Das ganze funktioniert so lang, als TS nur eine Datei zu bearbeiten hat. Wenn hier aber mehrere hintereiander abonniert werden, versaut der TSC aus irgendeinem Grund die xmls. Da hockt man dann vor einem nicht mehr starten wollenden TS der nun eine korrupte SDBCache.bin hat und auch noch ständig die Abos abgleicht mit dem was auf der Platte ist.


    In dem Fall: ALLES runter was Workshop ist. Deabonniert alles, löscht die zips aud RailWorks\temp und leert steamapps\workshop\content\24010.


    Der geschickteste Weg ist auf diesen Workshop syncing Firlefanz zu verzichten (TS Workshop inhalte dürfen sowieso nach Finalisierung nicht geupdatet werden da es Szenarios inkompatibel machen könnte):


    Lasst TS geschlossen, abonniert fröhlich so viel ihr wollt, klickt alle Coasty Szenarios an, was auch immer.


    Dann mit nem gescheiten Allesfresser wie 7zip Filemanager in den steamapps\workshop ordner gehen, per Doppelklick durch die zips klicken bis ihr am Content folder angelangt seid und Railworks noch als zweite Ansicht aktivieren, dann könnt ihr direkt alles nach RailWorks kopieren ohne das der TSC was von mitkriegt, wie jedes andere heruntergeladene Szenario auch. Das bleibt dann auch bei euch auch wenn's der Autor löscht.


    Danach leert ihr den Workshop folder und deabonniert alles wieder!


    Der Daumen hoch / runter taucht nicht mehr auf, also dem Autor auf seiner Workshopseite direkt für den Spass oder Stress danken :)


    Edit: Zum Schluss noch dies: wer irgendwo fahrende schwarze riesige Wände sieht braucht nur in den Welteditor zu gehen und RSDL\IslandLine zu aktivieren (wer die nicht haben sollte der hat auch die Wände nicht). Grund ist hier der ScaleRail RoadTraffic der auf IslandLine Autos zugreift, diese aber nicht preloaded werden (verschachtelte Referenzierung.) Ein GeoPcDx das nicht preloaded wird UND sich bewegt erzeugt Polygonmüll. Das ging wohl zu KRS Anfangszeiten ohne Cache und Scenarioproperties als der TS sich beim laden halt alles zusammengesammelt hat, als absehbar wurde das man ein Konzept zum Handeln der Riesen Datenmengen braucht ging das so nicht mehr. Bei statischen Shapes ist es egal, deshalb muss die VegEP von AP auch nicht geladen werden. Die bins holen sich die statischen Geos aus dem AP Folder ohne Probleme.

    27 Mal editiert, zuletzt von Spikee1975 () aus folgendem Grund: Grauenhafte ADHS Rechtschreibfeeler

    Danke 5 Ausgezeichnet 3 Gefällt mir 1
    • Neu
    Zitat von Spikee1975

    Eine grosse Fehlerquelle sind händisch bearbeitete xmls, da kann schon mal eine doppelte ID reichen um Fehlverhalten auszulösen (jede ID muss einmalig sein innerhalb eines Blueprints).

    Vielen Dank Spikee für deinen Beitrag. Da ich selbst grade auf Fehlersuche bin kommen mir noch zwei Fragen dazu. Darf die ID nummerisch fortlaufend sein oder müssen gewisse "Sprünge" bei Nummerierung eingehalten werden?

    Inwieweit können die Einträge der LogMate aufschlussreich sein wo der Fehler liegt? Hast du da einen Überblick?

    Viele Grüße und danke,

    Dennis

    • Neu

    Da meine Entdeckungen auf purer Erfahrung (9000 Stunden TSC) beruhen, kann ich natürlich gewisse Dinge nicht definitv sagen ohne den GameManagerVC64.dll Quellcode vor mir zu haben.


    Deshalb mache ich es grundsätzlich so dass ich mir DTG Blueprints anschaue oder mal eben einen selbst per BlueprintEditor erstelle um valides Format zu testen, da sieht man dann schnell Muster.


    Vorsicht bei .proxyxml Dateien da hier Sounds direkt per vergebener ID referenziert werden.


    Zum Thema LogMate, es spuckt dir halt alles aus was nicht in Ordnung ist. Erstmal missing blueprints, oft sind das einfach Preloads wo du das benötigte Rollmaterial nicht hast. Harmlos, erscheint halt einfach nicht im Spiel.


    Dann "blueprint xyz appears to contain invalid data". Das sind beschädigte Dateien, die müssen entfernt werden (Ich schiebe die in meinen Quarantäne Ordner um mich daran zu erinnern ggf mal danach zu suchen - oft kann man Assets die in irgendwelchen Megapacks vorhanden sind fixen wenn man den Originalupload des Autors ausfindig macht.) Wenn du die unserzt, hast du enweder ne leere xml oder müll. Im Falle einiger im Umlauf befindlichen usermanipulierten Wilburton\Stockton bins und Geos eröffnet ein Blick in die Datei dass da komische MP3 download links verborgen sind und sowas.


    Also wenn der TS crasht gibts da nen Grund. Und OOM war schon immer eine falsche Fährte (weil von RailWorks.exe und nicht Windows). Ein hardcoded text - die hätten da auch reinschreiben können "In China ist ein Sack Reis umgefallen" und die Leute hätten das geglaubt. Es wurde lediglich das alte "Something bad happened" durch diesen Text ersetzt, der nichts über den Fehler aussagt sondern einfach am Ende der Fehlerbehandlungsroutine steht - wenn nix mehr geht, ist's halt OOM - die jetzt zumindest das Modul nennt in dem der Fehler auftritt. (Dispatcher, Frontend, etc...)

    • Neu

    Vielen dank Spikee für deine Rückmeldung.

    Ich muss zugeben den Fehler die ID beizubehalten habe ich grade bei Child-Objekten von Loks öfter gemacht. Da gibt es nun wohl bedarf nachzuarbeiten. Daher die Frage ob die ID auch nummerisch fortlaufend sein darf.

    Zur LogMate im Bezug auf ein Absturzproblem verursachen mehrere Dateien "RunTimeError". Da werde ich noch nicht ganz schlau draus.

    Viele Grüße und Danke,

    Dennis

    • Neu

    Auffällig oft vor dem Absturz wiederholen sich folgende Zeilen:


    2024.11.27 02:00:21.465 - [RunTimeError] - Verify failed:

    2024.11.27 02:00:21.465 - [RunTimeError] -

    2024.11.27 02:00:21.465 - [RunTimeError] - D:\build\CoreRelease\Code\DLLs\NetworkManager\cLevelCrossingProperty.cpp : 139

    2024.11.27 02:00:21.465 - [RunTimeError] -

    2024.11.27 02:00:21.465 - [RunTimeError] - Expression: mEntity != 0

    2024.11.27 02:00:21.465 - [RunTimeError] -

    2024.11.27 02:00:21.465 - [RunTimeError] -

    • Neu

    train:bird


    Direkt in Railworks. Das heisst beim allerersten Start wird TS dazu gebracht alle Modifkationen seiner eigenen Dateien zu löschen, um eine saubere Reinstallation zu gewährleisten. Viele Fehler lagen genau daran, dass ausserhalb von .ap irgendeine modifizierte .bin liegt von der der Benutzer nichts mehr weiss. (Ja, leider macht die Steam S25 Kuju Plattformmenschlein kaputt, so dass diese auf anderen Routen nicht erscheinen... da wird ein Asset in Kuju\RailSimulator ersetzt was eigentlich nicht sein darf - hätten DTG merken müssen da sie die Depotinhalte an Steam schicken.) Assetüberschneidungen zwischen Depots sind zu vermeiden - was bei einer Überprüfung passiert hängt davon ab ob Steam zuerst das ELAP ersetzt oder die S25)



    Verantwortlich für die verschwundenen Kuju Leute und leere Plattformen auf anderen Strecken ist hier diese .ap der Ringbahn


    Die ersetzt nämlich diese vorhandene Kuju Datei. Hätte man da einfach eine neue VT_PlatformCharacter.bin benutzt und auf die Platformen verlinkt wäre das harmlos. Nun ist es ein Problemchen, da zwei Versionen einer Datei existieren. Unsichtbar für Steam dank .ap Andererseits hat die lose Kuju Datei höhere Prio - wer aber die Assets entpackt der kriegt den Fehler.


    Daher auch mein Appell: Lasst alles wie es ist. .ap's in .ap's und lose Dateien wie sie sind. Moderne Repaints kommen mit ordentlichen Skripts die per freier 7za.exe die Geos extrahieren und kopieren. Sind die Assets aber in anderem als Defaultzustand sind die Repaints dann eben falsch installiert.

    Grundsätzlich gibt's hier ein Problem mit einem Bahnübergang. Schauen ob alle Pfeile korrekt gesetzt sind, es können auch Assets fehlen (Ich habe in der tracks.bin einer niederländischen Strecke einen falschen Assetnamen gefunden, nach Korrektur alles Paletti. Das konnte ich nur mittels Schornstein-statt-Milchkanne finden.

    10 Mal editiert, zuletzt von Spikee1975 () aus folgendem Grund: Ein Beitrag von Spikee1975 mit diesem Beitrag zusammengefügt.

    Gefällt mir 1