Wie gesagt 0x0000007b ist ein Windows-Fehler. Sehr wahrscheinlich hängt das Update damit zusammen.
Die Out of Memory ist eine generische Fehlermeldung die von Railworks.exe kommt. Wäre es ein wirklicher Speichermangel, käme die Meldung von Windows, denn das verwaltet den Speicher und nicht RailWorks.
Viel Erfolg, es gibt kein allgemeingültiges Rezept um OOMs loszuwerden. Bei mir hat es geholfen, korrupte Assets zu korrigieren (es gibt genug davon).
Und das Verhalten von TS hängt auch vom PC Setup ab.
Ich hatte beispielsweise plötzlich Probleme, Bessemer & Lake Erie zu starten - immer OOM. Hab dann alle Assets durchforstet und einen Blueprint entdeckt, bei denen die internen IDs mehrfach vergeben waren. Hab die IDs neu verteilt und siehe da - keine Abstürze mehr. Dieser Fix hat auch bei anderen die das gleiche Problem hatten funktioniert. Wieder andere jedoch können die Route problemlos laden mit dem "beschädigten" Asset.
Da RailWorks kaum Fehlerabfangroutinen enthält - quasi nur diese eine Meldung die auch noch freundlich darauf hinweist man solle den 64 bit mode nutzen obwohl dieser einen gerade zum Desktop befördert hat, ist die Fehlersuche schwer. Eine Rolle spielen wohl Abweichungen die zwischen VAS (Virtual Address Space) und dem physischen RAM auftreten - das kann nur DTG wirklich fixen, sonst niemand. Der Trigger scheint in den meisten Fällen ein in irgendeiner Hinsicht unplausibler Blueprint zu sein - meine Erfahrung nach zumindest.
Ich habe bei G-TraX (hochgeschätzt, keine Frage) viele Blueprints gefunden die per Texteditor und Copy&Paste erstellt wurden, da haben sich einige Fehler eingeschlichen.