Ich würde gerne auf ein Thema zurückkommen, dass ich glaub ich auf Seite 7 dieser Diskussion schon einmal gefunden habe, das aber nicht gelöst wurde:
"Failed to save dump file to 'C:\TempDump\TS2016 - v54.5b.dmp' (error 0)"
Diese Fehlermeldung hat bei mir zwei Auslöser:
Einmal das platzieren einer gesamten Railjet-Garnitur im Szenarioeditor (platziere ich ihn einzeln, funktioniert es).
Das Hauptproblem liegt aber darin, dass wenn ich Railjet-Teile (Taurus oder einen Railjet-Zug in Einzelteilen) auf einer anderen Strecke, als dem Dreiländereck platzieren will (In diesem Fall: Hamburg-Hannover - Free Roam), sich nach exakt einem vollständigen Railjet und beim platzieren einer weiteren Taurus-Lok diese Fehlermeldung ergibt.
Dazu muss ich sagen, dass Hannover, wo ich es probiert habe bereits relativ voll mit Rollmaterial ist. Bei 16 GB verfügbaren Arbeitsspeicher gehe ich aber nicht von einer zu hohen RAM-Auslastung aus. In Bludenz stehen in einem Free-Roam Szenario vier Railjets und mehrere Taurus-Loks nebst zugehöriger Wagen. Bisher ist dieses Problem auch nicht aufgetreten. Erst seit ich den Railjet installiert habe.
Das Deaktivieren Dynamischer Flora, was ich irgendwo gelesen habe, hat nicht geholfen.
Dump-Fehler mit dem Rail-Jet (ausgelagert aus dem Railjet Diskussionsforum)
-
Bei 16 GB verfügbaren Arbeitsspeicher gehe ich aber nicht von einer zu hohen RAM-Auslastung aus
Der Ts ist nur auf 4GB ausgelegt und selbst diese kann er nicht ausnutzen.Dies ist an soooo vielen Stellen nachzulesen....
-
Bei 16 GB verfügbaren Arbeitsspeicher gehe ich aber nicht von einer zu hohen RAM-Auslastung aus.
Der TS2016 ("Railworks.exe") ist eine 32-Bit-Anwendung, weswegen bei ca. 3,5 GB für diesen einzelnen Prozess das Ende der sogenannten Fahnenstange erreicht ist ---> Absturz!
Das kannst du z.B. im Taskmanager nachsehen, was die "Railworks.exe" benötigt. -
Das kannst du z.B. im Taskmanager nachsehen, was die "Railworks.exe" benötigt.
Was nicht bei Win10 gegeben ist!
-
Heißt der da jetzt anders?
Mit <Strg> + <Shift> + <ESC> sollte das aber auch unter Win10 gehen. -
-
Nein, aber Windows 10 berechnet die Programme jetzt anders von der Auslastung.
Einiges vom TS wird in "Systemspeicher und komprimierter Speicher" vermerkt, sodass ich schon Dumps bei 1,8! GB (railworks.exe) hatte, der auch ein RAM Dumb war (Vergleich auf Win7 PC zeigte >3.4GB), weil der Rest in eben jenem Speicher steht. Einen Workaround habe ich noch nicht gefunden.Altbekannte Tastenkombinationen funktionieren natürlich weiterhin. Irgendwo hatten wir hier im Forum dafür aber mal einen eigenen Thread.
So, genug OT hier. -
-
Das müsstest du schon DTG fragen/Kuju.Die Fehlercodes sind meines Wissens nirgends öffentlich erläutert.
Gefühlt ist ein 54.5 aber ein Ramfehler.
Genau genommen, dass die Anwendung nicht mehr Speicher addressieren kann.
https://support.wildstar-onlin…r-reicht-nicht-aus-Fehler
Das einzige was ich auf die schnelle Suche auf Deutsch gefunden habe.An die Entwickler. Kann es sein, dass da eine Abfrage/Schleife getriggert wird beim Aufgleisen eines Zugverbandes? Vielleicht kann ja jemand mal den Ram während des aufgleisens beobachten.
Irgendwie habe ich mehr und mehr das Gefühl, dass da im Script des Zugverbandes etwas geladen wird, dass sich in einer Endlosschleife verfängt bis der RAM aufgebraucht ist. -
Das müsstest du schon DTG fragen/Kuju.Die Fehlercodes sind meines Wissens nirgends öffentlich erläutert.
Gefühlt ist ein 54.5 aber ein Ramfehler.Die 54.5 ist kein fehlercode, sondern die abgestürzte Version des TS (v54.5b)
Das Speichern eines sogenannten Dumps bedeutet eigentlich nur, dass der TS (also die "Railworks.exe") wegen irgendetwas abschmierte.
In dem abgespeicherten Dump (einer mdmp-Datei) kann man dann theoretisch nachsehen, was den Fehler verursachte.
In der Mehrzahl wird das Speichermangel sein, es kann aber auch andere Ursachen haben, z.B. eine 0-Byte-Datei oder eine Datei mit falscher Endung (z.B. blablabla.GeoPcDx.bin). letzteres passiert gerne beim Repainten, wenn man die GeoPcDx hat serzen müssen, aber vergaß, diese wieder umzubenennen.
Am zuverlässigsten ist immer noch die Fehlersuche mittels LogMate und diversen Tools, die einem den Speicherverbrauch anzeigen.
Eine mdmp-Datei zu anlaysieren dürfte jedenfalls kaum von Erfolg gekrönt sein, es sei denn, man ist Experte im Programmieren, kennt sich mit Assembler aus und hat die dafür nötigen Werkzeuge, wie z.B. einen Debugger.Fehler in einem Lua-Script hingegen manifestieren sich meines Wissens durch einen sogenannten "Crash to Desktop" ohne Fehlermeldung. Das bedeutet, dass der TS sich einfach schließt, weswegen man sich auf dem Desktop wieder findet.
"Beliebt" ist auch noch der Vertex-Fehler, der aber nach meiner Beobachtung ebenfalls durch einen Speicherüberlauf verursacht wird.
Wer viele Abstürze hat(te), sollte übrigens hin und wieder die mdmp-Dateien entfernen.
Diese findet man im Railworks-Hauptverzeichnis und können alle gelöscht werden.
Außerdem auch die Crash-Dateien im "C:\TempDump\"-Verzeichnis -
-
Prelli, es gibt aber auch 53.X Fehler und andere.
Zumindest bei 0 byte Dateien weiß ich, dass ein anderer Error geworfen wird, da hat Kuju schon mitgedacht damals. Fehlernummer weiß ich allerdings nicht auswendig.Die mdmp sind auch dann nicht zu verstehen.
Habe es probiert, als auch einem erfahrenen Programmier vorgelegt 
Luascriptfehler können einen b2d auslösen, aber es gibt auch Skripte, die einfach sich so oft laden, dass der Ram vollläuft. Hatte sowas mal bei irgendeiner Freewarelok 2012/13, da war eine Zählschleife nicht geschlossen und hat immer und immer wieder abgefragt, bis es nicht mehr ging^^ Vermutung kommt daher, dass man bei keiner Veränderung im TS zusehen konnte, wie der RAM langsam hochzählt^^
Vertexfehler kann auch DirectX, PhysX oder der GraKatreiber sein. Außerdem treten die bei mir nur im Editor auf, regelmäßiges speichern mittels F2 schaffte da eigentlich Abhilfe, dürfte den Buffer wieder neu initialisieren. Besonders beliebt ist hier wohl die Tracks.bin und dabei alles mit Gleislinks. Scheinbar wurde hier zu wenig Spielraum gelassen oder im Code Mist gebaut, verstanden habe ich den Fehler mit Ursachen jedoch noch nicht.
Allgemein hilft es auch selten benutze Assets/Strecken auszulagern und eben auch nach 0-Byte-Dateien zu suchen.
-
Prelli, es gibt aber auch 53.X Fehler und andere.
Das wäre mir neu. Meines Wissens gab es diese Meldungen nur bis etwa September 2015 unter dem TS2015, der eine 53er version hatte, kurz bevor der TS2016 herauskam, der eine 54er Version hatte. Andere Zahlen kenne ich nicht und nach meiner Beobachtung geben diese lediglich die Versionsnummer des TS an.
Vertexfehler kann auch DirectX, PhysX oder der GraKatreiber sein.
Schon möglich, aber bei mir war es reproduzierbar immer Arbeitsspeicherüberlauf und niemals ein Grafikproblem. Wäre es ein DirectX-, PhysX- (was hat das mit Vertex zu tun?) oder Grafiktreiberproblem, wäre das ebenfalls reproduzierbar und außerdem beständig, egal wie voll das Ram ist.
Allgemein hilft es auch selten benutze Assets/Strecken auszulagern
Das ist ein Irrglaube. Assets und Strecken, die nicht benutzt werden, schmälern nicht die Stabilität. Die benötigen nur Platz auf der Festplatte.
Tut mir leid, dass das hier so nach Offtopic abdriftet. Ist aber ein interessantes Thema.
-
Nein, aber Windows 10 berechnet die Programme jetzt anders von der Auslastung.
Bei mir zeigt Win 10 die Auslastung genau so an wie auch unter Win 8.
-
Wurde ja bereits von den Mods dankenswerterweise ausgelagert. Hier können wir genug OT betreiben
Zu den Vertexfehlern ziehe ich die Informationen aus diversen Beiträgen hier im Forum, manchmal half da anscheinend ein Update genannter Faktoren. Ich hab ihn zum Glück so selten, dass ich mich nicht näher beschäftigt habe.
Den letzten 53.6 Fehler habe ich laut Log am 28.01 gehabt.Wäre auch mal einen Wikieintrag mit Erfahrungen wert...
-
Ok, ich muss mich korrigieren...
Der TS2016 hatte eine 50er Versionsnummer, weswegen du auch noch im januar einen Crash v53.x irgendwas haben konntest.
Der TS2015 hatte eine 40er Versionsnummer.Ich bleibe jedenfalls dabei, dass das nur die Versionsnummer des TS ist und kein Fehlercode.
-
-
hat jemand gerade ne 151 zur Hand und kann sagen, was die braucht?
-
Um die 140 MB.
-
Würde ich vom Umfang als mindestens gleich bezeichnen. Zumindest etwas Optimierung sollte da drin sein. Vielleicht kann ja langfristig ein KI Taurus dazukommen.
