Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
There's huge amount of lines of "model creation failed".
There are 60 lines of "path component index out of bounds".
=> this means "path component index out of bounds" alone is not unhandled exception, as it occurs many times. Wc3 tries to handle it, and then maybe just fails somewhere, and at a point just crashes.
So maybe it's related, but it could be that the "path component index out of bounds" has nothing to do with the actual crash cause.
Still... looking at Warcraft3.exe's memory for the "path component index out of bounds" string occurence:
So a guess, maybe a wrong path to a model, path is too long, wrong path inside model, what ever. @GhostWolf has created a sanity tester for your models. You can just drag & drop your map into it, and it would make some checks.
====
As said, the crash itself could be something different. So here's some overall look at the crash itself:
It's hard to find the exact source, it seems pretty complex. Looking at memory via CheatEngine:
^it's the crash position. It's an unhandled access violation. The line "edx, [rax+rcx*4]" is attempt to read array of 4 byte data type, like maybe integer array. rax/rcx etc are just common registers, like temp variables that are used to store values/addresses to operate with.
rcx value 0x000000ffd6bf6f30 / 1098819530544 (decimal) is much too big for an array index, so wc3 tries to read memory that isn't being allowed to read.
rcx starts with same stack address "0x000000FFD6" => it is most likely an address of something fom current stack. Maybe address from local variable.
2 questions:
why is rcx, array index so huge / invalid
what is rax, base address of array (what functionality)
reading Warcraft3.exe or client.sdk gave no solution what rax address is. It most likely no address from Warcraft3.exe.
After looking more closely, "07FF" from rax seems like it comes from external .dll. ( one can recognize it by other dll addresses, the lines after "<Exception.DebugModules:>" )
After some more analyse it seems rax is an address within memory bounds of kernel32.dll!
kernel.dll uses symbols for open API, so it's possible to track what functionality gets used without reverse engineering.
That being said, rax value just points in middle of function "RegistertWaitForSingleObject" of kernel32.dll. (used pretty often for stuff like ThreadSyncing) But that it doesn't event point to start-address but just in middle of function does make no sense at all.
What does it mean:
rax is just plain false, and has wrong address
you use other kernel32.dll
If rax is false, there's no chance from here on. You can't just look backwards old register values etc. Only other thing that might help is looking at war3.dmp file.
So what could help:
post kernel32.dll ( hopefully your windows hasn't updated your .dll since then)
post war3.dmp file in case you have ( one could maybe find out more about stack / the array)
Also, it would be interesting to know, does the crash happen only once/what map/under what conditions, etc.
Unrelated to OP's problem but possible fix for anyone finding this:
So i created a custom folder to easily find the td map i play the most, and named the folder #Mapname so it's on top.
After a few solo games i discovered i could build on the path, thought it was just a random bug. But it stayed across games, weird. Then when i played with other people the map would consistently crash after a while and give me "ERR: path component index out of bounds" in logs. It's only after a few days of searching for a fix that i figured - no fcking way - is it because of that # in path name? Of course it was. Just removed the # and it was all fixed. Literally an exploit for certain TD maps...
Absolutely sure! Put # in folder name, you can now build on path and will consistently crash if you play with other people, remove # and all is fixed. Works with Pumpkin TD and Blacksmith TD so far, probably triggers all kinds of interesting bugs in other maps.
As said you could made a own thread for it. Explaining the issue, shortly phrasing your expectation, and shortly phrasing what actually happens, for each picture/situation.
There's huge amount of lines of "model creation failed".
There are 60 lines of "path component index out of bounds".
=> this means "path component index out of bounds" alone is not unhandled exception, as it occurs many times. Wc3 tries to handle it, and then maybe just fails somewhere, and at a point just crashes.
So maybe it's related, but it could be that the "path component index out of bounds" has nothing to do with the actual crash cause.
Still... looking at Warcraft3.exe's memory for the "path component index out of bounds" string occurence:
So a guess, maybe a wrong path to a model, path is too long, wrong path inside model, what ever. @GhostWolf has created a sanity tester for your models. You can just drag & drop your map into it, and it would make some checks.
====
As said, the crash itself could be something different. So here's some overall look at the crash itself:
It's hard to find the exact source, it seems pretty complex. Looking at memory via CheatEngine: View attachment 358153
^it's the crash position. It's an unhandled access violation. The line "edx, [rax+rcx*4]" is attempt to read array of 4 byte data type, like maybe integer array. rax/rcx etc are just common registers, like temp variables that are used to store values/addresses to operate with.
rcx value 0x000000ffd6bf6f30 / 1098819530544 (decimal) is much too big for an array index, so wc3 tries to read memory that isn't being allowed to read.
rcx starts with same stack address "0x000000FFD6" => it is most likely an address of something fom current stack. Maybe address from local variable.
2 questions:
why is rcx, array index so huge / invalid
what is rax, base address of array (what functionality)
reading Warcraft3.exe or client.sdk gave no solution what rax address is. It most likely no address from Warcraft3.exe.
After looking more closely, "07FF" from rax seems like it comes from external .dll. ( one can recognize it by other dll addresses, the lines after "<Exception.DebugModules:>" )
After some more analyse it seems rax is an address within memory bounds of kernel32.dll!
kernel.dll uses symbols for open API, so it's possible to track what functionality gets used without reverse engineering.
That being said, rax value just points in middle of function "RegistertWaitForSingleObject" of kernel32.dll. (used pretty often for stuff like ThreadSyncing) But that it doesn't event point to start-address but just in middle of function does make no sense at all.
What does it mean:
rax is just plain false, and has wrong address
you use other kernel32.dll
If rax is false, there's no chance from here on. You can't just look backwards old register values etc. Only other thing that might help is looking at war3.dmp file.
So what could help:
post kernel32.dll ( hopefully your windows hasn't updated your .dll since then)
post war3.dmp file in case you have ( one could maybe find out more about stack / the array)
Also, it would be interesting to know, does the crash happen only once/what map/under what conditions, etc.
Sorry for delay, I've been thinking this thread has been ignored.
kernel32.dll file seems to be updated, I'll upload it anyway. last modified date is September 11th.
war3.rar is the .dmp file at the time of that error. And the third file is the logs of the most recent crash. Crashes aren't very frequent, but they do still happen.
I watch the crash replays many times, but can't find no common conditions or specific actions there. and this crash doesn't just kill one player(this was a very frequent pattern in the Classic War 3 client, but it completely disappeared after Reforged), but all of the players crash.
Hey just posted here for people looking for clues about this particular error in logs, as this is the only forum referencing it and i can't post on the stupid Blizzard forums for whatever reason. Sorry for the off topic necro.
Reproducing the bug is trivial, just put any custom map in a folder starting with #. For now the only things i noticed : game can't find loading background pic and replaces it with a black screen, you can build on the path in most TD maps which is a ridiculous exploit, and you'll crash mid game only when you play with other people. 100% reproducible.
But you keep posting here. The whole point to make a thread for your problem is to have it more in a spot light. It's then the main thread topic and can be referenced being subject for blizzard employee to potentially look at it/fix it. Demo, good explanations etc. You don't need explain it only for me. If you don't care wasting some minutes, no problem, but your decission.
Hey just posted here for people looking for clues about this particular error in logs, as this is the only forum referencing it and i can't post on the stupid Blizzard forums for whatever reason. Sorry for the off topic necro.
Reproducing the bug is trivial, just put any custom map in a folder starting with #. For now the only things i noticed : game can't find loading background pic and replaces it with a black screen, you can build on the path in most TD maps which is a ridiculous exploit, and you'll crash mid game only when you play with other people. 100% reproducible.
Sorry for the necropost, but I just found this thread today and decided to do some testing with it for multiplayer. Here are my findings:
When the host hosts the map from # folder, if the other players that join the lobby also have the map in a # folder, no one desyncs. If the other players DON'T have the map in a # folder, they will desync.
When I hosted my map from a normal non-# folder, I had the other tester join with the map in a # folder on his end, and it did not prompt a re-download, and I was the one that desynced. He still stayed in the map.
When the host hosts the map from # folder, if the other players that join the lobby also have the map in a # folder, no one desyncs. If the other players DON'T have the map in a # folder, they will desync.
When I hosted my map from a normal non-# folder, I had the other tester join with the map in a # folder on his end, and it did not prompt a re-download, and I was the one that desynced. He still stayed in the map.
This is to be expected as there will be a state deviation (one client builds on path, other client tries to build on path but sanity checkers cause the order to fail so nothing is built on path) and so cause a checksum mismatch.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
