Atomic Systems

Jevon
I would like to see the procmon pml files so let me have the dropbox link - Thanks.
The gamemanager.dll/offsets error is intersting error is interesting if you have the eventviewer log file that could be useful too.
I'm surmising that the error contained something like this:
Exception Code: c0000005
Exception Offset: 006e0061
This is usually an "access violation" ie usually affecting gamemanager.dll and stopping railworks.exe in its tracks. It should have been reported in Procmon as that error will stop TS2013.
If you could supply the event viewer log that would be great:
Click Start Menu
Type eventvwr into Search programs and files (do not hit enter)
Right click eventvwr.exe and click Run as administrator
Expand Custom Views
Click Administrative Events
Right click Administrative Events
Save all Events in Custom View As...
Save them in a folder where you will remember which folder and save as Errors.evtx
Go to where you saved Errors.evtx
Right click Errors.evtx -> send to -> compressed (zipped) folder
Upload the .zip file here (if you can) to dropbox
Thanks
pH

jevon wrote:One other thing I wanted to mention. A number of people early on in this saga of the SBHH errors suggested that these were related to multiple unnecessary provider entries in the RouteProperties.xml. In my case fixing these did not solve any of my problems. I also went through the process of hand editing ScenarioProperties.xml files to the same end -- using RW_Tools to list required assest and removing unnecessary provider entries, but this also made no difference whatsoever.

Hi,

Having more provider folders enabled in the RouteProperties.xml and/or ScenarioProperties.xml increases the number of items loaded by the game and thus increases the likelihood of SBHH. In some situations removing unneeded provider filters (ie those that are enabled but no content is used from them) can make the route or scenario load. However, it is not a guaranteed fix for the simple reasons that in the following (exaggerated) example if I had 200 provider filters enabled I would expect the route / scenario to SBHH. If I halve the number of provider filters to 100 I still would expect the scenario / route to fail because even though I have halved the number, 100 is still a lot!

It was certainly worth a try (removing the unneeded providers) but unfortunately it looks like there are still too many enabled (and too many bin files being indexed).

I only clarify as removing unneeded provider filters is a POSSIBLE fix and definitely worth trying. It is NOT a GUARANTEED fix though

Jim

nobkins wrote:It was certainly worth a try (removing the unneeded providers) but unfortunately it looks like there are still too many enabled (and too many bin files being indexed).

I only clarify as removing unneeded provider filters is a POSSIBLE fix and definitely worth trying. It is NOT a GUARANTEED fix though

Jim,

For sure it was worth a try. In my case the number of providers was nowhere near 100 .. it was more like 40-50 before I edited the ScenarioProperties.xml, and as I recall 15-18 after editing.

I think W.C.'s words from 1939 are apropos: "a riddle wrapped in a mystery inside an enigma."

Jev

gptech wrote: Has anyone managed to get a reskin blueprint to deal with more than a single texture change?---if not it's of little use for locos with multiple textures (body, cab, and roof for example) that need changing to poprtray a particular livery.

No, because it's impossible as it's bugged like everything in the game. The only way to change it is to spamming RSC support with requests to fix it But since it's not a critical bug, and not visual problem, they probably won't fix it.

shanyiqua wrote:

gptech wrote: Has anyone managed to get a reskin blueprint to deal with more than a single texture change?---if not it's of little use for locos with multiple textures (body, cab, and roof for example) that need changing to poprtray a particular livery.

No, because it's impossible as it's bugged like everything in the game. The only way to change it is to spamming RSC support with requests to fix it But since it's not a critical bug, and not visual problem, they probably won't fix it.

Possibly a little unfair to say everything is bugged, and of course if you find how the game works so unbearable you do have the choice not to play it. The reskin blueprint has been with us for quite a while, possibly even from Railsimulator days. Ther's a school of thought that says the initial EA Railsimulator was released in a rush, and wasn't ready so perhaps this blueprint is a failed experiment that never was removed from the game?
I've stated before that I don't believe RSC have the capabilities in-house to delve deeply into the core programming of the game, and as we have a perfectly good way of producing re-skins fixing the blueprint is not essential. Admittedly they could have done much to reduce the problem by simply moving stock---for example into RSC/Class47; RSC/HST; RSC/Mk1Coaches etc, and I'm sure nobody would have minded having to re-write .bin files for their installed re-skins or editing scenarios to accomodate the new locations....honest

It's been stated, and not by RSC apologists/advocates/fanboys but by well respected members such as Mike Simpson that the root cause of the problem is the user---do you really need 80 class 47s, or 5 weathered versions of the same wagon?
Whilst I agree the rekin blueprint route would tidy up installations, it's doubtful it'd have much effect on the problem under discussion---it still needs to call on the Kuju/Railsimulator folder, as far as I'm aware the .bin using it still would live in that folder structure so running a scenario with the Kuju/Railsimulator Provider/Product box ticked would still mean all those numerous .bin files were read. Moving a few .TgPcDx files into a re-skinners oen folder would not help greatly, the reverse could be true as that would entail another Provider/Product box to be ticked.

Gary
In using Procmon I see quite a few .lua files being loaded from both KUJU and RSC. (Mainly signals and a few locos from KUJU - RSC just about everything)
Any significance?
Early Procmon results from SBHH error files show no errors in .bin files from KUJU or RSC. In fact no significant errors at all. Not Looking good.
Still digging.
PeterH

gptech wrote: It's been stated, and not by RSC apologists/advocates/fanboys but by well respected members such as Mike Simpson that the root cause of the problem is the user---do you really need 80 class 47s, or 5 weathered versions of the same wagon?

I know RW_Tools can produce a list of assets committed to installed routes/scenarios. And, maybe I dreamed this, but wasn't there also a way to determine which installed assets are not called by installed routes/scenarios -- in other words, which of my 100 (I'm serious ) Class 47s I can safely delete? If someone has the link to this it would be much appreciated.

Thanks.

peterfhayes wrote:In using Procmon I see quite a few .lua files being loaded from both KUJU and RSC. (Mainly signals and a few locos from KUJU - RSC just about everything)
Any significance?
Early Procmon results from SBHH error files show no errors in .bin files from KUJU or RSC. In fact no significant errors at all

Doesn't seem to be any particular clue there as to what's happening--almost as if the game crashes without a fight!
What scenario on which route is this?....if a few of us tested to see what happens on differing systems we might find (stumble on?) something of signigicance.

jevon wrote:And, maybe I dreamed this, but wasn't there also a way to determine which installed assets are not called by installed routes/scenarios -- in other words, which of my 100 (I'm serious ) Class 47s I can safely delete?

I'm not aware of any easy utility to find unused assets unfortunately, the time consuming method would be to create another instance of Steam/TS2013, copy over the scenarios and work through them one by one adding the locos. I imagine you'd find you use 99 of those class 47s though, and I think it's this amount of duplication that's a large part of the problem ( I feel rather impoverished, having only 16 class 47 folders ) As we don't have a nice, easy method to dynamically add nameplates to locos I can understand needing a few 'single engine skins' if a scenario features a specific engine, but we all have (or have had) a plethora of nearly identical skins for which a single one would suffice...as a theoretical example, why have a skin depicting DRS 47802 and another depicting DRS 47810 when all you see from your passing train is the cabs of these sticking out of Kingmoor shed? If the next scenario you play calls for another DRS liveried class 47 but it's a passing AI service at 3:30 in the morning once again it's immaterial what number is displayed on it.....if you see my line of thinking there.
If anything, we (or rather the prolific and talented re-skinners) need a nice easy method of adding names, moving the position and size of the numbers rather than going the MSTS route of vast duplication---either that or we start accepting little inaccuracies such as the numbers on a particular livery are a few inches too high, a few inches too close to the cab door etc. and use the positioning available on the default .GeoPcDx files.

Gary
The issue may have been there was more than one error!!
I have just realised that the files that I have analysed with Procmon the SBHH's in TS2013 were due to use of the editor - which is a different ball game as we know that the editor is pretty flakey anyway. I would guess that the editor is making an improper call to an address creating an access violation and crashing TS2013. Because its an internal error ie within TS 2013 Procmon doesn't "see" it.
What I'm after is a procmon file where the crash is solely due to the "SIZE" of the kuju\railsimulator folder ie one with many addons that have not been edited in any way. Now if there is NO such beast are we to assume that its only edited files that are causing the issue?
The other point is where is TS2013 installed 2 sets of data I analysed, TS 2013 was installed in the Program Files (X86) folder (indicating a 64-bit OS) and I wonder if that could be one of the causes ie an issue with windows security ie UAC etc.

Certainly the .bin and in fact any files in the Kuju\Railsimulaor and any kuju sub-folders show no sign of error even though TS2013 had crashed with an SBHH error.
Procmon found nothing to cause any concern.

Regards
PeterH

peterfhayes wrote:The other point is where is TS2013 installed 2 sets of data I analysed, TS 2013 was installed in the Program Files (X86) folder (indicating a 64-bit OS) and I wonder if that could be one of the causes ie an issue with windows security ie UAC etc.

I'd certainly advocate having the game out of the protected system areas, and as UAC can be set to different levels by the user that would (partly) explain the apparant randomness of some problems. Probably impossible to find definitive proof that UAC is the cause, but eliminating the potential can't be a bad thing. We could be chasing various combinations of *errors* that when applied under some circumstances cause weird happenings--the 32 bit architecture imposes the address space limit, UAC has potential to block an access call, a seemingly incorect edit of a .bin file can cause a blip......all errors that on their own may not cause a crash, but when happening together....

gptech wrote:Possibly a little unfair to say everything is bugged, and of course if you find how the game works so unbearable you do have the choice not to play it.

I say it because i can't really say a feature of railworks/ts that is working perfectly, moreover the most don't work at all.
(actually i don't play with TS2013 anymore, as it is boring as freeware devs still don't want to bother with it, (now since some years of development/helping in development for railworks/TS2013 contents i can perfectly understand this), and there is not much content for apart from UK, US and german content, and as the pathing and dispatcher AI is so bad that it's not possible to make scenarios that are not boring.
I've ceased any of my own developments for it(i've fed up with the non working, badly working features of the game, and the fact that the simplest problem need workaround tricks and scripting in the worst programming language of the world: LUA) just finishing those that i've started, and suggest the same for others who i'm helping.

gptech wrote:I've stated before that I don't believe RSC have the capabilities in-house to delve deeply into the core programming of the game, and as we have a perfectly good way of producing re-skins fixing the blueprint is not essential.

I agree, they don't have the capabilities. That "perfectly good way" is like shooting on a mosquito with a 288mm ship cannon , it's brute force. It's uneconomical and overcomplicated, and not flexible. The brute force way locks repaints to the original folders, takes more memory, and if the original rolling stock's configuration is changed it's likely to ruin all of the repaints. These are wouldn't happen with a good method for repainting, like the (fixed) reskin blueprints.
There are many of things such like this in railworks/TS and these together causing the instability, and the majority of the bugs in the game, and the performance problems. Even the free, hobbyst made OpenRails which isn't reached an alpha state yet, have more sophisticated rolling stock settings than TS2013 (for example include and override capabilities for config files).

gptech wrote:do you really need 80 class 47s, or 5 weathered versions of the same wagon?

Why not? If the game's bugs/features would be fixed, then it wouldn't cause any problems. And same again, if reskin blueprint would work as it should, then you could have for example 4000 repaints of each rolling stock, and still no problems with the game(if you don't use all in a single scenario ).
Reskin blueprint isn't a failed experiment, because it works, just it wasn't completed(you can save multiple texture replacements, just the game doesn't apply them except the first) just like diesel, steamer, electric simulations of the game, but this one could be easily fixed by RSC if they would care about it. There are a lot of little problems that could be fixed, if they would care, and as i programming too, i know which would need big efforts and which could be fixed in 5 minutes, and there are a lot of these "5 min" bugs that remain unfixed since years and reskin bp is among them.

I have sent a lot of bug reports(not alone) in the last 4 years, but all i've got is the mails with "Your comments have been passed to our Development team and will be considered in the discussions for future release of Railworks/TS products." none of these got fixed. And what i see, is only the critical problems are fixed and only the visuals are improved.

Having investigated quite a few .pml log files with ProcMon from various simmers (editor used and different installation folders) I have to conclude that this app may not be able to identify (when used by me) the causative error of SBHH's apparently when the Assets\Kuju folder reaches a certain size.
The common error code in event viewer was:
Exception code: 0xc0000005
This is an access violation (very common and doesn't always cause a crash). This happens any time a program tries to access memory (RAM) that it doesn't have access to. For example, it will happen if a program tries to write to memory that is marked as read only, or tries to read memory that the system owns like location 0x00000000. The latter is a really common mistake, that happens when code tries to look up the address of something, and gets null/0 returned but the program doesn't check for an error code before continuing.

Anyway, causes for this usually are:
* Bad code
* A faulty driver (well, this is also bad code)
* Faulty RAM
* Something external getting in the way, like an antivirus scanner
from: http://www.techrepublic.com/forum/qu...t-viewer-error.

My own feeling is that something corrupts/overloads/inerferes with gamemanager.dll (which was developed by KUJU for rail simulator and DirectX 9.0c may be involved) and a SBHH ensues.
Regards
pH