Atomic Systems

Hi all

Just about at the end of my tether with this, so I'm taking a break from sim testing and seeing if anyone here can help.

Having recently purchased a new PC, my first action was to re-download the Steam-based RS2013 installation and port across my non-Stream dlc, via USB drive, from my old computer. I immediately noticed that many of my older routes, such as Western Rails, Blackpool, Crouch Valley, Further North, Llanberwyn, Heartbeat Moor, WSR, Abingdon, would not run at all, giving the "line 113" error message. As I'd accumulated a huge collection of assets over the years, not all of which were in use, I thought it the ideal opportunity to have a good old clear-out and start afresh, so I renamed my complete but faulty installation and downloaded a fresh "vanilla" one from Steam. Unsurprisingly, everything worked as expected.

I then set about re-downloading and installing my non-Steam routes and required assets, one by one, with much success - the routes that I've named above (and scenarios) now worked. I have been using a couple of previously-broken scenarios as a gauge for progress, systematically running these after every install just to see if they still worked. Everything was going fine until last night, when inexplicably, my test scenario on the Woodhead route ("Something Borrowed, Something Blue") ceased working, giving a "line 113" error for the first time, even though I'd not altered that scenario in any way. The odd thing is that it was working earlier, and all I had changed in my RS2013 installation was to add more of the required assets to get the scenarios in the Western Rails route working. I had made no changes to the Woodhead route at all.

What I cannot figure, but what I'd really like to get to the bottom of, is exactly what the "line 133" error refers to - that is, exactly what file is causing the problem, as I'm lost as to what to test. These error messages give no clue as to which file is affected (possibly corrupted), so I have little clue as to what I need to check/reinstall. It seems to me though that if I continue, I'll be back where I started with all the main, Steam-based routes working but my third party dlc routes not, again. I'm simply trying to get all my routes (and ideally all scenarios) working properly within the same installation but it's proving very difficult, and I'm lost at the moment as to how to proceed.

Any ideas, anyone?

Ash

Remove the Assets you added, this error is caused by a badly formed .xml document which doesn't have to mean an incorrect one------an old file written to conform with an old spec may not work if the .xml spec changes.
What assets did you add?

The best idea is to not go on. Like you say, adding more to something containing some error somewhere just makes it hopeless.

Logic dictates that what you added caused the error. How can this influence the Woodhead scenario?

The not so likely idea would be that this scenario uses something you downloaded now but which is not mandatory, like scenery. Not likely at all, I would say.

The other idea is that many freeware items (I hope no payware at all) is naughty in modifying default content, or anything else outside the folder hierarchy where you would expect it. There are many global files where people have good ideas how to improve them but don't clone them to make the improvements available globally. In my view, the sum of all such hidden modifications is what breaks many installations.

In your case, it will be some file which is simply corrupted. The error message just means that this is not a proper XML file. Someone ate a > or < or doubled it or removed a line or used an & improperly or whatever.

So looking for new files, focussing on the Kuju & RSC folders mostly will show the culprit. Removing files in batches with repeated testing will let you break the whole load down to spot the individual file causing it.

Thanks guys!

So, I guess I should be looking for a file I downloaded yesterday, that also (somehow) interacts with the files in the Woodhead scenario?

I'll get RW_Tools on the case. I still wish there were some way of telling which file the Line 113 error referred to though...

Ash

Its completely frustrating. It happened on a route of mine and it took several hours of renaming folders (to make them invisible) to the game, which can narrow down where the bin file is that is causing the error.

The difficulty is that the error messages and dmp files (to the extent they are decipherable) offer no help in identifying the culprit.

One tool that can help is Microsoft Process Monitor, which you can run in the background as you launch which shows all processes and files running. By filtering to show only the Railworks.exe entries, you can see the last events before the game crashes - hopefully the culprit will show.

Thanks to Ruth and Neil for this tip.

If RSC could put this very basic function into error reporting it would be hugely appreciated.

B

Many thanks Ben - I'll try that now.

Ash

ashgray wrote:So, I guess I should be looking for a file I downloaded yesterday, that also (somehow) interacts with the files in the Woodhead scenario?

That was the base assumption.

Ben's suggestion sounds like the fast lane and working under any and all base assumptions.

I really wonder how such files reach the general public. When you find one, please let us know. I mean, serz.exe does not accept bad input, it cannot produce such corrupted files. From this, it follows that it would be an XML file. I can only think of RouteProperties.xml (and ScenarioProperties.xml ??) that is actually processed by RW. Generally, XML files are just ignored and .bin is used. So you could instead make a targeted search for corrupt RouteProperties.xml files. Feeding them to serz.exe should make it cough when you got the culprit. But there may be other .xml files that are relevant. Only I cannot think of some at the moment.

Success! - or at least, that's how it's looking at the moment!

I followed Ben's suggestion of downloading and firing up Microsoft Process Monitor, I ran the Woodhead scenario and, as expected, it failed with a "Line 113" error. The process manager clearly pointed to a folder I installed yesterday, so I re-named it, fired up RS2013 again, and the scenario loaded faultlessly! I don't think it's appropriate to name the author here but the files concerned do appear to be corrupted, and on the assumption that the same fault was responsible last time it happened to me, I think I've found the cause.

Well done Ben, and everyone else for your helpful ideas - I'm indebted to you.

Where would we all be without these forums?

Ash

Glad it worked, but all credit to Ruth (Rivemy) and I suspect Jim (Nobkins) too - this sort of cleverness is way beyond a humble reskinner.

For reference, if you run this and it doesn't land with a specific folder, its likely to be either the provider / pairs issue or a FKF (Fat Kuju Folder) (TM)

B

Blimey, how does one filter out all the bazzillions of processes? I am no techy at all and I am glazing over with all the choices but this program could potentially help me identify a scenario problem?

Use a filter "process name" "is not" "railworks.exe" then "add" and ok. In the toolbar deselect all the right hand group but "show filesystem activity.

You may need to enable the capture process by clicking the blue magnifier icon.

B

It's very worthwhile Martin - it nailed the exact file that was corrupted and was causing the problem immediately before I got the error and was booted out to my desktop.

Re-naming the folder and re-running the scenario proved it.

Ash

ashgray wrote:I don't think it's appropriate to name the author here but the files concerned do appear to be corrupted,

Without naming names Ash, can you say in what way the files were corrupt?
Was it 'sloppy' editing; a simple mistake such as deleting a '<'; a severe mangling of the files due to a bad or incomplete download?

ashgray
Its good to hear that Procmon proved useful in your line 113 error - I use it all the time to track issues in my system ie in TS2013 and other programs - it helped recently indirectly with a network error I was experiencing.
Two other great tools from sysinternals are : Process Explorer which can also track issues with video cards and VMMAP which can tell you what is going on in the virtual Address Space and can help with some of those obscure SBHH errors.
The sysinternals suite is excellent for nayone who wants to know a little more about how programs interact with your computer.
Great post.
pH

I would also like to learn more about the details. I mean, if it was a syntax error in a RouteProperties.xml, the people know to look there. If it was another place, it is important to know where else to look.

It is quite noble not to name the person who caused the fault (without knowing for sure) but seeing as a single file can cause really big trouble it would be important for the whole freeware sharing scene to reduce the number of such files to zero - behind the scenes, not upsetting anyone, but also preventing future spells of frustration like you experienced it.