TRS19 Crash to desktop

ctclark1

Member
Build 110497. Windows 10 x64 Build 20H2. AMD Ryzen 7 1700 @ 3GHz. 16GB RAM. Radeon RX580.

Program crashes to desktop (no messages, no freezing, just GONE in an instant), I've narrowed to what appears to be trying to load a specific asset... But I have no idea how to figure out what one it is. It's always as I approach a certain area within ground view. I've tried zooming in from the map level over the area and it also does it as soon as it begins loading the actual assets into view. I've narrowed it down to the primary TOP Route Layer (turning off that layer and leaving other route and session layers allows me to move into the area, but as soon as I enable the specific layer while in the area it crashes. It's not something that I can remove that layer and start over either, because it's the layer that EVERYTHING is built on). There's roads, bridges, tracks, switches, industries, buildings, signals, and trains in the area, so it literally could be anything.

  • I've done multiple extended DB repairs.
  • I backed up the route/session, deleted everything from my data folder, and reinstalled Trainz from scratch and redownloaded all assets for the route fresh from the DLC. (in case an installed asset was corrupted)
  • In the process I've run the "Delete missing assets" command a couple of times now, just in case, but there are no missing assets.
How can I find out what asset it is and remove it from my route? This is clearly something that has happened outside of my control because I was able to place whatever asset this was and it didn't crash previously, however I've been working in a different area of my route for a while and hadn't ventured into the area causing the problem in a while, so I can't say for certain WHEN it "went bad".
 
I did have similar experiences and after a lot of trial and error check my Virtual Memory. As is normally the case it was set to C:\ and I determined that the space available was not sufficient.
I moved VM to a larger drive and removed it from the C drive.
 
ctclark1 - When such an abrupt CTD occurs, the first thing to check upon restarting TRS19 is any 'Open for edit' items listed in Content Manager. (Resolve these by either submitting edits or reverting to original).
Does Content Manager reveal anything when you run the 'Faulty' (assets) filter?

Suggest list the dependencies for the route and check to see if there are any 'Unknown assets' or 'Missing dependencies'.
If certain assets show up in Red and declared 'Faulty', right-click the selected faulty asset to 'View errors and warnings'. Fix these if you can, or list them here for further help.
Also check for 'Updates available' and sort those out too before attempting to reload that particular route. Ensure you have the latest versions of any DLC packages you're entitled to by checking their status in the Content Store of the Launcher.
 
The other thing to try if this continues is process of elimination.

Disable all content except for built-in. Load the route. If nothing crashes, add 100 or so items by enabling them in Content Manager them. Repeat the test, and then continue until all your content is unhidden, or until there's a crash. You'll find that the usual Murphy's Law rules apply here because it's always the last asset you enable. :)

The other thing to keep in mind is what did you add recently in that particular area of the route. I recently went through this with an awful performance issue on a tightly packed route. In general scripted assets tend to cause the problems the most. Ensure your scripted items are all up-to-date. In your case, it could be a trigger calling a script that's causing the failure in that particular location.
 
As always, it is worth checking the number of Daily Backups set in the Dev section of the Launcher Settings. By default this goes to 7 and will chew up your HD space in no time, thus reducing the space available for VM or swap file to next to nothing. Set it to 1 or even 0 to overcome the issue.
 
I've resolved all Open for Edit items, the only ones which show up after crashing are the Route/Session which has crashed. I've tried both Submitting Edits, and Reverting Unsubmitted Edits, the program still crashes entering the same area.
There are no faulty assets.
No Unknown assets or Missing dependencies.
I've forced an update on every asset possible. This was part of my rationale for completely reinstalling the game and forcing all DLS content to re-download. The only items I installed from local CDPs were dependencies which were not on the DLS such as coronas. But without some kind of log which tells me the last asset which the game tried to load (which I don't see anything of the sort in the "Show Logs" window), I have no idea what it is to attempt to resolve it.

In previous troubleshooting steps, as I said, I've performed countless Extended DBRs to no avail. Nothing has changed on that front either, an Extended Repair still results in the same thing happening. The only red items from this, and they've been that way since I bought TRS19 (which was BEFORE this issue was occuring) are:
Code:
  - <NULL> : Failed to download precached data for package 'sc276d_1' at version '12345' for platform 'standard-3'
  - <NULL> : Failed to download precached data for package 'sc276' at version '12345' for platform 'standard-3'
  - <NULL> : Failed to download precached data for package 'sc276f_0' at version '12345' for platform 'standard-3'
  - <NULL> : Failed to download precached data for package 'sc276d_0' at version '12345' for platform 'standard-3'
  - <NULL> : Failed to download precached data for package 'sc276f_1' at version '12345' for platform 'standard-3'
  - <NULL> : Failed to download precached data for package 'sc276s' at version '12345' for platform 'standard-3'
  - <NULL> : Failed to download precached data for package 'sc276f_2' at version '12345' for platform 'standard-3'
(As I said, these have been a problem since day 1 of TRS19. I've previously accessed this area of the route since then.)

There is no change in behavior. It continues to crash every time I approach that area. See the video.
https://youtu.be/e4yNFFiF9DA

With regards to the VM suggestion, I have 16GB of RAM, a 2GB page file, and neither is near their maximum usage when this occurs, nor is there any spike in usage at the instant it crashes. There is no spike in disk usage for the drive storing both the program and the data (Corsair SSD, separate from my system drive) nor any change in activity from my graphics card except for the resulting crash which no longer requires any GPU usage so it drops to no use. I have no reason through ANY of the available evidence that this is system related, especially considering that area was previously accessible on this same system a few months ago.
 
I noticed in the video that you have quite a few background processes icons in your system tray. Each of these eat up valuable memory. During a high stress moment in the TRS program (such as moving to this area), it could be that the system is checking for available resources (without actually ramping up) and deciding that they are not available, so it closes the program.

I have 20GB RAM and things ran much better once I increased my page file to 32GB.

The rule of thumb for page file size is generally 1.5x your physical RAM, minimum. I'm not sure how you have been able to run on a 2GB page file.

I would try upping your page file to 24GB and see if that solves it.
 
Yes - Windows 10 simply does not automatically allocate sufficient virtual memory/ page file space for certain Trainz 'error-handling events'.
My recommendation is to always allocate twice or three times the amount of physical DDRAM you have installed on your rig to virtual memory.
This can be spread over more than one HDD or SSD and some of that page-file space should definitely exist on the same drive as your Trainz installation.
A few years back, during a horrendous beta-testing period with T:ANE, only 90Gb of page-file space allocation allowed me to troubleshoot and identify the source of persistent CTDs caused by a particular faulty built-in locomotive!
 
The rule of thumb for page file size is generally 1.5x your physical RAM, minimum. I'm not sure how you have been able to run on a 2GB page file.
Let's try "Because I understand paging files for $200, Alex"
The 1.5x recommendation is such an antiquated wives' tale that it's laughable. This hasn't really been applicable for most users since Windows 9x/ME with horrible memory management and severe RAM size limitations. At that time, you needed enough space to swap nearly all of your core memory in order to multitask effectively. Programs would quickly use up all the available memory through bloat and poor management, and so when switching tasks Windows would move the now dormant information to the swap file, and move the now active information from the swap file to RAM. The reason for 1.5x was related to having enough free space in the swap file that it could move large chunks (because it had to write it to the HD before it could release it from RAM) without overflowing the swap file. Write a large chunk from RAM to Page, free up that chunk of RAM, move a different large chunk from Page to RAM. Repeat. If you constrained the page file to be too small during that time, it would have to move much smaller chunks back and forth at a time and therefore took longer and thrashed your drive more trying to find the appropriate blocks in the page file to move back and forth.

I also hate to burst a bubble, but Windows (at least, in recent versions... maybe the 9x versions did? I don't remember, considering it's been almost 20 years since I've used a 9x variant regularly) doesn't just close a program if it can't find resources. It'll warn you first. It'll tell you you're out of memory, maybe prompt you to save something to close a program, or crash hard. It won't just wipe out an active program if it's out of memory. I can tell you that the way in which TRS is closing, Windows sees it as TRS closing itself out. It's not Windows freaking out. If for some reason as you imply TRS is closing itself because the resources aren't available, well then that's horrible programming.

Letting Windows handle it's own page file size nowadays is nothing out of the ordinary and is perfectly acceptable. It's much better at memory management than it used to be in the '90s and (very) early '00s.

Just for S's and giggles... upping my page file to 30GB didn't change a single thing, FYI. Let's stop blaming Windows here please. If TRS can't successfully dump the information that's causing it to crash, that's not on Windows and has nothing to do with memory management, that's on TRS and I'm not going to create a page file that takes up an entire 256GB hard drive in an attempt to catch it.

Catching errors is such a basic component of programming. Writing a line in the log showing a critical failure when loading a specific asset should be the program's last dying breath if it's going to crash out. It should be the last action of an error handling function that should catch the critical failure before the executable dumps out. That's seriously Programming 101, and shame on the programmers for not being able to make it do that.
 
The crashdump.txt file in your local data folder is the log you're referring to. (Obviously only useful to our programmers). So send that in with your report.

The best way to troubleshoot this type of issue is disable the deps, restart and retest. Then enable various sets of content until it crashes. By narrowing down the offending asset we'll then be able to harden the code against that condition.

Also, if you're not using the latest beta, then I'd suggest creating a copy of your install folder and local data folder, and retest there. The beta version has assertions enabled which, if triggered, will help identify things as well.
 
Last edited:
Through trial and error of disabling everything except the TransDEM produced assets, and slowly re-enabling, I believe I've narrowed it down to either of two styles of track, <kuid2:368725:49035:1> Protrack NSWGR dirty brown stone, old timber, baseplated and/or <kuid2:368725:49037:1> Protrack NSWGR dirty brown stone, old timber, baseplated, rusty rail. I believe it's actually the first one, as when I disabled that but left the rusty variant enabled it crashed in a different manner (as soon as the route loaded, before I even had a chance to move towards the faulty area), whereas enabling the first with the rusty disabled still allowed me to move towards the area before it crashed.

At one time, I thought this was the gold-standard of US rail, and swear that I had gotten it off the DLS, but it's listed as Third Party now. I have seen now that Bob MSGSapper has created new rails, would these be a good replacement? And, I guess the bigger question, can I do a mass Asset Replacement on disabled assets, or do I need to re-enable the NSWGR rails and tread carefully until I can make the replacement?

Tony, would it still be helpful to submit the crash report to determine what might be going wrong with the asset to cause it? Or is it a moot point?
 
Back
Top