TS2021 has become to the point of almost being unplayable for me because of constant out of memory crashes. 32 bit is more stable but it still happens frequently, 64bit is much worse. This happens on 3 different systems, one of which is a brand new build. Any suggestions? Has DTG done anything to address this? Is it worth submitting at ticket? Thanks!
If we had a few more details of your computer specs and settings we may be able to help a little more?
Just uploaded my DxDiag from my main system, what settings would you like to know? The previous system this build replaced no longer exists. I also run on a laptop from time to time which was certainly not meant for gaming but it runs TS2021 pretty decently with lowered graphics settings. The game won't even load on it without an out of memory error. I can get the specs for that if you like?
Same issues here. Constant OOMs when loading anything. My specs: CPU: Intel Core i5-8600K GPU: Nvidia RTX 2070 Super RAM: 16GB DDR4 I also got my DX diag.
When do you get the OOMs? As it Loads? Get to the menus? Open a scenario/route? As TS loads = look lower left it will say about loading/saving the scenario database does it crash then? In windows search "View Reliability History" any error message or technical details at the time of the crash. Have you run any Windows diagnostics? Google sfc /scannow - any errors DISM commands? Your DXDiag file has some entries I need to research further! Have you tried Verifying the Game files via Steam? Windows key plus r/R - winver - OK OK looking at the dxdiag reports you have several problem signature issues with various windows apps including TS - so you may have a windows issue? What version and build of Windows are you running?
This build is about 2 months old, Windows 10 Pro, not sure of build I would have to check. It happens at various times, during loading, during the menu screen, playing the game, doesn't matter. Have not done any Windows diagnostics, have verified game files. I'll have to try the "View Reliabilitiy History" I've run workshop content for years and this only started happening recently, and if you spend any time on the forums I'm certainly not the only one having this problem.
To clarify I only have experienced OOMs while attempting to load scenarios sometimes also happens in the QD consist editor and yes I have also used workshop stuff for years.
Have a look at this post - it seems to have helped some people https://forums.dovetailgames.com/threads/out-of-memory-crashes-page-file-problem.22918/ Peter
I have the same problems and a friend of mine (new to TS, no workshop content so far) as well. The suggestion with the page file helped a lot. I've set it to 50 GB and onto the second internal SSD, so loading and buffering is done by two independent controllers and drives. Still the OOM-crashes occur - sometimes when I open the scenario editor, or when I start to play a scenario, or even when I scroll through the scenario-list. Before quitting TS I always clear the TS-cache in the settings-menu - this helps quite a lot to prevent the crashes (in combination with the page file-option).
The ultimate solution involves using Steam to delete and then reinstall TS. At least, that's what worked for me after I gave up trying to run all of the tests and assemble all of the information DTG demands before even attempting to solve OOM crashes. Given my 324-strong collection of TS DLC, this process took several days, but it did resolve the situation.
I posted on the other thread about oom and page file system. I run ts2021 64 bit ok but when I close ts2021 down I am greeted by the white box with the oom message. Strange as it has just run OK.
I have WIN 7 Pro, with 16GB RAM, my TS2021 is on an SSD, I always now play the game in 64-bit, I don't have a disc defrag setting for an SSD, or, the need to clean it, so, how can we eliminate these OOMs on SSD's, any ideas please? I have no subscriptions to anything currently on Steam Workshop. Cheerz. Steve.
Steve You should already have the TRIM (garbage Collection) function on Windows 7 https://www.howtogeek.com/257196/ho...nabled-for-your-ssd-and-enable-it-if-it-isnt/. That's all you need wrt a SSD. I run it weekly in Windows 10 putting defragment in the search window - not sure on the Win 7 command. Note: My TS20XX SSD has very little "garbage" due to the low number of writes that TS generates. Its a different story with the System drive (C:\) that generates a lot of writes and needs regular cleaning. Cleaning, defragging, trimming any hard drive/SSD will NOT cure a TS OOM. They are usually due to a mismatch between the VAS and the Physical RAM, resulting in an INVALID page Fault aka OOM. Other (rarer) causes include sounds invoking a DEP error and DirectX9.0c unable to access a VAS address. Due to the individuality of our PC systems, these OOMs are difficult to diagnose and "fix". In your case with 16 GB of RAM installed it only needs 1 x 4K page out of around 4,200,000 x 4K pages to be not matched - OOM. They refer to the paging File above - what everyone forget is that unlike RAM the paging file RETAINS any data even when your PC is switched off and back on again. The paging file should always be cleared on shutdown, otherwise it tends to fragment and possible corrupt. https://www.howtogeek.com/282049/ho...ur-page-file-at-shutdown-and-when-you-should/ One of the reasons that changing the PF size works is that it is moved to a different address on the SSD/HDD and is no longer fragmented or "corrupt", not because of any increase in the PF size. In the past I have run some very serious CAD software with only 4GB of RAM installed and I have never seen the peak commit charge on the PF - exceed 4/5GB, so a PF of 6GB would be more than adequate. The larger the amount of RAM installed means that the PF is less important (especially if you do not use it to record the windows (error) log reports) - its main function BTW. It is still wise to have one. At present with 32GB RAM I see a peak commit charge of <1GB, so use a PF of 2/4GB min/max. It would be more useful for simmers to free up standby RAM regularly than have huge PF files that can contain confidential and error provoking data for ever!
Super advice thanks ever so much Peter. My TRIM was already enabled, but, I've now altered the clearpagefileatshutdown setting to 1, so, that should clear my page file now. I will monitor things for the next few weeks and see what happens. Cheerz. Steve.
Marts etc TRIM is not defragmenting - simply it merely releases blocks that have been previously written to and not released. https://en.wikipedia.org/wiki/Trim_(computing)
Any news on this topic? I've been having OOM after 5 to 10mins during scenarios, on a clean install with only RSSLO content and a few mods. I've done everything you have all suggested. From TRIM to clearing the page file on shutdown to setting the page file size to match my 16gb ram. I'm using an M.2 SSD, and my specs are more than enough. Is there anything more I could try apart from running with lowered graphics? It's been getting really frustrating, especially knowing that basically almost nothing will or can be done to the core engine in the future.
Yes, I think this OOM is the new SBHH.......How many of you remember those? Has this been occurring since the new updated game version to TS2021 late last year, can anyone remember? It's certainly something ''under the hood'' in the game, as so many of us are experiencing them, and we all have different machines and specs. Cheerz. Steve.
Steve Yes - SBBH - Access Violation - Memory Mismatch - OOM - 0xc000005 and so on. Been with us since 2012 in my experience. In 2017 I conducted a "very loose" meta analysis of all OOMs reported on the then forums and 99% were due to the simmer less than 1% for steam and TS. QJ To help you we really need your full PC specs, including monitor refresh rate and resolution, type of video card and settings in the Nvidia control Panel (or AMD equivalent) and settings in TS. Does this happen in ALL scenarios? What is RSSLO content - is that the same as DTG/RSC? Have you run any windows diagnostics such as sfc /scannow, DISM, dxdiag, Chkdsk (Google these if you want to use them) OOM's in TS have been with us a long time, so it is a complex issue not easily solved.
SBHH was ''Something Bad Has Happened'', DTG got rid of that year's ago, however, this OOM screen dump has only been around since last year, to my observation. I haven't seen this screen before and I've been here since Kuju days in 2007. I am not technically minded Peter, being very ill, so, I don't bother to run diagnostics etc as a matter of course. I only worry when major things happen, such as this issue, I gloss over other little things if they don't mess up with my enjoyment of the game, and this does, as it happens on any route, I don't even need to be driving, I had one the other day when in editor changing some vegetation over and it crashed, so, it happens at any time on any route. RSSLO is a 3rd party creator from Slovenia by the way, they develop routes and locos/rolling stock, etc. RailSimSLOvenia. Cheerz. Steve.
I find I usually get an OOM if I’ve installed something new, or tampered with the equilibrium of TS (!). I just treated myself to a couple new AP items, and trying to make a new QD consist resulted in an OOM, but a clear cache and restart, and all back to normal.
Steve I didn't make myself very clear: SBHH was the old way of telling us simmers that we had an OOM - it eventually morphed into the current OOM and the prevalent error has always been a 0xC0000005 error aka memory mismatch - access violation and any term that you want to apply. So what I am saying is that SBHH is the same as OOM just a different acronym. In the days pre 64-bit TS-20XX, under Windows 64-bit the sim could only access a MAXIMUM of 4GB of Virtual Address Space, BUT up to 192 GB of RAM (OS dependant) - the VAS easily became fragmented and lost contiguous space for TS to load into - SBHH - OxC0000005 error. It was even worse if you ran Windows 32-bit then the VAS dropped to a hack maximum of 3GB minus the VRAM on your vide card. Now running 64-bit OS and TS in 64-bit if the flags have been set correctly then TS can access up to 128 TERABYTES of VAS and any amount of physical RAM. But we still get OOM's probably due to Invalid Page Faults and some sound errors (ie sound code bypassing the MMU and loading directly into the RAM). Simply put, the editor accesses the VAS and RAM extensively - but in some edits TS is slow to release RAM addresses. that you have just written to. In the editor you are now creating new code in the VAS - it tries to load that code into the RAM - but because TS has not released the RAM addresses from a previous edit - these addresses can't be accessed - invalid page fault - OOM - TS crashes. Moral save any edit however small frequently - that usually clears the issue. Plus, because we now have a massive VAS - the editor writes to an address in the VAS - but there is no corresponding address in the RAM, out of range, system reserved and so on - invalid page fault - OOM TS crashes. Bottom Line SBHH is the same as OOM just a different descriptor. Can these OOM errors be fixed? Unlikely without a massive re-code/new code of the TS base code in 64-bit.