Unexplained Crash

[StuartG]

Ive been working on a scenario, a modified version of the Red Lightning scenario shipped with the game, and I keep hitting a problem. Ive made some modifications to the map, and I was getting an intermitant crash. However, its become more more serious after ive further modified the map to include more detail. Which makes me wonder, is it possible for TOAW to have an out of memory error? I took the stock scenario which was crashing irregularly, updated with the new map, now it crashes much more regularly. Anyone have any suggestions?
The error codes are here, if anyone wants the scenario to try it, I can up that too. Ive tried the suggestion in the 'try this before reporting a crash thread', but still no joy.

As you can see, I have this happening quite a lot.


StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 0100D28D)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 0100D28D)

StackTrace:0100D28D (Opart 4): (filename not available): (function-name not available)

0100D28D (Opart 4): (filename not available): (function-name not available)

StackTrace:ERROR: SymGetSymFromAddr64, GetLastError: 487 (Address: 010DAACF)

ERROR: SymGetSymFromAddr64, GetLastError: 487 (Address: 010DAACF)

StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 010DAACF)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 010DAACF)

StackTrace:010DAACF (Opart 4): (filename not available): (function-name not available)

010DAACF (Opart 4): (filename not available): (function-name not available)

StackTrace:ERROR: SymGetSymFromAddr64, GetLastError: 487 (Address: 010DF7A4)

ERROR: SymGetSymFromAddr64, GetLastError: 487 (Address: 010DF7A4)

StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 010DF7A4)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 010DF7A4)

StackTrace:010DF7A4 (Opart 4): (filename not available): (function-name not available)

010DF7A4 (Opart 4): (filename not available): (function-name not available)

StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 7749339B)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 7749339B)

StackTrace:7749339B (USER32): (filename not available): AddClipboardFormatListener

7749339B (USER32): (filename not available): AddClipboardFormatListener

StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 7748A33A)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 7748A33A)

StackTrace:7748A33A (USER32): (filename not available): GetClassLongW

7748A33A (USER32): (filename not available): GetClassLongW

StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 7748809A)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 7748809A)

StackTrace:7748809A (USER32): (filename not available): DispatchMessageW

7748809A (USER32): (filename not available): DispatchMessageW

StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 7747A230)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 7747A230)

StackTrace:7747A230 (USER32): (filename not available): DispatchMessageA

7747A230 (USER32): (filename not available): DispatchMessageA

StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 736104B0)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 736104B0)

StackTrace:736104B0 (gameoverlayrenderer): (filename not available): OverlayHookD3D3

736104B0 (gameoverlayrenderer): (filename not available): OverlayHookD3D3

StackTrace:ERROR: SymGetSymFromAddr64, GetLastError: 487 (Address: 010E143C)

ERROR: SymGetSymFromAddr64, GetLastError: 487 (Address: 010E143C)

StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 010E143C)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 010E143C)

StackTrace:010E143C (Opart 4): (filename not available): (function-name not available)

010E143C (Opart 4): (filename not available): (function-name not available)

StackTrace:ERROR: SymGetSymFromAddr64, GetLastError: 487 (Address: 010E0E9E)

ERROR: SymGetSymFromAddr64, GetLastError: 487 (Address: 010E0E9E)

StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 010E0E9E)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 010E0E9E)

StackTrace:010E0E9E (Opart 4): (filename not available): (function-name not available)

010E0E9E (Opart 4): (filename not available): (function-name not available)

StackTrace:ERROR: SymGetSymFromAddr64, GetLastError: 487 (Address: 010E09C3)

ERROR: SymGetSymFromAddr64, GetLastError: 487 (Address: 010E09C3)

StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 010E09C3)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 010E09C3)

StackTrace:010E09C3 (Opart 4): (filename not available): (function-name not available)

010E09C3 (Opart 4): (filename not available): (function-name not available)

StackTrace:ERROR: SymGetSymFromAddr64, GetLastError: 487 (Address: 010E0864)

ERROR: SymGetSymFromAddr64, GetLastError: 487 (Address: 010E0864)

StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 010E0864)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 010E0864)

StackTrace:010E0864 (Opart 4): (filename not available): (function-name not available)

010E0864 (Opart 4): (filename not available): (function-name not available)

StackTrace:ERROR: SymGetSymFromAddr64, GetLastError: 487 (Address: 00F63E8B)

ERROR: SymGetSymFromAddr64, GetLastError: 487 (Address: 00F63E8B)

StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00F63E8B)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00F63E8B)

StackTrace:00F63E8B (Opart 4): (filename not available): (function-name not available)

00F63E8B (Opart 4): (filename not available): (function-name not available)

StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 7760FA29)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 7760FA29)

StackTrace:7760FA29 (KERNEL32): (filename not available): BaseThreadInitThunk

7760FA29 (KERNEL32): (filename not available): BaseThreadInitThunk

StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 777C7A9E)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 777C7A9E)

StackTrace:777C7A9E (ntdll): (filename not available): RtlGetAppContainerNamedObjectPath

777C7A9E (ntdll): (filename not available): RtlGetAppContainerNamedObjectPath

StackTrace:ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 777C7A6E)

ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 777C7A6E)

StackTrace:777C7A6E (ntdll): (filename not available): RtlGetAppContainerNamedObjectPath

777C7A6E (ntdll): (filename not available): RtlGetAppContainerNamedObjectPath

[cathar1244]

Best guess is the crash to desktop bug that has affected several scenarios.

One player has noted naval movement in the enlarged version of "Next War in Europe" seemed to trigger crashes.

There is also a thought that the quantity of location names may be a culprit.

Last I recall, one of the troubleshooters believed it was a memory leak.

I've looked into things like odd terrain that is hidden, such as mountains in deep water hexes (editor artifacts). But no conclusions there.

Cheers

[larryfulkerson]

Does your scenario contain any units broken down into pieces on either side? If so, try putting them together and let the player split the units after the game has started. ???

[cathar1244]

Larry,

That's an interesting take. I'll check, at some point, that expanded Next War scenario again for units broken down at the start.

If an update to TOAW is issued, I hope that squashing this crash bug is part of the fixes.

Cheers

[sPzAbt653]

I took the stock scenario which was crashing irregularly,

Do you mean the scenario that shipped with IV crashes?

Also, do you have the latest TOAW public version? If not, you need that. I don't know what it is, but if you don't either I am sure someone here will tell you.

[StuartG]

ORIGINAL: cathar1244

Best guess is the crash to desktop bug that has affected several scenarios.

One player has noted naval movement in the enlarged version of "Next War in Europe" seemed to trigger crashes.

There is also a thought that the quantity of location names may be a culprit.

Last I recall, one of the troubleshooters believed it was a memory leak.

I've looked into things like odd terrain that is hidden, such as mountains in deep water hexes (editor artifacts). But no conclusions there.

Cheers

Thank you, that is a thought that occurred to me also. I have added a ton of new names, and it would be a reasonable explanation on why it is crashing.

I dont recall this ever being a problem with earlier versions. It might be something they ought to have a look at.

I do think its partly a memory leak. Because I noticed that with the earlier version I had, if you loaded back in the autosave, then it would carry on and I could complete the scenario without problems. However the larger version means it kicks out after 2 turns, even if I load the autosave. Very strange.

I might release it as it is without the upgraded map. At least then its possible to play it past turn 2. A shame, I put a lot of work into making the Eastern European rail system halfway accurate.

Thanks for the suggestions everybody.

[LLv34_Snefens]

Arriving a little late, but I noticed a similar issue, and with some testing it is quite easy to reproduce the crash on my PC.

It has to do with the names indeed. As an example try loading Bob Cross' "France 1944 D-DAY" as it has a fairly large amount of place names. After loading up the scenario, bring up the windows task manager and watch memory usage. As you scroll around places with many names popping up you will see this usage steadily increase, eventually reaching over 1GB. Usually my game shuts down once you reach around 1.5GB.
Now reload the scenario, turn off place names and repeat the scrolling around. Notice the memory usage doesn't increase like before. Interestingly, if you enable names, but un-check the windows font checkbox the RAM usage also only increases very slowly, but still more than if you remove names all-together

[cathar1244]

Arriving a little late, but I noticed a similar issue, and with some testing it is quite easy to reproduce the crash on my PC.

It has to do with the names indeed. As an example try loading Bob Cross' "France 1944 D-DAY" as it has a fairly large amount of place names. After loading up the scenario, bring up the windows task manager and watch memory usage. As you scroll around places with many names popping up you will see this usage steadily increase, eventually reaching over 1GB. Usually my game shuts down once you reach around 1.5GB.
Now reload the scenario, turn off place names and repeat the scrolling around. Notice the memory usage doesn't increase like before. Interestingly, if you enable names, but un-check the windows font checkbox the RAM usage also only increases very slowly, but still more than if you remove names all-together

Interesting, thanks for the comments. I've wondered why one doesn't hear much about crashes of the monster eastern front scenarios, as I -think- they also have a lot of place-names.

Cheers

[Cpl GAC]

I've had crashes in the east front monsters;

This scenario is fantastic. The curveballs the PO has for the 1941 advance are very exciting. By the time I figured out the axes of the main thrusts I had a hard time getting the kitchen sink into the Valdai Hills to throw at them. One thing I noticed but did not document (sorry) - right around turn 7 of both games I've played as the Soviets during the Axis PO move the game crashes. The program just closes - and runs fine again when I restart the saved.
...

Not sure the causes of the crashes are related but my habit is now to save once or more per turn... Nothing is more frustrating than trying to repeat what you thought was a really well-thought-out series of moves.

[cathar1244]

Saw this on my system as well. As place names pop up, memory is allocated but never released. Thus, memory usage grows until the program crashes to desktop. I also noted how slow the memory growth is when no place names are displayed. This may seem like a pain when playing a scenario, but cities can be moused over and the place name is displayed at the bottom of the screen. Not ideal, but may allow problem scenarios to be played longer without crashes taking place.

Of note: this takes place only when a scenario is being played. In the scenario editor, this effect is not seen; RAM usage remains more or less constant.

Good catch and easy to reproduce, as you note, with Windows task manager.

Cheers

Arriving a little late, but I noticed a similar issue, and with some testing it is quite easy to reproduce the crash on my PC.

It has to do with the names indeed. As an example try loading Bob Cross' "France 1944 D-DAY" as it has a fairly large amount of place names. After loading up the scenario, bring up the windows task manager and watch memory usage. As you scroll around places with many names popping up you will see this usage steadily increase, eventually reaching over 1GB. Usually my game shuts down once you reach around 1.5GB.
Now reload the scenario, turn off place names and repeat the scrolling around. Notice the memory usage doesn't increase like before. Interestingly, if you enable names, but un-check the windows font checkbox the RAM usage also only increases very slowly, but still more than if you remove names all-together