Failed to create pipeline state with combined hash , error 8007000e

Hi,We sometimes encounter the crash issue “Failed to create pipeline state with combined hash, error 8007000e” 。But in fact, the computer with that crashes has sufficient memory and VRAM resources.A portion of users is more likely to encounter this issue.

[2025.11.14-14.22.52:221][ 27]LogD3D12RHI: Error: Failed to create pipeline state with combined hash D5A943DF69A43365, error 8007000e.

[2025.11.14-14.22.52:221][ 27]LogD3D12RHI: Warning: Failed to create graphics PSO with combined hash 0xD5A943DF69A43365:

AlphaToCoverageEnable = 0

IndependentBlendEnable = 1

SampleMask = 0xFFFFFFFF

FillMode = 3

CullMode = 1

FrontCounterClockwise = 1

DepthBias = 0

DepthBiasClamp = 0.000000

SlopeScaledDepthBias = 0.000000

DepthClipEnable = 1

MultisampleEnable = 0

AntialiasedLineEnable = 0

ForcedSampleCount = 0

ConservativeRaster = 0

DepthEnable = 0

DepthWriteMask = 0

DepthFunc = 8

StencilEnable = 0

StencilReadMask = 0xFF

StencilWriteMask = 0xFF

FrontFace = { 1, 1, 1, 8 }

BackFace = { 1, 1, 1, 8 }

InputLayout.NumElements = 0

IBStripCutValue = 0x0

PrimitiveTopologyType = 0x3

NumRenderTargets = 0

DSVFormat = 0x0

SampleDesc = { 0, 0 }

NodeMask = 0x1

Flags = 0x0

I also noticed other similar issues:

[Content removed]

It provides a CL of version 5.6. I have already merged the CL mentioned above into the engine,but the issue has not been resolved.

[Content removed]

It suggests checking both

D3D12.PSO.DriverOptimizedDiskCache and

D3D12.PSO.DiskCacheWe are using D3D12.PSO.DriverOptimizedDiskCache but not D3D12.PSO.DiskCache.But there should still be quite a few games using D3D12.PSO.DriverOptimizedDiskCache. Could this be the cause of the crash?

I would appreciate any assistance you could provide.Looking forward to your reply.

[Attachment Removed]

重现步骤
Unfortunately, we don’t have a stable way to reproduce this.

[Attachment Removed]

Hi,

We are using D3D12.PSO.DriverOptimizedDiskCache but not D3D12.PSO.DiskCache.But there should still be quite a few games using D3D12.PSO.DriverOptimizedDiskCache. Could this be the cause of the crash?

We don’t really maintain this path and some drivers don’t implement pipeline libraries which is why these settings default to off in the engine. We recommend you use the built-in driver cache. It’s unclear if having this setting on is related to the crash.

This does appear similar to the behavior we saw with PSO management outlined here: https://dev.epicgames.com/community/learning/knowledge-base/DBOL/tech-note-fix-for-pso-management-issue-on-nvidia-hardware-in-unreal-engine-5-5

If you have already applied the patch, verify your PSO count isn’t increasing forever until the crash occurs by running stat D3D12RHI in a Development or Debug client and monitoring the number of PSOs.

The recommended settings to avoid this crash are:

  • D3D12.PSOPrecache.KeepLowLevel=false
  • D3D12.PSO.KeepUsedPSOsInLowLevelCache=false
  • r.PSOPrecache.KeepInMemoryUntilUsed=0 (if UE 5.5 or UE 5.6) or 2 (UE 5.7+)

However, even with these settings that may not be enough to prevent the crash if the driver is exhausting it’s own heap. We’re aware of an one such rare case this can happen as mentioned here [Content removed] and an important note from Ondrej copied from that post:

I would add that understanding this was not straightforward, because our PSO count stabilizes after a few minutes of gameplay, so the issue cannot be identified as a continuously rising PSO count. Drivers can continue creating additional shader variants internally long after that point. There is no API that provides visibility into the shader heap, so this behavior cannot be observed using in-engine stats.

It is also important to note that drivers may choose to generate significantly more shader variants for optimization when the game is GPU-bound. Because this happens only in GPU-bound scenarios, changing CVars or ShowFlags can strongly affect the crash rate. For example, r.NumBufferedOcclusionQueries=1 shifts the bottleneck to the CPU for some users, preventing them from hitting the shader heap limit. Similarly, CPU-side optimizations, such as UE 5.5 parallel rendering, can introduce more GPU-bound scenarios and therefore more shader heap limit hits. Likewise, older or slower GPUs are more likely to become GPU-bound, which increases the likelihood of crashes.

[Attachment Removed]

Hello, my colleague who is more familiar with the PSO implementation doesn’t think D3D12.PSO.DriverOptimizedDiskCache=1 would cause the crash, and that if you are able to reproduce the issue on a developer machine with -d3ddebug enabled you may find useful D3D12 debug information in the log.

[Attachment Removed]

Hi,

The D3D12 documentation suggests that error code is only for out of memory situations. It could be that the overall memory is not full, but there are resource heaps or internal driver buffers that are full. I’ve heard a corrupt PSO cache or unsupported GPU features can lead to this error, but have never substantiated those claims in a reliable way. Without a repro it’s difficult to say.

[Attachment Removed]

Hello,

I just wanted to post a reminder that Epic will be on holiday break starting next week (Dec 22, 2025) and ending Jan 5, 2026 and there will be no responses from Epic on public or private tickets, though you may receive replies from the community on public tickets.

We wish you happy holidays!

[Attachment Removed]

Hi,

Thank you for your reply. We will try the recommended configuration you mentioned.

At the same time, I noticed that we did make such a setting:

  • D3D12.PSOPrecache.KeepLowLevel=true
  • D3D12.PSO.KeepUsedPSOsInLowLevelCache=ture
  • r.PSOPrecache.KeepInMemoryUntilUsed=0

The main purpose of doing this is to reduce the PSO stuttering issue on some machines.However, if doing this causes stability issues, we will choose to turn it off.

By the way,I have reviewed all the crash logs again, and after we enabled the above cvar, the frequency of related crash issues did indeed increase.Maybe this is the cause of the problem.

We will set those cvars as you suggested and continue to monitor the related crash issues.

Thank you again for your reply!:grin:

[Attachment Removed]

Hi,

Thank you for your reply again. I got it.:grinning_face_with_smiling_eyes:

The suspicious part of this issue is that there is enough memory and VRAM, yet error code 8007000e is still returned.Besides actual OOM (Out of Memory) situations, what other reasons could cause error code 8007000e to occur?

[Attachment Removed]

Thanks! Wishing you the same.

[Attachment Removed]