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.
In crash log we see the values of
rax/rcx:
Code:
Registers:
RAX:0x00007ffffc801bf0 RBP:0x000000ffd6bf6f30 RCX:0x000000ffd6bf6f30 RDX:0x000000ffd6bf6f30
RBP:0x000000ffd6bf7000 RSI:0x00007ff7dce449e0 RDI:0x0000000000006318 R8:0x000000ffd6bf7b10
R9:0x00007ff7df86e1f0 R10:0x000000ffd6bf7850 R11:0x000000ffd6bf7730 R12:0x00007ff7df67cee8
R13:0x0000000000000000 R14:0x000000ffd6bf7b10 R15:0x0000000000000001
RSP:0x000000ffd6bf6ed0 RIP:0x00007ff7de819ea9 FLG:0x00000216
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.
Current stack address: Stack Base:
0x000000FFD6C00000
Currrent warcraft3.exe start address:
00007FF7DCB30000
- 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.
===
EDIT
Btw,
@MindWorX
generator for crash log is bugged,
"RBP" is written twice, while once it should be
"RBX".
View attachment 358159
