Good Afternoon, I have installed Train Simulator on my new PC recently and from today, I keep getting an error when the Custom Consist Creator is loaded at 17% saying 'Out of Memory'. I am completely unsure why my computer would be out of memory since I have 16GB RAM and a 1050ti. It would be grateful if you could suggest on how to remedy this issue. It is very annoying and it happened on my Old PC too. If anyone has an idea on how to remedy it, that'll be good. The only thing I have done today is enable my XMP profile for my RAM.
The out-of-memory problem shows up all over the place it seems. I am afraid that DTG put out a "64-bit" version that might be compiled as a 64-bit executable, but which is not true 64-bit. I have a 16GB RAM system with an 8GB GFX card, and I run into the out-of-memory error when CPU memory usage exceeds around 4.2GB. This indicates that the "64-bit" version of TS2020 does not have proper 64-bit memory handling but is just a 64-bit build of a 32-bit project. Which, if true, is absolutely shameless!
With all due respect to DTG, the error message is misleading. Technically, the exception code generated is 0xC0000005 which does NOT automatically mean 'OUT OF MEMORY' at all. It actually means 'ACCESS VIOLATION'. They are not at all the same thing, necessarily. An Access Violation is simply where the program has attempted to access memory that it does not have sufficient privileges to read or write. Quite literally, the program has tried to overstep its bounds and use memory in areas that are considered off-limits - either by dint of being in use by the operating-system itself, or by another app running on the same machine - or even just accessing memory that has not been formally allocated to the program, just yet, anyway. You can prove this to yourself, somewhat, by looking at a couple of files in your Railworks folders - first is in the TempDump folder - called ErrorReport.txt. It's readable in Notepad or any text-editor, and is just a a normal text file. This will tell you the exception code, and adjacent there is a (clearly developer-overridden) set of info and help text there, which are, shall we say, rather generic and somewhat wistfully point the finger at 'A User-Land Problem'. Another text logfile to corroborate your analysis, can usually be found in another folder - Railworks\data\CrashReport\TS2018_Report.txt (yes, even in TS2020!) - This appears to be a crash-time telemetry file, which contains a lot of last-minute live dump data about settings and I have an as-yet unsubstantiated feeling that these may be routinely transmitted to DTG over the internet, when they are generated at each crash. If you ponder through that file, you'll usually see an exact record of how much memory was in use in each modes, as well as the very last entry usually being the max memory available on your system. In all of these so-called 'OUT OF MEMORY' crashes I've seen in TS2020, I have yet to see any where the committed memory in use by the program, as recorded by its own telemetry logging, was anything like near the level of my 16GB of installed RAM. I would hazard a guess that the exception code for 'Access Violation' has been 'flavoured' by TS2020's error-reporting system (as far as we users are concerned) for convenience - and not necessarily ours. Maybe it's a lot easier to handle complaints about 'Out of Memory' with the retort that "it is a user problem," than it is to explain that 'Access Violation' really means that "we're sorry, our program sorta just ran off the rails into main memory and got killed by the operating system for being a naughty boy." With every chance that nobody quite knows for sure exactly why... TS is a very old horse now - and much as I still love it deeply - it has a tendency to go bonkers in its paddock simply because someone touched its dinner bucket in a funny way when the moonlight was wrong, and it got spooked.
