Beware - overlarge Kuju folder causes SBHH

[alanch]

Over the years I have installed an enormous number of downloads from UKTS and many other sites, and as we know many reskins install into the Kuju/Railsimilator or Kuju/RailsimulatorUS folders - eventually these reached 12GB and 4.1GB respectively, compared to default sizes of 2.97GB and 1.28GB. for some months many downloaded routes, including Cockermouth, Keswick and Penrith, and South West Wales would not load for me, either in the editor or to run scenarios - and Task manager showed I had plenty of my 3Gb of memory free. Everything had been carefully checked with RW-Tools and nothing was missing. The final straw came when Cresston, which used to work, wouldn't load!

At first I though I had installed a faulty file (or a few), so I compared the assets that the problem routes used, and carefully checked everything they appeared to use in common - no obvious faulty files. Then I ran some tests with Process Monitor running as the routes loaded - it was clear that the SBHHs were happening as assets loaded, but there was no obvious common factor - I checked each of the assets loading at the point the SBHHs happened, and there were no obvious faults.

Next step was to play around with reducing the list of blueprint sets in a RouteProperties.xml (South West Wales as it happened), and use that to open a test route of my own - reducing the number of blueprint sets allowed the route to open: it didn't seem to matter which asset sets I removed - but keeping the full set caused it to SBHH. My conclusion was that there is a limit on the number of assets that can be loaded, irrespective of whether there is free memory left. This may be why several people have had success creating separate installations with reduced asset sets for groups of routes.

My final step has been to remove my Kuju/Railsimulator and Kuju/RailsimulatorUS folders to one of my external drives, re-download them from Steam, and then just copy from my backup the missing assets required for the routes that would not run, and re-install the UKTS Freeware packs and default track makeover pack. So far, I have got CKPR, SWW and Cresston to run, and driven scenarios from end to end with no problems, so I think I have proved my hypothesis - too many assets in the Kuju folders will cause SBHHs.

It looks like in the near future we may need something like Trainstore (MSTS users will know what I am talking about) for Railworks - the alternative would be to move reskins out of the Kuju folders, editing their bin files to keep them working.

[chrisreb]

Sounds very likely to me. For this reason I have multiple asset sets for various route combinations and like you I have had working routes gradually stop working which I can only assume is caused by the accumulation of assets.

The routes you mention are among my problem routes so some are obviously more prone than others.

[alanch]

Sounds very likely to me. For this reason I have multiple asset sets for various route combinations and like you I have had working routes gradually stop working which I can only assume is caused by the accumulation of assets.

The routes you mention are among my problem routes so some are obviously more prone than others.

I was thinking of your experience as I started this post - I think the problem only arises if a route refers to many blueprint sets and one or more of those contains large numbers of assets. That is most likely going to be one or both of the Kuju folders I refer to.

[peterhayes]

Alanch
My guess is that you are running a 32-bit OS possibly Win XP?? If you are this has very little to do with Physical RAM but due to the Virtual (Process)) Address Space that all programs are loaded into by Windows. In a 32-bit app like TS2012 (with the Large Adress Aware Flag set) running in a 32-bit OS it will have a MAXIMUM of 4 GB of VAS to load into. However in a 32-bit OS 2GB of this VAS is allocated to the system leaving only 2 GB available for TS 2012 but the VRAM on the videocard takes some amount of this 2GB, so if you a video card with 1GB of VRAM it can nearly exhaust all of the VAS before you have even loaded TS2012. You can use the /3GB switch /userva = 2560 (via the boot.ini) which can increase the VAS up to 3GB (userva=3072) minus the VRAM. In a 64-bit OS, TS2012 gets a whole 4GB of VAS to itself and this is not impacted significantly by the VRAM.
I suspect this error you are seeing is due to the fact that by having to load huge amounts of extraneous data you have either depleted the VAS or it is so fragmented that TS2012 cannot find any contiguous space to load into. This may be exacerbated by a slow processor/RAM combination. By removing some of this extraneous material you have taken the laod off the VAS so it can load the relevant parts of TS2012 and run it without error.
The best solution is Win 7 64-bit which gives a greater buffer to SBHH errors due to Out of Memory (ie VAS) errors and via WDDM1.1 offere much better graphics capabilities.
If indeed you are running a 64-bit OS then your 3GB of Physical RAM needs to be increased to at least 4GB in 2 x 2 GB matched pairs.
Regards
PeterH

[PapaXpress]

Well said

[alanch]

Alanch
My guess is that you are running a 32-bit OS possibly Win XP?? If you are this has very little to do with Physical RAM but due to the Virtual (Process)) Address Space that all programs are loaded into by Windows. In a 32-bit app like TS2012 (with the Large Adress Aware Flag set) running in a 32-bit OS it will have a MAXIMUM of 4 GB of VAS to load into. However in a 32-bit OS 2GB of this VAS is allocated to the system leaving only 2 GB available for TS 2012 but the VRAM on the videocard takes some amount of this 2GB, so if you a video card with 1GB of VRAM it can nearly exhaust all of the VAS before you have even loaded TS2012.

Hi Peter - yes, I am using 32bit XP with 3Gb of memory, a dual core Pentium D 3GHz processor and and ATI Radeon HD 5570.

If you look again at my post, you will see that loading routes were crashing with an SBHH while Railworks was still reading the asset folder tree - at the point of the SBHH Railworks had only used about 300Mb of my memory, and 2Gb of memory was still free. My understanding is that even 32bit XP manages memory sufficiently well to cope with this load, and I am sure that the problem is with the coding that reads the asset tree. Possibly the coders used a fixed array to store the data read in, and once the number of assets exceeds the size of the array, the program crashes.

[peterhayes]

Alan
Its nothing to do with loading into RAM unless there is not enough RAM available and your 3GB should be enough. Before any code can be worked either by the cpu its caches and finally the working set in the Physical RAM it has to be loaded into the VAS by the OS. Think of the physical RAM as super super fast hard drive - that's all it is, it is somewhere to load code when the cpu and its caches need more operating space. If it were a physical ram issue the first thing that would happen is that Windows would slow down (now probably having to use the paging file ) and Windows not TS 2012 would give you a warning about possibly lowering settings and the if it went on long enough you would likely see a Windows (NOT TS2012 SBHH crash) crash usually with a BSOD and an exception code warning. IMHO The VAS is your problem NOT the Physical RAM. The SBHH errors indicate something wrong inside TS2012 ONLY and not Windows and its unlikely to be due to physical RAM. Changing to a 64-bit OS just gives a bit more headroom for TS2012 to operate in. I have the same size in my Kuju etc folders and I do not see SBHH errors but that is because I am running win 7 64-bit. IMHO Win XP 32-bit will struggle to cope with the "new" TS2012 code due to its memory limitations.
Have you tried the /3GB switch? How much VRam does your video card have?
Regards