Database rebuild fails & TRS19 stops working

[Lataxe]

As I was downloading a few few DLS items today in TRS 19 Platinum, I got the Windows 7 BSD. That's a first. In the past Trainz has only stopped from within Driver of Surveyor; and no BSD just a CTD. There's no obvious reason for this as only Content Manager was open and the download was only of a few new assets within normal size that appeared on the DLS today.

Windows 7 restarted with no issues so I restarted TRS19 Platinum. Selecting any of the options from the splash screen instigated a database rebuild. This proceeded until halfway through the "checking for faulty assets" section (at around 260,000 of approximately 490,000). The process then stopped with a message box saying "TRS 19 has stopped working". The program then closed (back to the desktop). No other program was running other than the usual background processes that always run when the computer is on.

Running with Task Manager open, the single process running is TRS19.exe, as the database rebuild proceeds. It's using up to 5Gb of the available 13Gb of memory and up to 96% of the CPU capacity.

Is there any known fix for this issue or am I going to have to do without TRS 19 and submit a ticket to whatever it is that one submits faults to in N3V?

My last full (synctoy) copy backup of TRS 19 folders was a week ago, although I've done little in it since then. Is a copy of the whole shebang (97.5Gb) my only probable fix?

Thanks in advance for any advice you can give.

Lataxe

 

[JCitron]

A BSOD is not good and is usually a sign of something significantly wrong such as a corrupted OS, drivers, or worse, a hardware issue. I recommend running system checks of some kind, verify data, memory tests, disk checks, and so on to ensure it's not the computer its self.

The DBR really does eat up a lot of physical RAM as it opens up and checks the data. This opening up of the compressed files, yes all the content is compressed, takes a lot of CPU to do so and RAM as well. I was able to get around this issue by creating some very, very large permanent swap files on my local hard disks. Instead of using the 1.5 times rule for swap files (page files), I doubled that on each file.

But before you do that, run a chdsk on your hard discs to ensure they're not failing or have other data issues because if there's a problem with those, then this will be for naught, and changing the page file size may cause other problems as well.

 

[Lataxe]

A BSOD is not good and is usually a sign of something significantly wrong such as a corrupted OS, drivers, or worse, a hardware issue. I recommend running system checks of some kind, verify data, memory tests, disk checks, and so on to ensure it's not the computer its self.

The DBR really does eat up a lot of physical RAM as it opens up and checks the data. This opening up of the compressed files, yes all the content is compressed, takes a lot of CPU to do so and RAM as well. I was able to get around this issue by creating some very, very large permanent swap files on my local hard disks. Instead of using the 1.5 times rule for swap files (page files), I doubled that on each file.

But before you do that, run a chdsk on your hard discs to ensure they're not failing or have other data issues because if there's a problem with those, then this will be for naught, and changing the page file size may cause other problems as well.

J,

Thanks for that advice. No hardware or other glitches revealed by various pokes about the Win 7 system via the various Computer Management and dic monitoring facilities.

I notice that the TRS 19 DB rebuild process fails with the memory usage shown as 7,791,654K which seems a lot and more than the usual circa 1-5GB of memory used when the there's a DB rebuild in Trainz. I might try that swapfile increase - although the PC does have 16GB of (all working) memory.

The Windows "TRS19 stopped working message" contains the following:

Problem Event Name: APPCRASH
Application Name: TRS19.exe
Application Version: 0.0.0.0
Application Timestamp: 5df8c2f8
Fault Module Name: ucrtbase.DLL
Fault Module Version: 10.0.14393.2990
Fault Module Timestamp: 5caeb96f
Exception Code: 40000015
Exception Offset: 000000000006e01f
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 2057
Additional Information 1: 74d7
Additional Information 2: 74d75f1f84e4eadd40e160561bfee185
Additional Information 3: 5108
Additional Information 4: 51084329f2917db310f63fd546a7a113

Do you have any idea if ucrtbase.DLL is a Windows or a Trainz DLL?

Regards,
Lataxe

 

[JCitron]

Try doubling your swap file.

That's good on the system and O/S side.

I have found that sometimes a bad asset, meaning one with some corrupted textures or a mesh, can really beat up the DBR process as it's checking the files. This may explain the extra RAM usage. Finding who the culprit is tough though.