Hello,
My game keeps freezing so I took some time to try and investigate what's happening so here it is:
The event log looks like this:
"
AppName PathOfExileSteam.exe
AppVersion 0.0.0.0
AppTimeStamp 67888689
ModuleName KERNELBASE.dll
ModuleVersion 10.0.26100.2454
ModuleTimeStamp 398a1cce
ExceptionCode e0000001
FaultingOffset 00000000000c837a
ProcessId 0x920
After doing some reverse I saw that the event says that the hang is here:
"
.text:00000001800C836E 48 8D 4C 24 20 lea rcx, [rsp+0F8h+ExceptionRecord] ; ExceptionRecord
.text:00000001800C8373 48 FF 15 EE 77 1A 00 call cs:__imp_RtlRaiseException
.text:00000001800C837A 0F 1F 44 00 00 nop dword ptr [rax+rax+00h]
.text:00000001800C837F 48 8B 8C 24 C0 00 00 00 mov rcx, [rsp+0F8h+var_38]
.text:00000001800C8387 48 33 CC xor rcx, rsp ; StackCookie
on the nop instruction that as you might know it does nothing and it's probably just compiler magic to align some code blocks ( not getting into it). The thing is, the event says that it's a crash (Kernel-Power type) right after a call to RtlRaiseException from ntdll.dll ( the above code is from kernelbase.dll -> more exact from RaiseException that is more or less a wrapper to RtlRaiseException). Since the exception code is 0xe0000001 it's obviously not a standard windows exception code and I start looking into PoE2 assembly code and just one bit of code has this exception code in the main executable:
"
.text:00000001400D7610 Function proc near ; DATA XREF: Function+4↓o
.text:00000001400D7610 ; sub_1400E30D0+E↓o ...
.text:00000001400D7610 sub rsp, 28h
.text:00000001400D7614 lea rdx, Function ; Function
.text:00000001400D761B mov ecx, 16h ; Signal
.text:00000001400D7620 call signal
.text:00000001400D7625 xor r9d, r9d
.text:00000001400D7628 xor r8d, r8d
.text:00000001400D762B xor edx, edx
.text:00000001400D762D mov ecx, 0E0000001h
.text:00000001400D7632 add rsp, 28h
.text:00000001400D7636 jmp cs:RaiseException
.text:00000001400D7636 Function endp
Judging by the assembly code, seems that this is just a custom exception handler of some sort ( I might be wrong )
I saw that the above function is passed to another function labeled
signal by the decompiler as seen below:
"
.text:00000001400E30D0 push rbx
.text:00000001400E30D2 sub rsp, 20h
.text:00000001400E30D6 mov rbx, rcx
.text:00000001400E30D9 call sub_141AF08E0
.text:00000001400E30DE lea rdx, Function ; Function <---- this is the function that generates the hang given what event viewer is saying and it's passed as 2nd parameter to the signal function. The first parameter being a 32bit integer that has the 0x16 = 22 decimal value.
.text:00000001400E30E5 mov ecx, 16h ; Signal
.text:00000001400E30EA call signal
.text:00000001400E30EF lea rcx, sub_1400D7660
.text:00000001400E30F6 call set_terminate
.text:00000001400E30FB lea rcx, sub_1400D7680
.text:00000001400E3102 call set_unexpected
.text:00000001400E3107 nop
The signal function looks roughly like this ( just to help you identify the function easier ):
"
if ( (unsigned __int64)Function - 3 <= 1 )
goto LABEL_32;
if ( (unsigned int)Signal <= 0x16 )
{
v4 = 6324292;
if ( _bittest(&v4, Signal) )
{
v5 = 0;
v6 = 0LL;
_vcrt_lock_0(3LL);
if ( (Signal == 2 || Signal == 21) && !byte_1439F1AE2 )
{
if ( SetConsoleCtrlHandler(ctrlevent_capture, 1) )
{
byte_1439F1AE2 = 1;
}
else
{
LastError = GetLastError();
*_doserrno() = LastError;
v5 = 1;
}
}
global_action_nolock = get_global_action_nolock(Signal);
if ( global_action_nolock )
{
v6 = (void (__cdecl *)(int))__ROR8__(
(unsigned __int64)*global_action_nolock ^ _security_cookie,
_security_cookie & 0x3F);
if ( Function != (_crt_signal_t)2 )
*global_action_nolock = (void (*)(int))(_security_cookie ^ __ROR8__(
Function,
64 - ((unsigned __int8)_security_cookie & 0x3Fu)));
}
_vcrt_unlock_0(3LL);
if ( !v5 )
return v6;
goto LABEL_32;
}
}
if ( (unsigned int)Signal > 0xB )
goto LABEL_32;
v10 = 2320;
I also wanna mention that the hang usually happens when I am loading another instance ( for example going to the next region - for example going from Clearfell to The Grelwood - it''s just an example ). I also saw some addresses in another hang some days ago that looked like kernel addresses so ( and it's just my "reverse engineering" intuition ) that mmight be a bug related to multithreading and the video driver but I might be awfully wrong with this. I will try to investigate more when I have more time. Until then I hope this is useful to you :)
