Reproducible DX12 GPU hang / DXGI_ERROR_DEVICE_HUNG – Async Compute stall with repeatable Nsight Aftermath shader PCs

[kylin.music]

Hi,


I have been investigating a highly reproducible GPU hang in Cyberpunk 2077 and have now collected enough information that I believe it may be useful for the REDengine/rendering team rather than continuing with generic troubleshooting.


I am not claiming that this is definitely a Cyberpunk/REDengine bug. The root cause could still be the NVIDIA driver, shader compiler, firmware, hardware-specific behavior, or an interaction between these components.


However, the failure has become extremely reproducible, and I have been able to identify the exact Compute shaders that were active during several independent GPU hangs.

System​

GPU: PNY GeForce RTX 5070 12GB Overclocked Triple Fan
SKU: VCG507012TFXPB1-O
GPU: NVIDIA GB205-A
VBIOS: 98.05.36.00.CB
CPU: AMD Ryzen 7 5700X
RAM: 32 GB DDR4-3200
PSU: 850 W 80 Plus Gold
OS: Windows 11 Pro, build 26200
Game: Cyberpunk 2077 Steam, patch 2.31
Mods: None

The GPU is stable in conventional stress tests.


OCCT GPU load reaches approximately 247 W without errors, and VRAM/system memory testing also completes without errors.


Other DX12 games generally work correctly.

Main failure​

Spoiler: Details

Cyberpunk 2077 repeatedly crashes very early, frequently around the main menu / UI initialization.


The game reports:


DXGI_ERROR_DEVICE_HUNG


0x887A0006


REDengine crash reports consistently show:


GpuCrashed = true


Windows simultaneously records:


LiveKernelEvent 141


corresponding to:


VIDEO_ENGINE_TIMEOUT_DETECTED


and I also see:


nvlddmkm Event 153


around the time of the GPU hang.


DRED consistently reports:


PageFaultVA = 0


so I am not seeing a conventional GPU virtual-address page fault.

Drivers tested​

The failure has reproduced across multiple NVIDIA drivers, including:


591.74


591.86


610.62


610.88


Windows WATCHDOG dumps show BugCheck Parameter 2 inside nvlddmkm.sys.


Relative offsets observed:


591.74 → nvlddmkm + 0x19AED90


591.86 → nvlddmkm + 0x19AFC40


610.62 → nvlddmkm + 0x1957E60


610.88 → nvlddmkm + 0x1959FA0


On 610.88, multiple independent failures repeatedly landed at exactly:


nvlddmkm + 0x1959FA0


I understand that without NVIDIA private symbols this does not prove that the offsets correspond to the same internal function.

Troubleshooting already completed​

I have already tested:


Clean Windows installation


Clean NVIDIA driver installations


Multiple NVIDIA driver branches


Game reinstall and file verification


Fresh Windows user profile


XMP disabled


CPU and GPU at stock settings


GPU undervolt / underclock testing


NVIDIA Debug Mode


PCIe Gen3 instead of Gen4


ReBAR enabled


HAGS disabled


Single-monitor configuration


Dual-monitor configuration


Low graphics preset


Ray tracing enabled and disabled


Different resolutions and refresh rates


TDR registry testing


Background applications and overlays removed


Visual C++ reinstall


Windows repair commands


Direct launch of Cyberpunk2077.exe


Memory and VRAM stress testing


No mods


The crash remains reproducible.

REDengine / ETW trace​

This is where the behavior became more interesting.


Repeated traces show the REDengine breadcrumb:


AsyncComputeDuringShadowmaps: In progress


while subsequent stages remain:


Not started


including stages such as:


Lighting


Skin_Post_and_Forward_Opaque


HologramDepth_and_Distortion


DecoupledParticleLighting


Transparents


PostFX


RenderFinal2D


EndRender


I then see approximately five seconds with no meaningful D3D12 progress.


During this period:


GPU utilization reports approximately 100%


GPU power drops significantly


GPU clocks remain high


GPU temperature remains low, around the mid-40°C range


VRAM usage is only around 3 GB


Then:


nvlddmkm Event 153


followed by:


LiveKernelEvent 141


The recurring sequence is approximately:


AsyncComputeDuringShadowmaps


→ Compute queue stops progressing


→ ~5 second D3D12 progress gap


→ nvlddmkm Event 153


→ GPU engine timeout / 0x141


I am not assuming that AsyncComputeDuringShadowmaps itself is necessarily faulty. It may simply be the workload still active when the lower-level hang occurs.

D3D12 GPU-Based Validation​

I also ran GPU-Based Validation.


It generated errors including:


GPU_BASED_VALIDATION_STRUCTURED_BUFFER_STRIDE_MISMATCH


and:


CLEAR_UNORDERED_VIEW_INVALID_DESCRIPTOR_HANDLE


with activity associated with:


DecoupledParticleLighting


I do not consider these messages proof of the cause of the 0x141 timeout, but I believe they may be relevant to the rendering team.

NVIDIA Nsight Aftermath​

I collected multiple .nv-gpudmp files.


The dumps consistently report:


Device state: Hung


Engine reset occurred: Yes


Adapter reset occurred: No


API: Direct3D 12


GPU: GB205-A


Driver: 610.88


Four independent crashes produced the following active Compute shader PCs.

Crash 1​

Shader hash:


89A74474EB58FD47


GPU PC:


compute_01 @ 0x14E0


Shader size:


5632 bytes

Crash 2​

Shader hash:


4676B8ED54260869


GPU PC:


compute_01 @ 0x0A90


Shader size:


3072 bytes

Crash 3​

Again:


4676B8ED54260869


compute_01 @ 0x0A90

Crash 4​

Again:


4676B8ED54260869


compute_01 @ 0x0A90


A later crash captured through the external NVIDIA Aftermath Monitor also reproduced:


4676B8ED54260869


compute_01 @ 0x0A90


Therefore, the exact same Compute shader and GPU PC have reproduced repeatedly across independent failures.


All of these Aftermath snapshots also reported the unique active PC on:


GPC 2 / TPC 4


I am not interpreting this as proof of a defective physical GPC/TPC, since scheduling behavior could also explain the repeated location.

Shader cache / recompilation test​

To rule out stale or corrupted compiled shaders, I performed a clean recompilation test.


I:


disabled NVIDIA shader cache


rebooted


cleared DXCache


cleared D3DSCache


confirmed both caches contained zero files


enabled NVIDIA Aftermath shader debug generation before launching the game


disabled REDengine's internal Aftermath capture using ForceOff=1


used the external NVIDIA Aftermath Monitor


The external monitor captured the GPU hang successfully.


However, no .nvdbg file was generated.


Most importantly, after completely clearing the caches and forcing recompilation, the crash still reproduced:


4676B8ED54260869


at:


compute_01 @ 0x0A90


This makes a stale/corrupted NVIDIA shader cache unlikely.

Extracting the actual REDengine shader binaries​

Since .nvdbg was unavailable, I investigated the game's shader caches.


I found DXBC containers inside:


shader_final.cache


and:


staticshader_final.cache


The totals were:


shader_final.cache → 19,037 DXBC containers


staticshader_final.cache → 913 DXBC containers


Total:


19,950 shader binaries


I extracted all 19,950 containers without modifying the original game files.


I then added the extracted directory to Nsight Graphics → Shader Binaries.


Nsight successfully resolved the exact binaries corresponding to the shaders seen in the crash dumps.


For:


4676B8ED54260869


Nsight resolved:


static_00440_0x6195C2.dxbc


For:


89A74474EB58FD47


Nsight resolved:


static_00577_0x954EF2.dxbc


Both binaries therefore originate from:


staticshader_final.cache

DXIL analysis – shader 4676B8ED54260869​

I disassembled the shader using Microsoft's official:


dxc.exe -dumpbin


It is:


Compute Shader Model 6.0


NumThreads = (8,8,1)


64 threads per group.


Resources:


cb6


t0 = Texture2D<float>


u0 = RWTexture2D


u1 = RWTexture2D


The shader reads four source texture values per thread and performs what appears to be a tiled min/max or depth-related reduction.


It uses groupshared/TGSM memory and performs a reduction across the thread group.


The reduction contains:


full thread-group synchronization


followed by progressively smaller participating thread sets:


32 → 16 → 8 → 4 → 2


with group-memory barriers between stages.


There is no unbounded/infinite loop in this shader.

DXIL analysis – shader 89A74474EB58FD47​

The second shader is functionally different.


It is also:


Compute Shader Model 6.0


but uses:


NumThreads = (2,2,32)


128 threads per group.


Resources:


cb6


s0 = Sampler


t0 = TextureCube


t1 = StructuredBuffer


u1 = RWTexture2D


It uses a groupshared array containing 384 floats.


The shader processes data from the StructuredBuffer and TextureCube and then performs another shared-memory reduction.


Its reduction pattern is again similar:


full group synchronization


→ shared-memory reduction


→ smaller participating thread subsets


including:


32 → 16 → 8 → 4


with group-memory barriers between stages.


This shader does contain a loop over the StructuredBuffer, but its exit condition is bounded by the buffer element count.

Interesting common pattern​

The two shaders do very different work.


However, both share a very similar execution pattern:


Compute Shader Model 6.0


groupshared / TGSM memory


thread-group synchronization


shared-memory reduction


progressively smaller participating thread subsets


group-memory barriers


final UAV texture writes


This makes me wonder whether the important part is not one particular shader, but a shared REDengine Compute pattern or helper used by multiple shaders.


The repeated 4676B8ED54260869 @ 0xA90 is still the dominant signature, but the earlier 89A74474EB58FD47 @ 0x14E0 appears to exercise a structurally similar shared-memory reduction.


I cannot map the native Aftermath GPU PCs directly to individual DXIL instructions because I do not have the .nvdbg information.


CDPR presumably has access to the shader source and build/debug information, so this is one of the main reasons I am posting here.

What I would like CDPR to check​

If somebody from the REDengine/rendering team sees this, I would particularly like to know:

1. Can shader hash 4676B8ED54260869 be mapped internally to its REDengine shader/pass name?
2. Can shader hash 89A74474EB58FD47 be mapped internally as well?
3. Is 4676B8ED54260869 associated with AsyncComputeDuringShadowmaps or another pass active around that breadcrumb?
4. Is the common groupshared/TGSM reduction + barrier pattern in these two shaders part of a shared REDengine helper or shader implementation?
5. Are the GPU-Based Validation messages involving DecoupledParticleLighting expected, or could they indicate a descriptor/resource-state problem?
6. Has anything similar been observed internally on RTX 50-series / Blackwell GPUs?
7. Would the REDengine/rendering team be interested in the original .nv-gpudmp, WATCHDOG dumps, ETW traces, DXBC binaries, or DXIL disassembly?

Files available​

I can provide:


NVIDIA Nsight Aftermath .nv-gpudmp files


Aftermath JSON exports


Windows WATCHDOG .dmp files


ETW traces


REDengine crash reports


the exact two DXBC shader binaries


DXIL disassemblies of both shaders


GPU-Based Validation logs


complete crash packages


I would be happy to provide the full material if someone from CDPR's rendering team wants to investigate this further.


Thanks.

Post edited to compress the info -- SigilFey

 

[devivre]

It’s better to use the support website for these types of report:

Game crashes — Cyberpunk 2077 | Technical Support — CD PROJEKT RED

Welcome to CD PROJEKT RED Technical Support! Here you will find help regarding our games and services, as well as answers to frequently asked questions.

support.cdprojektred.com

(Click on Contact Us to send a ticket. And since the text is probably to long you could also send them the link to your thread)

However, in case it's a modded playthrough this would make things very difficult to reproduce.

 

[kylin.music]

It’s better to use the support website for these types of report:

Game crashes — Cyberpunk 2077 | Technical Support — CD PROJEKT RED

Welcome to CD PROJEKT RED Technical Support! Here you will find help regarding our games and services, as well as answers to frequently asked questions.

support.cdprojektred.com

(Click on Contact Us to send a ticket. And since the text is probably to long you could also send them the link to your thread)

However, in case it's a modded playthrough this would make things very difficult to reproduce.

Hello devivre.
I've been in contact with support for about a month now, more specifically with Pult. He has been helping me a lot with all the testing.

Just for context, I've never used any mods in my game. I even bought a new NVMe drive because I thought there might be some kind of issue with my old SSD.
But I'll update my support ticket with a link to this post.

I carried out these tests over the weekend and finished them yesterday. I thought I'd post everything here to give the issue more visibility, gather information from other people, and hopefully work together with the team toward finding a solution.

Thank you very much for the suggestion and for your reply.

 

[kylin.music]

Hi everyone,

I'm updating this thread to share the latest (and apparently final) response I received from CDPR Technical Support regarding this issue. After weeks of back-and-forth, providing them with NVIDIA GPU dumps, Nsight Aftermath logs, and pinpointing the exact D3D12 descriptor heap errors, this was their conclusion:

"I'm afraid that you've exhausted the troubleshooting steps that I could have suggested for the described issue. In this case I can only recommend reaching out to an IT Specialist for further PC diagnostics."

To say this is frustrating is an understatement. I have already performed the "IT Specialist" diagnostics. I provided them with hard evidence showing exactly where the engine fails, yet the case is being dismissed as a generic PC issue.

Just to recap for anyone tracking this or any actual REDengine dev who might stumble upon this thread, here is the undeniable data I’ve gathered and already sent to support:

• The Exact Error: The game consistently hangs at the WaitingForUI stage (after Engine/SafeInit finishes). The crash logs always point to DXGI_ERROR_DEVICE_HUNG (0x887A0006).
• The Root Cause in D3D12: My logs captured the exact moment before the device removal: D3D12 ERROR: ID3D12CommandList::ClearUnorderedAccessViewUint: The specified GPU descriptor handle needs to be from the descriptor heap currently set on the command list (Execution Error #1314).
• Not a Hardware Bottleneck/OOM: This happens with VRAM usage sitting comfortably between 1.4GB and 2.5GB. My GPU is a 12GB RTX 5070.
• Exhaustive Testing: This is a 100% reproducible DX12/Async Compute stall. It happens on a completely clean Windows 11 installation, multiple clean NVIDIA driver versions (591.86, 610.62, 610.88), no mods ever installed, and with all CPU/GPU/RAM running at stock settings (no undervolt, no XMP). I even wrote a custom DX12 repro program to isolate the behavior.

I am currently pursuing an RMA with PNY just to be absolutely certain it isn't a marginal hardware defect that only triggers under this specific Async Compute workload. However, given the extreme specificity of the D3D12 descriptor heap error, this strongly points to an engine-level bug interacting poorly with the RTX 50 series architecture or driver.

Are there any other RTX 50 series users experiencing this exact 0x887A0006 crash during startup? If a dev sees this, I still have all the .nv-gpudmp, KYLIN.log, and Aftermath files ready to be analyzed.

 

[SigilFey]

To say this is frustrating is an understatement. I have already performed the "IT Specialist" diagnostics. I provided them with hard evidence showing exactly where the engine fails, yet the case is being dismissed as a generic PC issue.

Correct! And yet the problem still exists. When in a situation like this, it may require a technician with very specific skills to sort out what's actually happening.

The Exact Error: The game consistently hangs at the WaitingForUI stage (after Engine/SafeInit finishes). The crash logs always point to DXGI_ERROR_DEVICE_HUNG (0x887A0006).

This is the most useful bit, if it keeps appearing with exactly that error. We now know that the Nvidia driver failed to finish a Windows command, or took too long to respond, and Windows crashed the game to avoid a critical fault. However, it's important to remember that this may be the symptom, not the cause.

no undervolt, no XMP

Absolutely no under/over voltage, and no under/over clocking. XMP, however, I would enable to whatever the default in the BIOS is. Are all of your RAM chips exactly identical (brand, JEDEC vs. max frequency?)

Also, be sure to disable any CPU "Boost" or "Overdrive" technology. It's called something different from this to that mobo brand.

I am currently pursuing an RMA with PNY just to be absolutely certain it isn't a marginal hardware defect that only triggers under this specific Async Compute workload. However, given the extreme specificity of the D3D12 descriptor heap error, this strongly points to an engine-level bug interacting poorly with the RTX 50 series architecture or driver.

I would do the same. Not sure a full RMA is needed, but contacting the PC manufacturer directly would probably be the best route. The caveat here is that just because it only happens with one game, that can mean that only that game puts the PC in exactly the environment it needs to manifest the hardware/firmware/driver issue. CP2077 is an extremely demanding game!

It's also important to note that a game "bug" exists in the code, which means that if it exists, every single player on that platform will see exactly the same thing. In this case, I think it's far more likely to be a driver/OS/hardware issue...but an extremely particular one.

A good test is to see if you can get it to happen with some other game that demands continuous, heavy load. Something like Call of Duty or Fortnite are extremely light, by comparison. ArmA 3 in a big mission running at 2K or 4K, or DCS World with 10+ people in the server would be better bets. A recent Total War game with 4v4 or 6v6 could do the trick. Space Engineers on a public server with around 5-10 players and TONS of stuff already built. You get the idea.


_______________


Above all: patience! You've put a lot of effort into this. The problem will eventually be found!

 

[kylin.music]

Correct! And yet the problem still exists. When in a situation like this, it may require a technician with very specific skills to sort out what's actually happening.


This is the most useful bit, if it keeps appearing with exactly that error. We now know that the Nvidia driver failed to finish a Windows command, or took too long to respond, and Windows crashed the game to avoid a critical fault. However, it's important to remember that this may be the symptom, not the cause.


Absolutely no under/over voltage, and no under/over clocking. XMP, however, I would enable to whatever the default in the BIOS is. Are all of your RAM chips exactly identical (brand, JEDEC vs. max frequency?)

Also, be sure to disable any CPU "Boost" or "Overdrive" technology. It's called something different from this to that mobo brand.


I would do the same. Not sure a full RMA is needed, but contacting the PC manufacturer directly would probably be the best route. The caveat here is that just because it only happens with one game, that can mean that only that game puts the PC in exactly the environment it needs to manifest the hardware/firmware/driver issue. CP2077 is an extremely demanding game!

It's also important to note that a game "bug" exists in the code, which means that if it exists, every single player on that platform will see exactly the same thing. In this case, I think it's far more likely to be a driver/OS/hardware issue...but an extremely particular one.

A good test is to see if you can get it to happen with some other game that demands continuous, heavy load. Something like Call of Duty or Fortnite are extremely light, by comparison. ArmA 3 in a big mission running at 2K or 4K, or DCS World with 10+ people in the server would be better bets. A recent Total War game with 4v4 or 6v6 could do the trick. Space Engineers on a public server with around 5-10 players and TONS of stuff already built. You get the idea.


_______________


Above all: patience! You've put a lot of effort into this. The problem will eventually be found!

Hi SigilFey, thank you for taking the time to reply and for the encouragement!

Just to clarify a few of the hardware points you mentioned, as I’ve actually already covered them during my troubleshooting:

Regarding the RAM and XMP: The RAM sticks are an identical matched kit. I originally ran them with XMP enabled (BIOS default profile), but turning XMP off was one of the diagnostic steps I took to rule out memory instability. The crash happens regardless of XMP being on or off. I also ran OCCT Memory tests for 30 minutes with zero errors.

Regarding CPU Boost: I am running a Ryzen 7 5700X. I tested it completely stock, making sure any Precision Boost Overdrive (PBO) or auto-OC features were disabled in the ASUS BIOS. The crash still happens.

You make a very fair point about a strict code bug theoretically affecting every single player. However, my suspicion is an edge-case interaction between REDengine's Async Compute implementation, DX12, and this specific RTX 50 series silicon or driver. The most glaring evidence is the D3D12 Execution Error #1314 (CLEAR_UNORDERED_ACCESS_VIEW_INVALID_DESCRIPTOR_HANDLE) that triggers right before the device hang. This indicates an invalid command is being processed, rather than just a brute-force hardware timeout.

As for other heavy loads, the GPU breezes through OCCT GPU stress tests drawing around 247W and stabilizing at 74°C without throwing a single error. Other demanding DX12 games also run perfectly fine. Cyberpunk 2077 is the only application failing, and always at that exact WaitingForUI startup stage.

You're right that CP2077 is incredibly demanding and might just be exposing a marginal hardware flaw that synthetic tests miss. That's exactly why I'm pushing PNY for the RMA. If they give me a replacement and the new card works, we'll know it was the silicon. If it still crashes... well, the mystery deepens!

Thanks again for the input. I'll update this thread once PNY actually moves forward with the RMA.

 

[SigilFey]

You make a very fair point about a strict code bug theoretically affecting every single player. However, my suspicion is an edge-case interaction between REDengine's Async Compute implementation, DX12, and this specific RTX 50 series silicon or driver. The most glaring evidence is the D3D12 Execution Error #1314 (CLEAR_UNORDERED_ACCESS_VIEW_INVALID_DESCRIPTOR_HANDLE) that triggers right before the device hang. This indicates an invalid command is being processed, rather than just a brute-force hardware timeout.

Yes, this I think is the right idea. It will most likely wind up being a combo of hardware/game/API/driver/firmware/OS not getting along somehow.

You're right that CP2077 is incredibly demanding and might just be exposing a marginal hardware flaw that synthetic tests miss. That's exactly why I'm pushing PNY for the RMA. If they give me a replacement and the new card works, we'll know it was the silicon. If it still crashes... well, the mystery deepens!

True dat. Let us know how it goes, or if anything changes with a driver update.