DBGHELP.DLL and fatal crash

[_o_OOOO_oo-Kanawha]

I have managed to capture a screenshot just after the fatal DBGHELP.DLL error that causes the game to crash.

DBGHELPDLL.jpg

It appears to have run out of memory. On Tehachapi Pass (Rowen - Summit Switch) using Donner Pass locomotives and Eyein's Tank Train, BKDUO 72 cars @ 133 tons.
The locomotives were 11 SD40T-2.

When I run the quick drive with 8 C44-9W locomotives it doesn't crash, neither with 11 DTM SD45's.

With the Tunnel Motors in notch 8, I need to sand almost all the time when the grade exceeds 2.0% to prevent a stall.

It happened a few times before with the Tunnel Motors and sanding on this run. Is prolonged sanding eating memory?

[peterhayes]

Edwin
Is your OS 32 or 64-bit?
That looks like a Windows error that caused this issue.
If you modified/installed/uninstalled anything recently that may be the issue.
Have you run sfc /scannow via the command prompt - does it fix anything?

Click on Start > All Programs > Accessories > right click Command Prompt and select Run as Administrator > type in sfc /scannow and press Enter

From Microsoft:

If you have recently uninstalled AVG Anti Virus or another piece of software, your dbghelp.dll file may still be in the System32 directory but it may be named dbghelp.dll.old... simply rename the file to dbghelp.dll and restart your PC for the dll to be recognised

You may need to download the dll file from MS and copy it to the System32 folder.

To obtain the latest version of DbgHelp.dll, go to http://www.microsoft.com/whdc/devtools/ ... fault.mspx and download Debugging Tools for Windows. Refer to Calling the DbgHelp Library for information on proper installation

.
pH

[_o_OOOO_oo-Kanawha]

The computer in question runs Windows 7 64 bit and has 8 GB of RAM.

There is a DBGHELP.DLL in system32: version 6.1.7601.17514

Isn't there a Visual C distribution installation pack included with the game? Should I re-install that first?

This computer has many other games and stuff, so there are often programs installed and uninstalled.

That Microsoft web page isn't comforting when it comes to versions of debugging tools and Visual development products.
The Control Panel/Programs and Features lists a lot of Visual C and .Net frameworks and architectures and versions.
There are Visual C++ from 2005 till 2013, it's a mess.

[peterhayes]

EdwinK
You could try ALL of the exe files (not PhysX*.exe) in the Install folder.
I too have every version of C++ from 2005 to 2013
My version of DBGHELP.dll is the same as yours.
I guess that you also have this file (different versions) in the Railworks and Steam folders?

Did you run sfc /scannow? Any Issues?

Another (remote) Possibility: I just noticed on your screenshot a cX0000005 error - "memory mismatch" which is common but it could be due to a corrupt scenario/file in TS2016. Basically an app like a scenario/route, etc does not load the code "fast enough" or not at all from the OS/VAS to the cpu/RAM. The code then can't processed or is processed "too late" and so you get a memory mismatch error.

pH

[_o_OOOO_oo-Kanawha]

Thanks, Peter for your help and support.

There were a few issues reported by the system files integrity check and apparently corrected after a reboot.

I am however still inclined to think lack of resources/memory is causing the error. Railworks is AFAIK the only game on that computer to throw the DBGHELP.DLL error. The 32 bits memory limit is 4GB, and any active memory use above app. 3.5 GB will likely crash the game. I suppose the "missing" .5 GB are textures laid off in the VRAM?

Will peruse the various system logs for any helpful info. Logmate will probably be of little use and uses a lot of resources itself.

Anyway, I've adapted my workflow when creating scenarios to quit and restart between edits to free the memory used.

[peterhayes]

EdwinK

I am however still inclined to think lack of resources/memory is causing the error. Railworks is AFAIK the only game on that computer to throw the DBGHELP.DLL error. The 32 bits memory limit is 4GB, and any active memory use above app. 3.5 GB will likely crash the game. I suppose the "missing" .5 GB are textures laid off in the VRAM?

The big problem with TS2016 (a 32-bit app) is the Virtual Address Space (VAS) and this is limited (running a 64-bit OS, with LAE set in the app - it is in TS2016) to a maximum of 4GB - that's it!
Now if the VAS becomes fragmented or there is very little contiguous space left for TS2016 to load into (as little as 1 MB will do it) then it will crash. The editor is notorious for fragmenting the VAS, and depleting the contiguous space. In a 64-bit OS the VRAM does not use any significant amount of VAS. Its a different story in a 32-bit OS, where the OS uses 2GB VAS and the VRAM takes another chunk, leaving 1GB or less for TS2016 - very flakey.

The Physical RAM has nothing to do with it - if you had used all of the Physical RAM - WINDOWS would have flagged a message telling you to turn down your settings. The VRAM does not use any RAM at all.

If you were in the editor when the "debug" error occurred then something in the code was wrong hence the Cx0000005 error - memory (in this case VAS - mismatch. Every time you close (save) the editor it refreshes the VAS!

This is what I have written previously:

The problem in TS2016 is that (particularly the editor) that as the game runs and you just run scenario after scenario the contiguous space in VAS becomes smaller and the VAS itself becomes highly fragmented. Now when this reaches a critical level, TS 2016 will crash and create a dump file. If the code for a scenario, route, reskin, etc is written poorly – you may get a memory mismatch Cx0000005 error. All this means is that the OS has loaded the code into the VAS but has yet to load it into the cpu/RAM – the code “can’t be found” – error and crash.

If there were a RAM issue in TS2016 – WINDOWS would tell YOU to turn down settings and run very slowly and/or crash with a BSOD.

Regards
PeterH