POE 2 Complete PC Freeze while loading screen

no i get your agenda i am aware fully of what goes on concerning my PC.

It was a windows issue, claiming you know whats going on my PC more than i do is the height of arrogance.

Not sure why you are banging on about rolbacks i didnt rolback my PC at all.

I also dont get why you are still hanging on forums for a game you clearly hate so much
Última edição por andred#5148 em 16 de fev de 2025 10:07:10
I'm going to agree to disagree, if there was a block user option i'd use it on you.

All my replies do is give you a chance to copy and paste ( now 30-40 times) the same ridiclous claims

Última edição por andred#5148 em 16 de fev de 2025 10:52:55
I just had my first total freeze since a few days back.

My story with the latest update:

1. Patch hit, I try it. Seem nice. Update some settings. Retart the game, Booom! freeze on the first loading screen.
2. Figure the first load screen might not fall under the temporary fix. Gp to the forum and see that many ppl still experience the freezes but it is fixed for some.
3. Continue to play with cores disabled and poeUnchrasher. Get a total freeze when opening the caravan map.
4. Contact community manager, tell him whatever fix they implemented doesn't work. Tell him that disabling multi-threading always works for me, only to learn that the fix is suppose to disable multi-threading on all load screens, no exception. Community manager sends me to a page with "common solutions" to crashes for Poe1.
4. I wipe the shader cache, as it is one of the suggested solutions. And keep
playing with cores disabled and poeUnchrasher.
5. After not having any crash for 2 straight days of gaming. I'm thinking, "ok, maybe old crashed currupted my shader cache and the fix is actually working."
6. Play on for several more days with all cores enabled and no poeUncrasher. Problem seems fixed. "Wohooo. finally. Only like what 3 months?"
7. Today when loading Dashar or whatever the act 2 place is called. I get another total freeze.

Conclusion, the fix works in most cases but not all. Its either that the fix is not properly implementet and that the disabling of milti-threading is to slow or not working in some cases. It could also be that the shader-cache gets easily corrupted. Once it is corrupted, crashes starts happen regularly. I've seen others claim that wiping the shader cache works for a while and then the crashes start happening again.

Could be a combination of the two.

It would be super strange though, if I get a total freeze when multi-threading is disabled. How can the game freeze my whole computer if it is only using 1 core. That makes no sense. The only explanation, other than the fix is not working in all cases, is that windows is somehow confuced behind the scenes and uses all of the other cores, seems unlikely imo. Maybe I just don't understand how it works?

My next test will be to wipe the shader-cache and then disable the cashing all together in nvidia settings. I think this can be done. Or maybe I should just give up. I think I just give up until they actually figure this stuff out for real.

Sigh.

"
andred#5148 escreveu:
I'm going to agree to disagree, if there was a block user option i'd use it on you.

All my replies do is give you a chance to copy and paste ( now 30-40 times) the same ridiclous claims



There is nothing to agree or disagree here. Only pure facts. You can either accept the facts or keep being ignorant.

Facts are:

1) This is not a Windows 11 24H2 issue according to Microsoft. Microsoft is very transparent about anything that are caused by their own faults. Always has been.

2) Act of updating or rolling back changes a lot "under the hood" of your OS, which works as a temporary fix because among one of the many changes is the reset of the trigger that PoE2 triggers that result in hard crashes.

3) The hard crashes are directly caused by PoE2's code itself and nothing else. That is why this issue is OS-independent. Linux has it, Windows 10 has it, Windows 11 has it.

So you can either offer factual information about how this is a Windows 11 24H2 issue and prove that Microsoft is wrong about their own product or just accept that you did not know much about computers as you think you do, read the information, and gain new knowledge.

If only GGG were honest we would not even have to have this conversation... We could simply look at GGGs explanation of the situation with proper technical information but we can never know why exactly this is happening as GGG keeps being dodgy and dishonest. By the way, Microsoft is still not acknowledging this is a Windows 11 24H2 issue as claimed by GGG.

As long as GGG is not interested in open and honest communication our only other option is to increase the pressure and warn others by giving a negative review for Path of Exile 2 on Steam in a detailed and informative manner.
I cannot send/reply to direct messages because my in-game character has not finished Act 1.
What to do:
1)Write a short review about the hard crashes in notepad.
2)Copy and paste it to steam reviews, put up a negative review.
3)Copy and paste it to steam discussions, put it up there.
"
andred#5148 escreveu:
no i get your agenda i am aware fully of what goes on concerning my PC.

It was a windows issue, claiming you know whats going on my PC more than i do is the height of arrogance.

Not sure why you are banging on about rolbacks i didnt rolback my PC at all.

I also dont get why you are still hanging on forums for a game you clearly hate so much


Linux users have the same crashes
How possible is it that this is an issue with DX12/Vulkan and the game's code seeing how seeing how it has direct administrative access to the kernel and both Windows and Linux (using emulation, Wine/Proton for DX12) use it. DX12 and Vulkan have similar code bases. Just a thought.
After the 20+ computer freezes I've had in Poe 2, now I am also encountering the same issue in Poe 1. No other games do I have issues. 7800x3d/4080s/32gb 6000mhz/3440x1440p. To stop the computer freezes I have to use vulkan and disable core 0-1.
"
0:011> k
# Child-SP RetAddr Call Site
00 000000c3`6bbf7810 00007ff7`fe110a47 KERNELBASE!RaiseException+0x8a
01 000000c3`6bbf7910 00007ff7`fe107020 PathOfExileSteam+0x2360a47
02 000000c3`6bbf7980 00007ff7`fe1d1d18 PathOfExileSteam+0x2357020
03 000000c3`6bbf79b0 00007ff7`fe106f80 PathOfExileSteam+0x2421d18
04 000000c3`6bbf79e0 00007ff7`fe0fde9e PathOfExileSteam+0x2356f80
05 000000c3`6bbf7a10 00007ff9`263a3886 PathOfExileSteam+0x234de9e
06 000000c3`6bbf7ae0 00007ff7`fca05dc9 ntdll!RcConsolidateFrames+0x6
07 000000c3`6bbffb20 00007ff9`24ace8d7 PathOfExileSteam+0xc55dc9
08 000000c3`6bbffb80 00007ff9`2633bf2c KERNEL32!BaseThreadInitThunk+0x17
09 000000c3`6bbffbb0 00000000`00000000 ntdll!RtlUserThreadStart+0x2c


"

(212c.22fc): Unknown exception - code e0000001 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.


Here we go again. Hey, at least we have Map stash tab #sarcasm
Ok, so because I was angry and my pc still freezes I was investigating the bug a bit more and it seems to be a deadlock at first glance. I triggered the bug multiple times with multiple breakpoints.

This is the thread that calls RaiseException (the following stack strace is right before calling RaiseException):
"
0:017> k
# Child-SP RetAddr Call Site
00 000000ea`a29f83a0 00007ff7`fe110a47 PathOfExileSteam+0xd78fd
01 000000ea`a29f83d0 00007ff7`fe107020 PathOfExileSteam+0x2360a47
02 000000ea`a29f8440 00007ff7`fe1d1d18 PathOfExileSteam+0x2357020
03 000000ea`a29f8470 00007ff7`fe106f80 PathOfExileSteam+0x2421d18
04 000000ea`a29f84a0 00007ff7`fe0fde9e PathOfExileSteam+0x2356f80
05 000000ea`a29f84d0 00007ff9`263a3886 PathOfExileSteam+0x234de9e
06 000000ea`a29f85a0 00007ff7`fca05dc9 ntdll!RcConsolidateFrames+0x6
07 000000ea`a29ffd50 00007ff9`24ace8d7 PathOfExileSteam+0xc55dc9
08 000000ea`a29ffdb0 00007ff9`2633bf2c KERNEL32!BaseThreadInitThunk+0x17
09 000000ea`a29ffde0 00000000`00000000 ntdll!RtlUserThreadStart+0x2c


so PathOfExileSteam+0xd78fd looks like this in assembly:

"
.text:00000001400D78E0 Function proc near ; DATA XREF: Function+4↓o
.text:00000001400D78E0 ; sub_1400E33C0+E↓o ...
.text:00000001400D78E0 sub rsp, 28h
.text:00000001400D78E4 lea rdx, Function ; Function
.text:00000001400D78EB mov ecx, 16h ; Signal
.text:00000001400D78F0 call signal
.text:00000001400D78F5 xor r9d, r9d
.text:00000001400D78F8 xor r8d, r8d
.text:00000001400D78FB xor edx, edx
.text:00000001400D78FD mov ecx, 0E0000001h <--- this is the exception code and here is the address where i put a bp
.text:00000001400D7902 add rsp, 28h
.text:00000001400D7906 jmp cs:RaiseException
.text:00000001400D7906 Function endp


Now we know that an exception is generated but we need to find what causes this exception. Since sometimes the instance loading was working I was thinking about investigating some race condition.
"

0:017> !locks

CritSec +88061350 at 000001fc88061350
WaiterWoken No
LockCount 0
RecursionCount 1
OwningThread 18f0
EntryCount 0
ContentionCount 1820
*** Locked


So we have a critical section that is owned by thread with threadId 0x18f0.

Those are all the threads:
"

0:017> ~
0 Id: 4e84.38c Suspend: 1 Teb: 000000ea`9903e000 Unfrozen "MainThrd"
2 Id: 4e84.5558 Suspend: 1 Teb: 000000ea`99196000 Unfrozen
3 Id: 4e84.3d00 Suspend: 1 Teb: 000000ea`991ae000 Unfrozen
4 Id: 4e84.32d4 Suspend: 1 Teb: 000000ea`99198000 Unfrozen
6 Id: 4e84.fe4 Suspend: 1 Teb: 000000ea`991b8000 Unfrozen
7 Id: 4e84.dfc Suspend: 1 Teb: 000000ea`9904c000 Unfrozen
8 Id: 4e84.3240 Suspend: 1 Teb: 000000ea`99080000 Unfrozen
9 Id: 4e84.4c0 Suspend: 1 Teb: 000000ea`99082000 Unfrozen
10 Id: 4e84.3efc Suspend: 1 Teb: 000000ea`99084000 Unfrozen
11 Id: 4e84.51bc Suspend: 1 Teb: 000000ea`99086000 Unfrozen
12 Id: 4e84.55ac Suspend: 1 Teb: 000000ea`99088000 Unfrozen
13 Id: 4e84.1ecc Suspend: 1 Teb: 000000ea`9908a000 Unfrozen
14 Id: 4e84.44e8 Suspend: 1 Teb: 000000ea`9908c000 Unfrozen
15 Id: 4e84.5048 Suspend: 1 Teb: 000000ea`9908e000 Unfrozen
16 Id: 4e84.5114 Suspend: 1 Teb: 000000ea`99090000 Unfrozen
. 17 Id: 4e84.3948 Suspend: 1 Teb: 000000ea`99092000 Unfrozen
18 Id: 4e84.53b0 Suspend: 1 Teb: 000000ea`99094000 Unfrozen
19 Id: 4e84.4534 Suspend: 1 Teb: 000000ea`99096000 Unfrozen
20 Id: 4e84.449c Suspend: 1 Teb: 000000ea`99098000 Unfrozen
21 Id: 4e84.54dc Suspend: 1 Teb: 000000ea`9909a000 Unfrozen
22 Id: 4e84.567c Suspend: 1 Teb: 000000ea`9909c000 Unfrozen
23 Id: 4e84.4dec Suspend: 1 Teb: 000000ea`9909e000 Unfrozen
24 Id: 4e84.53b8 Suspend: 1 Teb: 000000ea`990a0000 Unfrozen
25 Id: 4e84.5754 Suspend: 1 Teb: 000000ea`990a2000 Unfrozen
26 Id: 4e84.1a08 Suspend: 1 Teb: 000000ea`990a4000 Unfrozen
27 Id: 4e84.33d8 Suspend: 1 Teb: 000000ea`990a6000 Unfrozen
28 Id: 4e84.2f2c Suspend: 1 Teb: 000000ea`990a8000 Unfrozen
29 Id: 4e84.436c Suspend: 1 Teb: 000000ea`990aa000 Unfrozen
30 Id: 4e84.2bbc Suspend: 1 Teb: 000000ea`990ac000 Unfrozen
32 Id: 4e84.134c Suspend: 1 Teb: 000000ea`990b0000 Unfrozen
33 Id: 4e84.18f0 Suspend: 1 Teb: 000000ea`990b2000 Unfrozen <--- thread that owns the lock
34 Id: 4e84.2408 Suspend: 1 Teb: 000000ea`990b4000 Unfrozen
35 Id: 4e84.259c Suspend: 1 Teb: 000000ea`990b6000 Unfrozen
36 Id: 4e84.4564 Suspend: 1 Teb: 000000ea`990b8000 Unfrozen
37 Id: 4e84.5398 Suspend: 1 Teb: 000000ea`990ba000 Unfrozen "BinkAsy0"
38 Id: 4e84.4744 Suspend: 1 Teb: 000000ea`990bc000 Unfrozen "BinkAsy1"
39 Id: 4e84.4ff0 Suspend: 1 Teb: 000000ea`990f2000 Unfrozen
41 Id: 4e84.3354 Suspend: 1 Teb: 000000ea`990fa000 Unfrozen
42 Id: 4e84.2bc8 Suspend: 1 Teb: 000000ea`990fc000 Unfrozen
43 Id: 4e84.21cc Suspend: 1 Teb: 000000ea`990fe000 Unfrozen "sl.log"
44 Id: 4e84.5490 Suspend: 1 Teb: 000000ea`99116000 Unfrozen
45 Id: 4e84.2374 Suspend: 1 Teb: 000000ea`9911a000 Unfrozen
46 Id: 4e84.5778 Suspend: 1 Teb: 000000ea`9911c000 Unfrozen
47 Id: 4e84.2c78 Suspend: 1 Teb: 000000ea`9911e000 Unfrozen
48 Id: 4e84.b00 Suspend: 1 Teb: 000000ea`99120000 Unfrozen
49 Id: 4e84.2314 Suspend: 1 Teb: 000000ea`99122000 Unfrozen "D3D Background Thread 0"
50 Id: 4e84.5674 Suspend: 1 Teb: 000000ea`99124000 Unfrozen "D3D Background Thread 1"
51 Id: 4e84.1a0 Suspend: 1 Teb: 000000ea`99126000 Unfrozen "D3D Background Thread 2"
52 Id: 4e84.1494 Suspend: 1 Teb: 000000ea`99128000 Unfrozen "D3D Background Thread 3"
53 Id: 4e84.3440 Suspend: 1 Teb: 000000ea`9912a000 Unfrozen
54 Id: 4e84.1798 Suspend: 1 Teb: 000000ea`9912c000 Unfrozen
55 Id: 4e84.4f30 Suspend: 1 Teb: 000000ea`9912e000 Unfrozen
56 Id: 4e84.5748 Suspend: 1 Teb: 000000ea`99130000 Unfrozen
57 Id: 4e84.4eb8 Suspend: 1 Teb: 000000ea`99132000 Unfrozen
58 Id: 4e84.33f0 Suspend: 1 Teb: 000000ea`99134000 Unfrozen
59 Id: 4e84.28e4 Suspend: 1 Teb: 000000ea`99136000 Unfrozen
60 Id: 4e84.11b0 Suspend: 1 Teb: 000000ea`99138000 Unfrozen
62 Id: 4e84.4e24 Suspend: 1 Teb: 000000ea`9913c000 Unfrozen
63 Id: 4e84.3494 Suspend: 1 Teb: 000000ea`9913e000 Unfrozen
64 Id: 4e84.1340 Suspend: 1 Teb: 000000ea`9914a000 Unfrozen
66 Id: 4e84.2124 Suspend: 1 Teb: 000000ea`9914e000 Unfrozen
68 Id: 4e84.10fc Suspend: 1 Teb: 000000ea`99152000 Unfrozen
71 Id: 4e84.2a84 Suspend: 1 Teb: 000000ea`99164000 Unfrozen
72 Id: 4e84.1f58 Suspend: 1 Teb: 000000ea`99170000 Unfrozen



And this is the stacktrace for the thread that owns that critical section:
"
0:017> ~[33] k
# Child-SP RetAddr Call Site
00 000000ea`b61ff9e8 00007ff9`262f3524 ntdll!NtWaitForAlertByThreadId+0x14
01 000000ea`b61ff9f0 00007ff9`23afde78 ntdll!RtlSleepConditionVariableSRW+0x1c4
02 000000ea`b61ffa90 00007ff9`23a23d2d KERNELBASE!SleepConditionVariableSRW+0x38
03 000000ea`b61ffad0 00007ff9`23a1f4a9 msvcp_win!Concurrency::details::stl_condition_variable_win7::wait+0x19
04 000000ea`b61ffb00 00007ff8`7f4ee7ea msvcp_win!Cnd_wait+0x19
05 000000ea`b61ffb30 00007ff8`7f4ee704 D3D12Core!BackgroundTaskScheduler::Scheduler::TaskThread+0xb6
06 000000ea`b61ffc60 00007ff9`238837b0 D3D12Core!std::thread::_Invoke<std::tuple<<lambda_d1dcd43984ff6503e4a6a4b61a501ad9> >,0>+0x14
07 000000ea`b61ffc90 00007ff9`24ace8d7 ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x30
08 000000ea`b61ffcc0 00007ff9`2633bf2c KERNEL32!BaseThreadInitThunk+0x17
09 000000ea`b61ffcf0 00000000`00000000 ntdll!RtlUserThreadStart+0x2c


RecursionCount 1 suggests that thread 33 (TID == 0x18f0) took the lock once and somehow when the crash occurs that thread is in ntdll!NtWaitForAlertByThreadId+0x14

Now about the LockCount member from the CRITICAL_SECTION struct. In this case LockCount == 0

"
LockCount This is the most important field in a critical section. It is initialized to a value of -1; a value of 0 or greater indicates that the critical section is held or owned. When it's not equal to -1, the OwningThread field (this field is incorrectly defined in WINNT.H—it should be a DWORD instead of a HANDLE) contains the thread ID that owns this critical section. The delta between this field and the value of (RecursionCount -1) indicates how many additional threads are waiting to acquire the critical section.


So in this case LockCount - (RecursionCount - 1) is 0, meaning that there is no other thread waiting to acquire the critical section but somehow that critical section is still locked :| . So it seems like some kind of deadlock.

I hope this helps and this bug will be fixed....
I will try to investigate it further when I have some time
"
IceCool10#6669 escreveu:
Ok, so because I was angry and my pc still freezes I was investigating the bug a bit more and it seems to be a deadlock at first glance. I triggered the bug multiple times with multiple breakpoints.

I hope this helps and this bug will be fixed....
I will try to investigate it further when I have some time


From what I've seen:

First of all: All the first few frames are from PathOfExileSteam, meaning the crash originates within the game’s own code, not a system DLL (like ntdll.dll or KERNEL32.dll).

The code here is also seems to be a recurring or a looping one unless they are all together within one single manager.

This is a stack unwinder: "06 000000ea`a29f85a0 00007ff9`263a3886 ntdll!RcConsolidateFrames+0x6"

It is used when Windows unwinds the stack after an exception.

"jmp cs:RaiseException at 0x1400D7906" suggests this function deliberately triggers an exception. As in the code itself calls the exception. This is not a standard Windows exception such as 0xC0000005 for access violation or 0xC00000FD for stack overflow. It is probably their debug process.

Now normally if I were to see something like this without having the context I would say this function is part of an error reporting system and its job is to ensure that when something unexpected happens, the game crashes in a controlled manner rather than behaving unpredictably.

In our case however, for some reason it doesn't do that and instead behaves unpredictably. Like you have said this is probably due to a deadlock.

Since Lock Count is 0 it means no thread has attempted to acquire the lock after thread 18f0 locked it and since Recursion Count is 1 this is the first and only lock acquisition by this thread.

"ContentionCount 1820" means that 000001fc88061350 has been requested 1820 times by other threads. So the problem is here. Since WaiterWoken is No, no thread has been released from waiting on this lock. The thread 18f0 is holding it firmly.

Further down the line you have used k to see that

There is probably a wake signal that is commented out.

Because the thread is not actively running but is waiting indefinitely inside SleepConditionVariableSRW() - this is by the way a standard system API used for thread synchronization, it makes a thread wait (sleep) until another thread signals a condition variable. It is implemented in KERNELBASE.dll and internally calls RtlSleepConditionVariableSRW() from ntdll.dll.

So the only way I can think of that can lead this to happen is that the thread is waiting on a condition variable that never comes due to faulty programming.

This is a thread synchronization issue:
1) The thread belongs to Direct3D 12's background task scheduler.

2) It is inside a task loop, but instead of executing work, it is waiting for a condition to be met.

3) This means it is expecting another thread to push work into the queue and notify it, and that may not be happening.

This is not an immediate crash. The thread is stuck waiting for a condition variable that never gets signaled.

The system freezes because other threads are likely waiting on this one, causing a cascading stall.

Which is what we have been experiencing since 2 months. The game engine mishandles worker thread synchronization. If the GPU is waiting for CPU work and the CPU is waiting for a GPU response, the system enters a fatal deadlock.

My guess is a commented out code.

To debug this we need to find which other thread was supposed to call WakeConditionVariable().

If you have time could you please use send the full result when you run !stacks.

We can then look for threads that are waiting on a lock or another condition variable and/or threads that might have been responsible for signaling Thread 33.

Obligatory:
If only GGG were honest we would not even have to have this conversation... We could simply look at GGGs explanation of the situation with proper technical information but we can never know why exactly this is happening as GGG keeps being dodgy and dishonest. By the way, Microsoft is still not acknowledging this is a Windows 11 24H2 issue as claimed by GGG.

As long as GGG is not interested in open and honest communication our only other option is to increase the pressure and warn others by giving a negative review for Path of Exile 2 on Steam in a detailed and informative manner.
I cannot send/reply to direct messages because my in-game character has not finished Act 1.
What to do:
1)Write a short review about the hard crashes in notepad.
2)Copy and paste it to steam reviews, put up a negative review.
3)Copy and paste it to steam discussions, put it up there.
Última edição por Cainrith#2807 em 17 de fev de 2025 18:28:13

Reportar Post do Fórum

Reportar Conta:

Tipo de Reporte

Informação Adicional