Thre are 563 elements, meaning there is a total of 563 named files like for instance Kuju, DTG, RSC, Pad-Labs, Scarlet, vizzart, VirtualRailroads etc. All of that in total amounts to 563 files in the Main-Assets folder.
Ok I will try that now, thank you 
Should I also let DTG and RSC in the Main-Assets Folder also?
Should I also let DTG and RSC in the Main-Assets Folder also?
No, thats not necessary.
Only "Kuju/RailSimulatorCore" contents basic important files like portals, markers, etc the TS cannot run without.
No, move out of Assets into Assets again at will.
TS must not be running of course and needs to be restarted.
Noch mal zu der bisherigen Diskussion:
Die Verzeichnisse in Railworks/Assets sind nicht zwangsläufig auch die Provider-Ordner, für die der Cache, d.h. die Blueprints.pak Dateien erstellt werden. Das können auch Verzeichnisse sein, die eine oder mehrere Ebenen tiefer liegen. Typisches Beispiel sind die Ordner DTG und RSC. In diesen Ordnern liegen die Verzeichnisse für die jeweiligen Strecken und Loks/Triebwagen. Und erst diese Verzeichnisse bilden dann die Provider. Somit kann man aus der Anzahl der Verzeichnisse im Asset-Ordner keine wirklichen Rückschlüsse auf die Gesamtzahl der zu erzeugenden Blueprints.pak Dateien ziehen.
Das Logmate-Protokoll, dass hier gepostet wurde, zeigt eindeutig, dass die Cache-Erzeugung ohne Absturz bis zum Ordner Yohan\BB66000 funktioniert hat. Erst als der TS in den nächsten Ordner gegangen ist, kam es zum Absturz und das Protokoll endet abrupt ohne weitere Eintragungen. Von A bis Y (Yohan) braucht man deshalb nicht nach dem Fehler suchen. Damit kam der TS klar.
Die Frage ist nun, gibt/gab es in der betroffenen Installation ein Verzeichnis, in das TS gewechselt ist. Dabei geht der TS streng alphabetisch vor. Gibt es ein solches Verzeichnis, dann sollte man dort nach dem Fehler suchen (also am besten das Verzeichnis verschieben). Wenn man im Dateimanager in der alphabetischen Reihenfolge kein weiteres Verzeichnis findet, dann es ist nicht die altbekannte Problematik, dass der Consist Builder keine vernünftige Fehlerabfangroutine hat. Dann dürfte es eher an Memory-Fehler-Problematik liegen, die seit kurzem immer häufiger auftritt und für die bislang keiner einer vernünftige Erklärung gefunden hat. Das Logmate-Protokoll spricht aber eher für die erste Variante, da am Ende noch eine Zeile für eine neue Blueprints.pak-Erzeugung begonnen wurde.
Und was das Cache-Löschen betrifft. Das heißt eigentlich nur, dass alle Blueprints.pak gelöscht werden. Blueprints.pak müssen gelöscht werden, wenn sich in den Provider-Verzeichnissen etwas geändert hat. Weil ansonsten in den Blueprints.pak falsche Angaben stehen. Dieser Cache ist überhaupt nur da, damit der TS nicht alle Millionen an Dateien im Asset-Ordner lesen muss, sondern erst einmal nur die bestehenden Blueprints.pak-Dateien. Je nach Installationsmenge können das schon mal 1500 sein oder wie hier über 3000 (was allerdings wirklich etwas viel erscheint). Man darf dabei nicht vergessen, dass im Asset-Ordner auch alle anderen Objekte enthalten sind, Vegetation, Gebäude, Schilder, Signale, etc.. Damals hat man es noch nicht für nötig gefunden, das Rollmaterial getrennt zu behandeln. Worunter das TS-Menü bis heute (und bis zum Ableben des TS) empfindlich leidet.
Ok danke!
If the problem is after the Yohan folder then deleting everything below it in alphabetical order (Y to Z) should eliminate the crash problem, no?
Try it step for step, not all in one step. Try first only the next directory. If I understood correctly, you deleted already the whole Yohann folder. In this case move the next directory out offside the Assets folder. If you are unsure, make a screenshot from the directory structure within the file manager and post it here. Don't do too much in one step. You like to have a nice TC installation after the error correction, not only a partially deleted. (A hint, if you didn't it before: a backup before further steps could one of your best friends )
I already have a full backup of all my files on an external hard disk. Thanks for your detailed explanations so far!!
EDIT: I have begun manually re-adding folder files in the main Assets folder and testing the consist editor. I've come up with a crash again with the latest batch of 19 files, before that batch I didn't have any crashes. I am posting the new Logmate here below. I really really hope this is not a memory problem, I still have about 450 folder files to manually add after this new crash.
Das Protokoll sieht aber nicht aus, als ob beim Consist Builder mitgelaufen ist ?
Eine Frage: Welches Betriebssystem verwendest Du? Ich habe heute gesehen, dass Windows 10 zumindest seit 1903, bei 16 GB Hauptspeicher nur eine Auslagerungsdatei von 2 GB anlegt. (Wenn W10 die Auslagerungsdatei selbst verwaltet.) Ich habe heute mal die Auslagerungsdatei auf 16 GB mit max. 32 GB erhöht und bislang hat sich keine OOM-Meldung mehr herausgetraut.
