Access violation errors

[K2rover]

One thing I hope TS2019 fixes is the access violation errors, which have taken the place of the Out of Memory dumps of 32-bit times. Seems to be particularly bad on certain routes.

The worst I've now found is the extended Great Eastern Main Line up to Norwich on the Steam Workshop. I can barely even set up a blank free roam scenario without it crashes with an access violation error or a temp dump. Completely unplayable. So gutting for a route which could have been so fantastic.

Why do they occur and does anyone else hope/have insider knowledge that the update later this week will maybe fix it? I really hope so. I find the train simulator series so much more immersive than Train sim World which I haven't been blown away by, but the bugs on train simulator never seem to go away despite how long it's been developed for now. 64 bit has been a transformation, but wish these errors would disappear.

[gptech]

...have insider knowledge that the update later this week will maybe fix it? I really hope so. I find the train simulator series so much more immersive than Train sim World which I haven't been blown away by, but the bugs on train simulator never seem to go away despite how long it's been developed for now. 64 bit has been a transformation, but wish these errors would disappear.

No insider information, but no matter how good/stable a program gets it will easily be brought to it's knees by a *less than optimal* addition. We can't expect DTG, nor any other software producer, to be able to safeguard against every case of "user error"---you can try to make things "fool proof" but you can never underestimate the tenacity of the "foolish"

The GEML extension has been plagued by issues from day one, there's along thread about it in here detailing the woes many have had in here somewhere, so that route causing bother isn't a big surprise---do you have any other rogue route that isn't particularly recognised as being *iffy* that you also have issues with?

[Carinthia]

One thing I hope TS2019 fixes is the access violation errors, which have taken the place of the Out of Memory dumps of 32-bit times. Seems to be particularly bad on certain routes.

If you are "out of memory" you are out of memory under whatever name you call it. The impossible cannot be achieved.

Try lowering your settings a little until things become stable. Having got my settings at a satisfactory level I don't experience any TS crashes at all. But I don't use third-party scenarios, some are very resource-hungry.

You can watch your resource usage by running TS in a window and keeping task manager visible.

John

[K2rover]

Seems to be particularly 3rd party or Workshop but got it this evening with West Coast Main Line Shap which was unusual (if that doesn't count as 3rd party). Are we saying that access violation errors are 'out of memory'?

[gptech]

Are we saying that access violation errors are 'out of memory'?

No, ot at least not totally.
The "Access Violation Error" isn't really a TS issue, but simply Windows reporting that there's been an error accessing some data. That's usually data held in RAM that is suddenly unavailable because the game has crashed and that data flushed from RAM --it can't be accessed because it ain't there, thus violating how the system works. Running short of available RAM could give rise to the problem if data has been flushed to make room for more, but is then called for again by the game. This should be largely alleviated by the move to 64bit though so if you're running the 64bit iteration of TS it wouldn't be the first thing to consider--a single, tiny, .bin file that's a wee bit *flakey* can/will bring the game down.
It's a very generalised error message, as it doesn't indicate just what's caused the game to crash.
You have a PM by the way.

[Carinthia]

Seems to be particularly 3rd party or Workshop but got it this evening with West Coast Main Line Shap which was unusual (if that doesn't count as 3rd party). Are we saying that access violation errors are 'out of memory'?

Not necessarily only that, but In my experience that has always been the case. Much will depend on how much RAM your computer has. You can find out whether that is so for you by using Task Manager, as I suggested. Absolutely nothing to stop you reverting later. It can happen on 64-bit aswell as 32-bit, as scenario makers can make their works more and more complex given the increased capability of 64.

The new features of Train Simulator 2020 will use more RAM too, so things will soon get even more stretched.

John

[gptech]

Not necessarily only that, but In my experience that has always been the case. Much will depend on how much RAM your computer has.

John, I have the odd "Access Violation" error despite having 32GB of RAM; surely you're not suggesting that I need more?
It's not the amount of installed physical memory that's important; VAS takes care of being able to deal with virtually "pouring a quart into a pint pot"--in theory anyway, of course it'll run into problems at times but the memory issue is often secondary to the root cause. Lowering settings, thus the memory usage, does help: reducing overall load on the system can't be anything but a benefit but it also does allow the game/PC to *bulldoze* through other issues.

K2, have you tried slimming down your installed routes and assets temporarily to try and find any possible rogue items, and just what are the specs of your machine?

[rob81]

All,

I can report the same issues my end too. Occurs for me on WHL Extension every time I use the scenario editor. Seemingly stable assets that have never caused issues in the past (Class 57 railtours set, JT class 67) cause exactly this issue.

This must be a software issue as far as I can tell - my machine specs are way beyond necessary for TS, specifically, I'm on windows 10 with an Intel i7-7700 processor and 16 GB of RAM, with 18.3 GB of available virtual memory.

I've reported the issue to DTG but got the usual unhelpful support reply asking for details already given.

[Carinthia]

John, I have the odd "Access Violation" error despite having 32GB of RAM; surely you're not suggesting that I need more?

Sorry if you thought I was talking to you, I was talking to somebody else, actually.

Like many people, I suspect, I whacked all settings up to full when 64-bit came along but things were not good. I haven't had a single "Access Violation" error since adjusting my settings down slightly, not enough to give any obvious loss of realism, and I have only 8 GB RAM. Maybe you've got too much . . .

So many people I have helped say this has been the solution for them too. But some just don't want to even try it.

John

[gptech]

Sorry if you thought I was talking to you, I was talking to somebody else, actually.

I'd expect you to have been directing it primarily at K2, so no...I didn't think you were addressing me.
There are far too many causes of this particular error, which as noted above isn't a game generated message. Obviously lowering graphical settings will reduce the overall load on any system which can only be of benefit if it's a system that's weak in some area--could just as easily be a weak CPU or GPU as a lack of available, physical RAM. This ploy may also allow the game/system to *deal with* any files that are slightly suspect and whilst it's a worthwhile change it isn't necessarily addressing the real cause of an issue.

I have only 8 GB RAM.

So, as you're running with an amount of many that's widely accepted as being the absolute minimum for a 64bit OS, how can you say that a shortage of RAM is a huge issue? Your experience flies in the face of the reasoning that you need oodles of RAM installed. As also noted above, VAS allows for huge amounts of data to be addressed, regardless of the amount of physical RAM fitted to the PC.

don't use third-party scenarios, some are very resource-hungry.

By 3rd party scenarios do you mean those by the likes of AP, Just Trains, Steam Sounds Supreme etc plus scenarios from Workshop and sites like this , or just the user produced scenarios available? Whichever, by taking what's possibly part of the problem out of the equation you may not even be testing the right things.
You've a small amount of RAM, which the theory you're expounding says is the cause of the problem but you don't have the problem--the result doesn't fit the reasoning in your case. Another theory says that slightly *less than optimal files* are the bigger cause so by removing a source of such files haven't you gone some way towards supporting that particular theory?

I've little doubt that the real, true, root cause is dependant on far many more factors than PC spec and file integrity and is very much peculiar to each system; something we'll never be able to properly qualify. We haven't even considered the amount of free disc drive space on the system drive yet, which can have a huge bearing o things---Windows needs space for it's temporary management files, so if it can't find a home for them it'll have a hissy fit

Seems to be particularly 3rd party or Workshop

How many routes and scenarios do you have installed K"?....roughly, no need to do any accurate counting.

[peterfhayes]

This is a complex issue and there is a lot of misinformation published about on the web. Access Violations in TS are rarely caused (if ever) by the amount of RAM you have installed. Everyone forgets the paging file which in essence is "extra RAM". If there is a timing protocol for RAM calls then because the PF is so slow you may get a time-out error and a crash of the software program. But that would be pretty rare! RAM is hardware, and if there was an issue with RAM resources – WINDOWS would warn you and eventually the whole system not just TS would crash.

As gary has explained, the usual suspects are calls to the RAM in a protected zone or to an address in the RAM already occupied. You need to look at the so-called page faults via Google, Invalid, Hard and Soft - not really faults but indicators that something is not quite right with the software trying access areas of RAM that it can't.

This is how it works:

When you try to access a memory address in the RAM, the computer goes through several steps:
If the address is part of the current memory segment/address (RAM), access is granted.
Otherwise, if the address's segment is in memory (RAM) with appropriate access permission, access is granted.

If the address is not in memory, but still in the VAS, the CPU will generate a memory check exception. At this point, the operating system (OS) takes over.
If the segment is available in the VAS with appropriate access permission, it is loaded into memory (RAM) by the OS/Cpu and assigned to the virtual memory manager; access is then granted.

If, at this point, the memory is not available, there is one of two possibilities. Either the address is not available, or you do not have the permissions you need (eg, trying to write into read-only memory RAM). In this case, the operating system will pass the access violation to the process and stop the program (TS crashes).

We now have in the 64-bit version of TS up to 8 TERAbytes of VAS to access, so any "OUT OF MEMORY" errors are a thing of the past. The page faults occur usually because TS has been loaded into the OS/VAS, but is not loaded into the RAM per se. The cpu then addresses another call to the RAM, but if that call to the RAM is invalid – TS will crash. Access violations in TS are purely software driven and caused by 3rd party software usually from the WS.

Complex and Technical.
pH

[mikesimpson]

Some of these 'Access Violation' errors are really difficult to understand. I now have 32 gigs of RAM and I can't run TS2019 at all in 64 bit as it crashes as it starts with the Access Violation error. When run in 32 bit mode, it runs fine but gives the Access Violation error on exiting the program - every time.

No idea why, but when I find time I will remove a lot of junk routes and see if that helps.

Mike

[gptech]

Don't forget assets too Mike....

[Carinthia]

One thing I hope TS2019 fixes is the access violation errors, which have taken the place of the Out of Memory dumps of 32-bit times. Seems to be particularly bad on certain routes.

If my initial suggestion did not help, I highly suggest you contact Dovetail Support.

One of the things they will do is to provide you with a checklist of relevant external items that must be fully up to date for Train Simulator to work properly without Access Violation errors within the abilities of your system, however powerful or not it may be. It will take a little time to go through everything but I feel sure the result will be worth it.

John