https://bugs.winehq.org/show_bug.cgi?id=44061
--- Comment #14 from dereklesho52@Gmail.com --- I tried debugging this issue further, and it appears that a new issue has popped up.
Before the callback it passes in is called, the program fails when it tries to execute an unmapped area of memory
seh:NtRaiseException code=c0000005 flags=0 addr=0xe760ac ip=e760ac tid=0122 seh:NtRaiseException info[0]=0000000000000008 seh:NtRaiseException info[1]=0000000000e760ac seh:NtRaiseException rax=0000000000e50000 rbx=000000007bd78668 rcx=fffffffffffffffe rdx=0000000000000011 seh:NtRaiseException rsi=000000007bc20040 rdi=000000000000050a rbp=000000000052d480 rsp=000000000052d378 seh:NtRaiseException r8=0000000000000000 r9=0000000000000000 r10=0000000000e760ac r11=000000000000012c seh:NtRaiseException r12=000000007bc20000 r13=0000000000000040 r14=000000007bd75e18 r15=000000007bd79a90
In a relay log, before this occurs, it appears to allocate some memory close to where this exception occurs:
0121:0122:Call KERNEL32.VirtualAlloc(00000000,0000f3b4,00001000,00000040) ret=14028e00c 0121:0122:Ret KERNEL32.VirtualAlloc() retval=00e50000 ret=14028e00c
However, - This memory size isn't large enough to reach the point where they execute - They subsequently protect the memory as read-only before the exception happens
0121:0122:Call KERNEL32.VirtualProtect(00e50000,0000f3b4,00000020,0052d4f0) ret=14028e0af 0121:0122:Ret KERNEL32.VirtualProtect() retval=00000001 ret=14028e0af
I suspect that the execution is intended to happen within this allocation, and that the f3b4 it puts in for the size isn't correct. Although the VirtualProtect call seems to suggest otherwise.
Full log is attached