Atomic Systems

I have, today, encountered a problem that wasn't here yesterday.

I load up TS2015, but it crashes with a dmp file error on "Updating Scenario Database." It is currently v51.2a, and I didn't see any untoward behaviour yesterday.

Can anyone help me fix this?

What was the last thing you did/altered/installed in TS?,

Last thing I did? A GGS scenario on the Liverpool-Manchester route.

Installed: Some workshop scenarios by Elphaba.

Drogba11CFC wrote:Last thing I did? A GGS scenario on the Liverpool-Manchester route.

Installed: Some workshop scenarios by Elphaba.

Ok, so assumimg you have cleared cache whilst trying to fathom out what is going on, you could simply back-track and remove each in turn of the scenarios you mention and see if that identifies the culprit.

Or, you could try running such as 'Process Monitor' (Google it, it's freely downloadable and legit), which will flag up the very last file that TS tries to process before starting to create the .dmp file. I use this option if the cause of a crash is not readily apparent and 9 times out 10, I find that whatever item/scenario/DLC that this last file appertains to, this is the cause and once removed/reinstalled, all returns to normal.

Hope this helps,

Richard

I've had exactly the same problem - but it dumps out as it tries to save the scenario database.
Problem started after I had installed some freeware foreign routes and I can't readily
remember what they were.
Eventually TS will start up okay though, sometimes on the second attempt, and rarer
on the third or fourth attempt.
When I close the game down though, it invariably dumps out.

I've verified the cache, but I'll download the Process monitor as well.

No success; it still freezes on "Updating" despite the cache verify and I don't know what to search for in Process Manager. I fear that a complete reinstall may be necessary.

Just remove all those scenarios you've recently added before getting drastic.

I had the same issue exactly.

This was caused by too many scenarios for the scenario database to handle according the DTG.

You would either need to delete some scenarios ( a temporary measure at best) or, create 2 separate route folders ( split my US routes off). You would then swap them round depending on which set you want to run when starting the simulator. I also have 2 separate SDB.bin files which get created when saving the scenario database at startup which cuts load times as the updating does not need to effectively swap the US and non US every time.

Drogba11CFC wrote:No success; it still freezes on "Updating" despite the cache verify and I don't know what to search for in Process Manager. I fear that a complete reinstall may be necessary.

I will admit that the list of info given by ProcMon can be bewildering, but bear in mind the sheer number of operations a system can perform per second.

What I do is to set it to scroll the information it shows, and then run TS and get ready to stop the scrolling at the very moment the sim crashes. Of course, in the very short time from seeing the crash to stopping ProcMon, your system will still have processed 00's (000's?) of files so it is a case of being patient in looking up through the data listed until you spot the point at which a .dmp was called. Above here somewhere will be the last TS file processed before the crash took place.

Time consuming it is, but I find it a useful way of pin-pointing exactly what it is that is causing the sim to 'gip', as it were,

Richard

Interesting. How would I have two separate sdb files?

rfletcher72 wrote:

Drogba11CFC wrote:No success; it still freezes on "Updating" despite the cache verify and I don't know what to search for in Process Manager. I fear that a complete reinstall may be necessary.

I will admit that the list of info given by ProcMon can be bewildering, but bear in mind the sheer number of operations a system can perform per second.

What I do is to set it to scroll the information it shows, and then run TS and get ready to stop the scrolling at the very moment the sim crashes. Of course, in the very short time from seeing the crash to stopping ProcMon, your system will still have processed 00's (000's?) of files so it is a case of being patient in looking up through the data listed until you spot the point at which a .dmp was called. Above here somewhere will be the last TS file processed before the crash took place.

Time consuming it is, but I find it a useful way of pin-pointing exactly what it is that is causing the sim to 'gip', as it were,

Richard

Just before it wrote the .dmp file it was reading locale.nls. The last Railworks file was cudart32_30_9.dll.

Drogba11CFC wrote:Interesting. How would I have two separate sdb files?

Start TS2014 with say all the non US routes (my example only) and it creates an SDB.bin file in the Content folder.

When for example you want to swap to the US routes, rename the respective Route folders , take a copy of the SDB.bin and call it say SDBMain.bin. The when starting TS2014 the SDB.bin will be re created with just the US routes. Now you have 2 Route folders each with a matching SDB.bin.

Rename each paring depending on which set of routes you want.

Obviously you lose the ability to have all routes available in a single session.

The alternative is to store more routes using Mike Simpson's Store IT program. Either approach works but for me I have more routes readily available without remembering which commonly used ones are stored.

chrisreb wrote:I had the same issue exactly.

This was caused by too many scenarios for the scenario database to handle according the DTG.

You would either need to delete some scenarios ( a temporary measure at best) or, create 2 separate route folders ( split my US routes off). You would then swap them round depending on which set you want to run when starting the simulator. I also have 2 separate SDB.bin files which get created when saving the scenario database at startup which cuts load times as the updating does not need to effectively swap the US and non US every time.

That seems to have worked.

Good news indeed if you can now play the game although sadly a new workaround to get it to work.