It probaly is because of a Device Remove event (GPU hang). When the GPU hangs then the DX11/12 runtime invalidates the DX rendering device, and when dgVoodoo tries to allocate some GPU object next time then it returns a NULL object that dgVoodoo want to dereference, and it causes a crash. That's why the crash point is in d3d9.dll.
But you can check it out yourself, just run DebugView/DebugView++ and check out if a "DX11: Remove Device" or a message like that appears when the crash happens. You can also install the Windows SDK and enable the DX11/12 debug layer to get more information about the error. Maybe it's an API driving problem/bug (I don't know Geo-11) that doesn't cause problem with an old 1660 but it does with an RTX4060. (you can test the game with and without Geo-11 to see if the problem is in dgVoodoo)

But it can easily be a driver issue. For example, an RTX 5060Ti always crashes through 32 bit DX12 when the GPU usage is high. I even filed an issue with a simple repro app to NV, they could reproduce the crash but they don't give a * about it.

Because virtually every DX12 application is 64 bit :p

Thank you for your response. I ran DebugView during the crash and there are no "Device Removed" or DXGI_ERROR messages visible before the crash. The log only shows OVR/SteamVR messages and then directly "Game process removed". The crash is completely silent with no D3D debug output.
The only interesting line just before the crash is:
Deleted GP object
I also tested without geo-11 — the crash does NOT occur with just dgVoodoo2 + Clash of Kings mod on RTX 4060. So the problem requires geo-11 to reproduce.
To summarize:

dgVoodoo2 + geo-11 + Clash of Kings mod → crash on RTX 4060 (Ada Lovelace)
dgVoodoo2 + geo-11 + Clash of Kings mod → works fine on GTX 1660 Super (Turing) and GTX 1050 Ti (Pascal)
dgVoodoo2 + Clash of Kings mod (without geo-11) → works fine on RTX 4060
dgVoodoo2 + geo-11 + base game (no mod) → works fine on RTX 4060
Tested with multiple dgVoodoo2 versions and NVIDIA drivers (536.40 to 581.42)

lowenz wrote on 2026-04-20, 20:09:

Because virtually every DX12 application is 64 bit :p

Yes, and I guess they cannot even test the 32 bit driver build thoroughly because of that. But I'd expect that when somebody provides them a simple repro test case then they are happy to investigate it, hoping to find something general bug causing instability problems. But clearly not that is the case.

cicicleta wrote on 2026-04-20, 22:35:

Thank you for your response. I ran DebugView during the crash and there are no "Device Removed" or DXGI_ERROR messages visible b […]
Show full quote

Thank you for your response. I ran DebugView during the crash and there are no "Device Removed" or DXGI_ERROR messages visible before the crash. The log only shows OVR/SteamVR messages and then directly "Game process removed". The crash is completely silent with no D3D debug output.
The only interesting line just before the crash is:
Deleted GP object
I also tested without geo-11 — the crash does NOT occur with just dgVoodoo2 + Clash of Kings mod on RTX 4060. So the problem requires geo-11 to reproduce.
To summarize:

dgVoodoo2 + geo-11 + Clash of Kings mod → crash on RTX 4060 (Ada Lovelace)
dgVoodoo2 + geo-11 + Clash of Kings mod → works fine on GTX 1660 Super (Turing) and GTX 1050 Ti (Pascal)
dgVoodoo2 + Clash of Kings mod (without geo-11) → works fine on RTX 4060
dgVoodoo2 + geo-11 + base game (no mod) → works fine on RTX 4060
Tested with multiple dgVoodoo2 versions and NVIDIA drivers (536.40 to 581.42)

So, it must be something with Geo-11. For instsance, a shader or an API driving bug that does not affect the old card/driver but it has effect on the new one. (I myself encountered such things too with my old and new video cards.)
Or, as Geo-11 stubs DX11, it might return a null object under certain circumstances that causes dgvoodoo to crash. Sg like that.

It'd be cool to run the stuff with the DX11 debug layer enabled to see if it reports problems.

I just ran Official Formula 1 Racing and with Glide enabled many of the textures are corrupt now.

I tried switching back to nGlide but that doesn't even start 😁

Direct3D works okay (some z-fighting in the shadows).

Dege wrote on 2026-04-21, 19:15:

lowenz wrote on 2026-04-20, 20:09:

Because virtually every DX12 application is 64 bit :p

Yes, and I guess they cannot even test the 32 bit driver build thoroughly because of that. But I'd expect that when somebody provides them a simple repro test case then they are happy to investigate it, hoping to find something general bug causing instability problems. But clearly not that is the case.

It's the root of the problem with SpecialK and D3D12-wrapped 32 bit game engines.....64 bit game engines (UT2004 with the newest patch or Styx Master of Shadows 64 bit) has no problem in fact.
32 bit ones keep looping @start and then crash: choosing the D3D11 backend (not D3D12 FL11) is the only way to make them run through SpecialK.

lowenz wrote on 2026-04-25, 16:44:

Dege wrote on 2026-04-21, 19:15:

lowenz wrote on 2026-04-20, 20:09:

Because virtually every DX12 application is 64 bit :p

Yes, and I guess they cannot even test the 32 bit driver build thoroughly because of that. But I'd expect that when somebody provides them a simple repro test case then they are happy to investigate it, hoping to find something general bug causing instability problems. But clearly not that is the case.

It's the root of the problem with SpecialK and D3D12-wrapped 32 bit game engines.....64 bit game engines (UT2004 with the newest patch or Styx Master of Shadows 64 bit) has no problem in fact.
32 bit ones keep looping @start and then crash: choosing the D3D11 backend (not D3D12 FL11) is the only way to make them run through SpecialK.

And what about non-NV gpu's? Like an Intel Arc. 😊
It works beautifully for me with D3D12.

cicicleta wrote on 2026-04-20, 22:35:

Thank you for your response. I ran DebugView during the crash and there are no "Device Removed" or DXGI_ERROR messages visible b […]
Show full quote

Thank you for your response. I ran DebugView during the crash and there are no "Device Removed" or DXGI_ERROR messages visible before the crash. The log only shows OVR/SteamVR messages and then directly "Game process removed". The crash is completely silent with no D3D debug output.
The only interesting line just before the crash is:
Deleted GP object
I also tested without geo-11 — the crash does NOT occur with just dgVoodoo2 + Clash of Kings mod on RTX 4060. So the problem requires geo-11 to reproduce.
To summarize:

dgVoodoo2 + geo-11 + Clash of Kings mod → crash on RTX 4060 (Ada Lovelace)
dgVoodoo2 + geo-11 + Clash of Kings mod → works fine on GTX 1660 Super (Turing) and GTX 1050 Ti (Pascal)
dgVoodoo2 + Clash of Kings mod (without geo-11) → works fine on RTX 4060
dgVoodoo2 + geo-11 + base game (no mod) → works fine on RTX 4060
Tested with multiple dgVoodoo2 versions and NVIDIA drivers (536.40 to 581.42)

Btw, another possible reason came to my mind: could it be that the game with Geo-11 ran out of the 2GB address space? That's another typical case when a crash happens in dgVoodoo dll's.
Just try to make the game executable 4GB-aware.

I think maybe that's the problem. The game without mods works perfect in any graphic card, the problems comes when you add the mod, it has a lot of textures maybe that's the problem with rtx 4060

Dege wrote on 2026-04-25, 17:02:

lowenz wrote on 2026-04-25, 16:44:

Dege wrote on 2026-04-21, 19:15:

Yes, and I guess they cannot even test the 32 bit driver build thoroughly because of that. But I'd expect that when somebody provides them a simple repro test case then they are happy to investigate it, hoping to find something general bug causing instability problems. But clearly not that is the case.

It's the root of the problem with SpecialK and D3D12-wrapped 32 bit game engines.....64 bit game engines (UT2004 with the newest patch or Styx Master of Shadows 64 bit) has no problem in fact.
32 bit ones keep looping @start and then crash: choosing the D3D11 backend (not D3D12 FL11) is the only way to make them run through SpecialK.

And what about non-NV gpu's? Like an Intel Arc. 😊
It works beautifully for me with D3D12.

I'm talking about my ArC B570 (awesome card) system.
The D3D12 wrapper alone works, SpecialK+D3D12 dgvoodoo2 make 32 bit games loop (keep restarting) or crash at start. Tested 64 bit games (UT2004, Styx 1 - 64 bit D3D9->12) run with no problem and so 32 bit games wrapped to D3D11.

lowenz wrote on Yesterday, 11:47:

Dege wrote on 2026-04-25, 17:02:

lowenz wrote on 2026-04-25, 16:44:

It's the root of the problem with SpecialK and D3D12-wrapped 32 bit game engines.....64 bit game engines (UT2004 with the newest patch or Styx Master of Shadows 64 bit) has no problem in fact.
32 bit ones keep looping @start and then crash: choosing the D3D11 backend (not D3D12 FL11) is the only way to make them run through SpecialK.

And what about non-NV gpu's? Like an Intel Arc. 😊
It works beautifully for me with D3D12.

I'm talking about my ArC B570 (awesome card) system.
The D3D12 wrapper alone works, SpecialK+D3D12 dgvoodoo2 make 32 bit games loop (keep restarting) or crash at start. Tested 64 bit games (UT2004, Styx 1 - 64 bit D3D9->12) run with no problem and so 32 bit games wrapped to D3D11.

Then it sounds like a Special-K issue. The devs haven't yet looked into the cause of those crashes?