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 Last edited by andred#5148 on Feb 16, 2025, 10:07:10 AM
|
![]() |
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 Last edited by andred#5148 on Feb 16, 2025, 10:52:55 AM
|
![]() |
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. |
![]() |
" 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. |
![]() |
" 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.
|
![]() |
" " 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): " so PathOfExileSteam+0xd78fd looks like this in assembly: " 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. " So we have a critical section that is owned by thread with threadId 0x18f0. Those are all the threads: " And this is the stacktrace for the thread that owns that critical section: " 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 " 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 |
![]() |
" 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. Last edited by Cainrith#2807 on Feb 17, 2025, 6:28:13 PM
|
![]() |