POE 2 Complete PC Freeze while loading screen

"

Braric#4417 wrote:

Someone should start a class action lawsuit to refund the early access purchase price.

They delivered not even half of what they promised in EA and the game is actually unplayable.

"

Cainrith#2807 wrote:

"

IceCool10#6669 wrote:

Long Block Of Code

Before we start: Please run 0:015> r.

My observations:

Thread 15 (502c): Raising an Exception but more importantly it is not waiting, instead it is actively crashing. If this thread was supposed to signal one of the waiting threads, the wake-up signal is lost, causing the other threads to remain stuck. In our case it is.

Threads 16, 17, 18, 19: These are stuck in SleepConditionVariableSRW(). Since Thread 15 crashed it will never come and they will remain stuck forever.

Them sharing the same address means thread 15 was performing a critical task but failed, leaving the others in limbo.

The next block is an exception handling method as evidenced by the existence of CxxFrameHandler4.

After returning from sub_1401CAF60, the function:
1) Executes a nop (likely for alignment or debugging).

2) Clears the eax register (xor eax, eax), meaning it is returning 0. Returning 0 indicates success if they are following the standard coding practices.

3) Restores the stack (add rsp, 58h).

4)Returns (retn). Return is 0.

Since sub_140C560B0 only calls sub_1401CAF60 and returns, it is unlikely that sub_140C560B0 itself caused the exception.
Instead, sub_1401CAF60 is the function that either crashed or explicitly threw an exception.

If sub_1401CAF60 performed an invalid operation (for example dereferencing a null pointer, accessing an invalid memory location, or causing a divide-by-zero error), it could trigger an access violation (0xC0000005).

If sub_1401CAF60 encountered an assertion failure or logic error, it could have explicitly called RaiseException(), causing Thread 15 to crash.

If sub_1401CAF60 was supposed to signal a condition variable before returning, but instead crashed, then:
Thread 15 stopped before waking up waiting threads (Threads 16-19).
This left those threads stuck in SleepConditionVariableSRW().
The result: a deadlock, leading to a system freeze.

Continuing on for the block "this is the code that creates those threads":

The thread stack size is being set (dwStackSize = 0x80000 or 512KB). This means the thread is given a dedicated stack size, but not an unusually large one.

Now this in itself can give us actual details about what sub_1401CAF60 which is called by sub_140C560B0 supposed to do because Explicit Stack Size is often used only on certain things and we know from your previous post that there is a recurring pattern of function calls for DX12 so this is most likely:

Shader compilation. Other possibilities are: Command buffer generation, scene rendering traversal.

For a Vulkan/DX12 worker thread handling deep recursion, large GPU structures, or multi-threaded rendering 512KB is quite low.

Now... I both want this to be true and false at the same time but...

0x80000 is 512KB
0x800000 is 8MB.

8MB is also the suggested stack size for heavy workloads such as... Deep recursion. It is also small enough to be missed.

If this is not it then 512KB is just a red herring. But still it is quite low in my opinion since even the default is 1MB. A well optimized code could be able to run this in a way that Toyota Hilux was running at the end of Top Gear.

Why I'm focused on this:
If the thread overflows its stack and corrupts kernel memory, it can cause a system-wide freeze instead of just crashing the application. Some Windows drivers use the same kernel stack memory region, meaning an out-of-bounds write could cause a hard lockup.

Anyway... Continuing on from "those other threads that don't generate an exception are waiting and here is the code":

This is a System API. And it points out to the following scenario:

1) If Thread 15 is on deep recursion and exhausted its 512 KB stack, it would crash before completing execution.

2) It would crash before calling WakeConditionVariable()

3) Without WakeConditionVariable() no threads are ever woken up, leaving the others stuck.

4) If these threads were rendering threads, the entire graphics pipeline would stall, leading to a system freeze.

Continuing from "this code is called from here ( from sub_140C55D10 )":

This function appears to be preparing and waiting on a condition variable, ensuring that a certain event or resource becomes available before proceeding. The key is that it eventually calls sub_1422D69F4, which in turn calls SleepConditionVariableSRW().

This means that if the expected condition is never met, the thread will wait indefinitely.

rdi is the first function parameter, meaning this function is likely operating on an object (for example a synchronization object, a queue, or a resource handler).

Continuing from "The Array":
I believe this is a thread pool managing GPU work. A GPU task scheduler could assign worker threads to functions in this list. A failure (such as stack overflow in Thread 15) could disrupt the entire system, leaving worker threads waiting.

Continuing from "Then I've searched for that array in the code":

I'm now 99% sure this is the thread pool managing GPU work. The function iterates through a list of work items or jobs (rsi linked structure). It loads a function pointer table (off_1427D3C30), meaning it dynamically selects which function to execute.

There’s exception handling (pExceptionObject), but if a failure is not properly handled, it could leave threads stuck.

We know it is not properly handling.

The final box:

YOU MIGHT HAVE SOLVED IT. OR COME VERY CLOSE TO IT.

Please run 0:015> r.

It would print all register values, including Rip, Rsp, and Rbp, which could confirm if:

If Rip is in RaiseException(), the crash was likely triggered deliberately (assertion failure, runtime abort, etc.).

If Rip is an invalid address, the stack may have overflown, corrupting return addresses.

If Rip points to a function in PathOfExileSteam, the game’s threading code is failing internally.

If Rsp is abnormally low, it strengthens the case that 512 KB was too small, leading to a stack overflow.

TLDR:
There might be a typo at the point where they set the stack sizes.

0x80000 is 512KB
0x800000 is 8MB.

The size is set as 0x80000.

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.

"

KissFC#2626 wrote:

Not GPU related : it is a thread stack that is handling some sort of watchdog for internet connection and responsible for server hop in case it didn't find any availabie instance. Except the thread crap itself with jumbo frame and modern way of handling network. POE1 is plagged with exactly the same code and it's been ages it hasn't been changed.

You can somehow make the code run even worse tinkering with your MTU size and/or playing with your DNS such as using google DNS.

And it is not a deadlock, as if the thread goes non responding, the main loop create another one while the old is zombified in the CPU command queue : it is litteral fork bomb (as it only clear all of its instances if a successful connection happens)

"

snurrfint#5780 wrote:

(...)
This explains why the freeze only happens when loading a new map. It explains why it seems to happen at random times.
(...)

"

monkeyskank#1595 wrote:

"

snurrfint#5780 wrote:

(...)
This explains why the freeze only happens when loading a new map. It explains why it seems to happen at random times.
(...)

First, thank you guys for spending time to look into that.

Now, Freeze may not only happen when loading maps, but mainly.

Outside of loading screen seems to be very rare, but they do seem to occur.
I had it after 0.0.1e, when the monsters got spawned on the map by trialmaster and also this week when my friend ported to me at the beginning of the vanguard dreadnought (when his char got spawned maybe?). I can't be 100% that it is the same bug, but, those were also full freeze, with slow mouse cursor and nothing else responding after something got loaded. Pretty hard to reproduce outside of loading screen though.

Big patch fixed the issue for me, so I was very surprised when it happened, but yeah, outside of loading screen, as far as I know the workaround is not used. Hope this help even a little bit.

"

Phoenixotica#6095 wrote:

"

Braric#4417 wrote:

Someone should start a class action lawsuit to refund the early access purchase price.

They delivered not even half of what they promised in EA and the game is actually unplayable.

Not only will it not work, it's completely non-applicable. This is an early access game. Early access is defined as:

Early access, also known as alpha access, alpha founding, paid alpha, or game preview, is a funding model in the video game industry by which consumers can purchase and play a game in the various pre-release development cycles, such as pre-alpha, alpha, and/or beta, while the developer is able to use those funds to continue further development on the game. Those that pay to participate typically help to debug the game, provide feedback and suggestions, may have access to special materials in the game. The early-access approach is a common way to obtain funding for indie games, and may also be used along with other funding mechanisms, including crowdfunding. Many crowdfunding projects promise to offer access to alpha and/or beta versions of the game as development progresses; however, unlike some of these projects which solicit funds but do not yet have a playable game, all early access games offer an immediately playable version of the unfinished game to players.

So, you didn't "buy" anything. You contributed to the development of a game slated to be free to play later this year, and in exchange for that, you got a work in progress to play and bug test.

I get the frustration of spending money and having issues. I do. But this misconception of "I should get a finished game" needs to end. You bought access to an alpha/beta. If that's too much for some people and uninstalling is what's right for their peace of mind, then aces. But let's stop trying to incite legal this and legal that when there's no leg to stand on when people went in with at least the correct understanding made available to them. If they were in a rush to play and didn't read through what they signed up for, then that's on them, not GGG.

"

Timothy_GGG wrote:

Hello again everyone.

As the patch notes mentioned; there is a temporary fix regarding this for users on Windows 24h2 (26XXX) in the current build of Path of Exile 2 (It will be backported to PoE 1 when that receives a client patch).

For those who haven't had any success related to a full PC freeze/crash when multithreading is enabled please once again send me your dxdiag output and adding --ex-crash-report to your launch options (if you only experience this on DX12). The engine team are working with both NVIDIA and Microsoft to sort any issues that we cannot reliably fix.

Thanks again and please keep this thread civil so support doesn't have to lock this as there is lots of useful information.

"

HeresyGoblin#7286 wrote:

"

Phoenixotica#6095 wrote:

"

Braric#4417 wrote:

Someone should start a class action lawsuit to refund the early access purchase price.

They delivered not even half of what they promised in EA and the game is actually unplayable.

Not only will it not work, it's completely non-applicable. This is an early access game. Early access is defined as:

Early access, also known as alpha access, alpha founding, paid alpha, or game preview, is a funding model in the video game industry by which consumers can purchase and play a game in the various pre-release development cycles, such as pre-alpha, alpha, and/or beta, while the developer is able to use those funds to continue further development on the game. Those that pay to participate typically help to debug the game, provide feedback and suggestions, may have access to special materials in the game. The early-access approach is a common way to obtain funding for indie games, and may also be used along with other funding mechanisms, including crowdfunding. Many crowdfunding projects promise to offer access to alpha and/or beta versions of the game as development progresses; however, unlike some of these projects which solicit funds but do not yet have a playable game, all early access games offer an immediately playable version of the unfinished game to players.

So, you didn't "buy" anything. You contributed to the development of a game slated to be free to play later this year, and in exchange for that, you got a work in progress to play and bug test.

I get the frustration of spending money and having issues. I do. But this misconception of "I should get a finished game" needs to end. You bought access to an alpha/beta. If that's too much for some people and uninstalling is what's right for their peace of mind, then aces. But let's stop trying to incite legal this and legal that when there's no leg to stand on when people went in with at least the correct understanding made available to them. If they were in a rush to play and didn't read through what they signed up for, then that's on them, not GGG.

bad take, thats just outright moronic. If i buy a product in early access i expect bugs and crashes, not for that product to actively HARM my pc by playing it because it CRASHES the SYSTEM not the game, under full cpu load, requiring a hard reset of the pc itself. that's not what i signed up for and i have NEVER in my 2 decades of pc gaming EVER encountered an issue this malicious or dangerous to pc's in a video game. i didn't sign up to test a game early so they could fuck my computer in the process. no other game devs have forced their community to send in useless dxdiags that wont pinpoint the issue any further than what we already know. its not windows, its not nvidia or amd or any other fuckin random company. it's an issue with the code in GGG's engine. and it is actively destroying computers which is outright unacceptable regardless of what state the game is in. game crashes should be confined to THE GAME. not my entire fucking system thats just ridiculous.