Thanks for video!

I checked it out and I can even reproduce it with D3D11 and native D3D9, altough I get a crash instead of a freeze.
Sometimes it requires a lot of enter/leave to the shop, other times it happens almost instantly.

It seems to be a game side problem (memory corruption?) because neither the DX debug layer nor the dgVoodoo debug layer report any problems and even less of than half of the 2GB address space is reserved.
It always run into an INT 3 (debugger break) instruction at some point, and that's why it crashes. A debugger screenshot for the native case:

Edit: Patching the executable to 4G aware seems to help after all, I don't know why.

How many times have you tried to start the game by checking one state? I mean that such errors can be latent (floating) for example or 100 attempts to launch 8 can be successful. Which can lead to incorrect conclusions. You need to make at least 100 attempts in such tests.

I checked the 4GB patch didn't help me. I also checked the effect of the number of CPU cores (affinity). This also does not affect the PC freezing. I can't repeat it with d3d11_fl11_0 (I pressed enter for five minutes without stopping).

I didn't see the move to a separate topic.

PC freezes because some tool has extended the TDR timeout into infinity

mitradis wrote on 2025-05-16, 12:41:

How many times have you tried to start the game by checking one state? I mean that such errors can be latent (floating) for example or 100 attempts to launch 8 can be successful. Which can lead to incorrect conclusions. You need to make at least 100 attempts in such tests.

As I said, it either happened "at once" (a few tries) or I had to keep trying for up to ~10 minutes.
Btw, you can try enabling option DirectXExt\D3D12BoundsChecking to see if it's a GPU exception coming from the D3D12 rendering. But that shouldn't cause a constant freeze because TDR should restart the GPU and the game should crash, I think.

Squall Leonhart wrote on 2025-05-18, 18:28:

PC freezes because some tool has extended the TDR timeout into infinity

That'd be weird because TDR is kernel level, so disabling it would mean the (graphical) freeze of the entire operating system.
AFAIK disabling TDR is only recommended for debugging the graphics driver, or running computations on the GPU taking a very long time (but not causing a GPU crash).

Dege wrote on 2025-05-18, 18:58:

Squall Leonhart wrote on 2025-05-18, 18:28:

PC freezes because some tool has extended the TDR timeout into infinity

That'd be weird because TDR is kernel level, so disabling it would mean the (graphical) freeze of the entire operating system.
AFAIK disabling TDR is only recommended for debugging the graphics driver, or running computations on the GPU taking a very long time (but not causing a GPU crash).

Disabling it would result in bsod, where as extending it into a long duration lets the kmd wait into perpetuity on the timeout, for some reason i did this once with my pc and was getting 30+ second waits on TDR's where i'd think the system is completely hung only for it to eventually blink out and recover, probably a remnant of my attempts to mine a bitcoin back when doing it was the in thing.

Squall Leonhart wrote on 2025-05-18, 23:24:

Dege wrote on 2025-05-18, 18:58:

Squall Leonhart wrote on 2025-05-18, 18:28:

PC freezes because some tool has extended the TDR timeout into infinity

That'd be weird because TDR is kernel level, so disabling it would mean the (graphical) freeze of the entire operating system.
AFAIK disabling TDR is only recommended for debugging the graphics driver, or running computations on the GPU taking a very long time (but not causing a GPU crash).

Disabling it would result in bsod

But I guess only because the kernel detects "infinite loop" inside the kmd graphics driver so the triggering reason for the BSOD is not directly the GPU exception(?).
BSOD can be forced though, instead of restarting the GPU+the driver, to get a kernel dump. That's how NVIDIA asks for dumps for reported problems, for example.