What causes memory couldnt be read error here?

[Kacpa2]

Hello, since i couldnt really decide where this should be i post it her :v

I work on the map for longer time but i still get issue with it's random memory could not be read crashing that has no reason whatsoever and has no repating pattern, more over only some people crash rest stays in game.

I removed every leak that matters(except fixed floating text that is just there since begining and forever so it isnt dynamic or anything neither repeating)from some not portal based teleports to income(it so good that it doesnt even pick all units in the map so it's quicker) all of them have proper destroy code, crash seems to be random, probably something is making game exceed some cache limit.
Map is 5.2mb heavy, is around 350x350(i seen bigger more complex maps that dont crash), has some imports, code/triggerwork is perfectly fine since last update(no leaks, better income trigg) and it appears that leak fix and rest stuff didnt change it a bit, it still gets crash in random point in time for some people in the game.

I used all options from Map Optimizer V5 on it if it may be some clue. But overall i dont see reason for it to be so crashy at all, except the size, but as i said there are even bigger maps that dont crash at all :/
I can post screens of trigger work and imports if needed

 

[DracoL1ch]

always attach the log from /errors with .txt extension. it could contain at least something.

 

[Kacpa2]

I looked trough them tehre is nothing repeating, nothing causing struggle of the game to load it, it just has last rendered stuff, and when i got crash logs of other people who crashed is same moment they dont have anything in common in memory dump. Tough i can attach it.
It seems something i just causing the game to exceed capabilities of most pcs when it comes to memory, question is what and why...

 

[DracoL1ch]

things to look up for:

 

[Kacpa2]

I checked it, it's normal missile that i used on one of custom gryphon units, other one is just generic teal circle around aura affected units. I have few more crash longs, nothing repeats, and it seems really random. In other it's lightin, some other not related stuff, from other people's crash logs(from same crash) i got different stuff. I can post some of trigger work if needed(tough as i said there are no loops at all, and all repeative leaks were removed in last update of the map.

 

[Dr Super Good]

Without the source code, or more specifically the debug symbols, we cannot tell what is causing the crash exactly.

The fact this is all art of some kind (models) points towards some bug in the render code. This could be the result of the recent migration from D3D8 to D3D9. It could also be the result of a bug in the old render code which seldom crashed due to how D3D8 works compared with D3D9.

Try running Warcraft III in OpenGL mode. That API backend should not have changed. Be warned that text is slightly malformed (artefacts are visible). This would rule out the migration to D3D9 being the cause and instead point towards the rebuild with a more recent MSVC redistributable as the suspect.

5CCD7840 003F918C 0001:00196840 c:\program files\warcraft iii\Game.dll
5CC7C913 003F91BC 0001:0013B913 c:\program files\warcraft iii\Game.dll
5CC7C47F 003F91E8 0001:0013B47F c:\program files\warcraft iii\Game.dll

If people could identify what these function calls do it might also help.

 

[Kacpa2]

Without the source code, or more specifically the debug symbols, we cannot tell what is causing the crash exactly.

The fact this is all art of some kind (models) points towards some bug in the render code. This could be the result of the recent migration from D3D8 to D3D9. It could also be the result of a bug in the old render code which seldom crashed due to how D3D8 works compared with D3D9.

Try running Warcraft III in OpenGL mode. That API backend should not have changed. Be warned that text is slightly malformed (artefacts are visible). This would rule out the migration to D3D9 being the cause and instead point towards the rebuild with a more recent MSVC redistributable as the suspect.

5CCD7840 003F918C 0001:00196840 c:\program files\warcraft iii\Game.dll
5CC7C913 003F91BC 0001:0013B913 c:\program files\warcraft iii\Game.dll
5CC7C47F 003F91E8 0001:0013B47F c:\program files\warcraft iii\Game.dll

If people could identify what these function calls do it might also help.

Hello, i tested it with OpenGl, i also expanded virtual memory alot aaaand it crashed as always at random point in time.
I have 2 separate(3rd may come around tomorrow, cuz my friend couldnt send it to me today)crash logs. Take a look please.

 

[Dr Super Good]

Ok this is highly likely a bug with their migration to MSVCR120. Both crashes in same MSVC function from same Game.dll function on different systems.

64411595 001E95C8 0001:00010595 C:\Windows\system32\MSVCR120.dll
5FB55C2B 001E95EC 0001:00774C2B c:\program files\warcraft iii\Game.dll

6FA21595 00389294 0001:00010595 C:\Windows\system32\MSVCR120.dll
60A15C2B 003892B8 0001:00774C2B d:\warcraft iii\warcraft iii\Game.dll

If someone could find out what "0001:00774C2B" is doing it may yield information useful to help Blizzard fix the problem next patch.

 

[Kacpa2]

Ok this is highly likely a bug with their migration to MSVCR120. Both crashes in same MSVC function from same Game.dll function on different systems.
If someone could find out what "0001:00774C2B" is doing it may yield information useful to help Blizzard fix the problem next patch.

Got the third crash log from another friend i mention previously. Ofc not all people crash, so it cant be map's fault really.

 

[Dr Super Good]

10011595 001298FC 0001:00010595 C:\WINDOWS\system32\MSVCR120.dll
6F775C2B 00129920 0001:00774C2B e:\warcraft iii\Game.dll

Same cause as the other 2 crashes. Same function Game.dll function, same MSVCR120 function.

MSVCR120 should have some debug symbols as the API is publicly available. Maybe one can debug what function WC3 is calling for some insight as to the nature of the crash. For example is it a graphics API function or a memory management function? The fact it does not crash everyone at once means it is something that is system local that is crashing. This usually is graphics, UI, sound etc.

 

[Kacpa2]

2 more recent crash logs i had, i had system formatted recently so i have few at the moment, i noticed that if there are less players game can last much longer(crash didnt even occur), but i'm speaking like 2-3 people instead of 12, it's must be issue with reusing memory caused by 1.27 changes.

 

[Dr Super Good]

2016-06-24 23.46.22 Crash.txt is unrelated from all the other crashes. 2016-06-25 01.53.25 Crash.txt is the same as the other crashes. Like I said before, debug the MSVC function that is crashing for some insight as to the possible cause.

 

[Kacpa2]

2016-06-24 23.46.22 Crash.txt is unrelated from all the other crashes. 2016-06-25 01.53.25 Crash.txt is the same as the other crashes. Like I said before, debug the MSVC function that is crashing for some insight as to the possible cause.

Well to be honest i dont even know how to do it xD. I looked around and there is no way for person with no knowledge on it to debug it really. I got another crash from another person if it's any use...

 

[Dr Super Good]

2016-07-05 19.56.25 Crash.txt is the same crash as the others.

I think the error log is trying to say it is crashing during a memset? The game is either trying to clear past a buffer bounds or it is trying to clear non-allocated pages. This could be caused by the game trying to process an object which has been destroyed, so the buffer it is trying to set has been deallocated.

 

[Kacpa2]

Well i doubt there is way for me to fix it is there?

 

[Dr Super Good]

If a replay could create this error reliably then I might be able to debug it further.

 

[Kacpa2]

Well as far as myknowledge on leaks goes, all dying units/buildings and spells like shockwave leave some memory locked but it's nano thing that is totally irrelevant and does not affect the game when hundreds of units die. This shouldnt cause the crash at all and didnt prior to update. I made test with my cousin while he was at my place and literaly over 2 tousand units have been killed during it and game didnt crash.

The prob with replays is this that when game crashes there is no replay and when i have ok play then it doesnt occur in game. The only way for me to get replay is from person that didnt crash and well always there is atlest 1-2 people who wont drop and will witness massive crash(econreset displayed by bots) to them.
It doesnt drop all people, then i doubt it's something that i can fix myself cuz it can be triggers or error in object editor it must be this mess with memory allocation :/

 

[Dr Super Good]

Would it be possible to dump the replays from the robot? Since the robots process all commands some of them can generate replay files automatically.

 

[Kacpa2]

Well MMH doesnt seem to have even any kind of remains of hosted game, so i doubt it, but i can get replay from person that didnt crash with the rest i just need to play a bit with them till another one occurs. There was one in which others crashed and i was left in together with 2 other people, at other times i crash and some other people stay ingame.

 

[Zwiebelchen]

A "memory could not be read" error in combination with only 1 player crashing instead of all can only mean one of two things from my experience:

- Leaks preventing handle IDs from getting recycled ... although that would mostly make all players run out of memory at almost the same time
- The memory error introduced by 1.27 ... It's been plagueing my game for quite some time now too and no, there's no fix for that yet

 

[Dr Super Good]

I would not be surprised if there is some buffer overrun issue with something graphic related. They moved to D3D9 which likely changed some of the struct arrangements/sizes. Much of the graphic code is not completely safe of buffer over run errors, I managed to get the game to load a texture from memory garbage as an example.

 

[Kacpa2]

A "memory could not be read" error in combination with only 1 player crashing instead of all can only mean one of two things from my experience:

- Leaks preventing handle IDs from getting recycled ... although that would mostly make all players run out of memory at almost the same time
- The memory error introduced by 1.27 ... It's been plagueing my game for quite some time now too and no, there's no fix for that yet

So i cannot do anything about it :/ I removed all leaks long ago and it still crashed at random. Is it in patch wishlist threads? Will Blizzard know that they have to fix it?

 

[Zwiebelchen]

It's not a definite proof that this is caused by the 1.27 patch. There is still a big chance that it's a user error on your side, depending on how good you are with what you're doing.

I was just raising awareness that this is a thing that exists. I still recommend applying the usual debugging practices before you shrug it off as something unfixable on your end:
- Deactivate parts of the map script one by one and check if the problem persists
- Go back to the last version in which the crash didn't happen and check all the differences between these versions
- If you find the faulty script, post it here for us to analyze.

 

[Kacpa2]

Amount of triggers isnt that high only leaks that were there are removed(position variables instead of just center in region) It doest crash on any trigger action it must be else, unit, ability, upgrade. Now i look on every unit and remove un nessesary duplicates i made prior. If that wont do i will rebuild the map maybe