Eine AccessViolation hat erst mal gar nichts mit 32 oder 64bit zu tun. Das kann in beiden passieren. Der TS ist nun mal in purem C++ geschrieben und da hat man sich als Entwickler eben selbst um das Speichermanagement zu kümmern. Das war ja schon seit je her ein Problem im TS. Nur führte das bisher nicht unbedingt zu einer AccessViolation, sondern es wurden einfach Speicherbereiche nicht leergeräumt und nach einem Neustart des TS wurden selbe neu "adressiert" und benutzt, also mit den alten Daten da drin (daher rühren zB die Meldungen im LogMate der nicht gefundenen Kurvendaten eines Gleissegments). Das fällt dem Normalnutzer kaum auf, aber als Entwickler bekam man das zu spüren. Jetzt, nachdem die den Code umgeschrieben haben, haben sich wohl tatsächlich dort Dinge eingefunden, die da vorher nicht waren. Also neue Bugs. Ich gehe davon aus, dass halt hier und da wirklich eine Speicheradresse mehrfach reserviert werden soll und da knallts eben sofort. Das ist in C++ nicht erlaubt und führt sofort zum Absturz der Anwendung. Wo genau der Fehler da nun liegt, ist sicher festzustellen und der TS müsste dazu mal komplett debuggt werden, was ewig dauern könnte. Ich bezweifle, dass das noch passieren wird, leider. Genauso wie die Fehler in den Bin Dateien, die beim Abspeichern jetzt ab und an entstehen. Da ist einfach ein blöder Bug reingerutscht beim Umschreiben des Cores. Den gilt es zu finden, aber irgendwie zweifel ich auch da stark, dass noch was passiert. Läuft ja alles, wenn man nichts all zu kompliziertes bauen will.