Summary
Summary
UE 5.8.3 editor crash: EXCEPTION_ACCESS_VIOLATION writing the image base of UnrealEditor-D3D12RHI.dll in FRHIResource::GetResourceInfo, called from D3D12 SetShaderParametersOnContext (Texture case taken for a UAV entry) during parallel RHI translation on a Background Worker. Seen twice in about 18 hours of 5.8.3 editor uptime; never seen in about 57 hours on 5.8.1 with a near-identical project and config.
Environment
Launcher build of 5.8.3, updated in place from 5.8.1 on 4 Oct 2026. No Windows cumulative update, GPU driver or BIOS change around the update (only routine Defender definition and Store app updates). The project module UnrealEditor-Delusion8.dll was last built on 27 Sep against 5.8.1 (hotfix-compatible BuildId 55116800) and was not rebuilt after the update.
Item
Value
Engine
5.8.3, CL 58210709 (Launcher). Previously 5.8.1, CL 56057345
OS
Windows 11 Pro 25H2 (10.0.26200.9457)
CPU, board
Intel Core Ultra 5 250KF Plus; MSI PRO B860M-E, BIOS 1.B10 (2025-08-06), microcode 0x118
RAM
32 GB (1 × 32 GB DDR5-5600, JEDEC, no XMP)
GPU, driver
NVIDIA GeForce RTX 5070, driver 610.88 (32.0.16.1088, driver date 2026-07-22); the same driver appears in all crash logs back to 2 Sep 2026
RHI
D3D12, SM6; bindless enabled for ray tracing only (log: “Bindless is enabled (Configuration=RayTracing)”); the crashing compute dispatch used classic binding
Rendering
Lumen GI and reflections with hardware ray tracing, Virtual Shadow Maps, ray tracing on; scalability Epic
Overrides
No r.RHICmd.* or r.RDG.* overrides at the time of both crashes (engine defaults: ParallelTranslate on, RDG.ParallelExecute 2)
Modules
No third-party plugins. Non-Epic modules besides OS DLLs: the project game module (no RHI/RDG/render code), the NVIDIA user-mode driver, the NVIDIA capture hook nvspcap64.dll, Microsoft InkObj and VS Setup.Configuration; the same set as in 5.8.1 sessions, none on the crashing stack
Level
One map containing a clinic interior with many shadow-casting local lights and 3 SceneCapture2D mirrors; editor, no PIE
Description
Both crashes have the same signature, down to the module offsets, in two separate editor processes.
Crash
Report folder
Time (UTC+3)
Uptime
Thread
Written address (= D3D12RHI base)
Breadcrumb frame
1
UECC-Windows-60B78A1F4BA2B564A8CA7A8D338A67C8_0000
2026-10-04 20:11
2 h 06 min
Background Worker #4
0x00007FFBA7F50000
67679
2
UECC-Windows-F7E6223849C91394C024A183B0F560FE_0000
2026-10-05 05:22
1 h 02 min
Background Worker #2
0x00007FF98BE30000
67884
• Breadcrumbs “Parallel” (innermost first): FVirtualShadowMapArray::BeginMarkPages / VirtualShadowMapMarkPages / Scene / RenderGraphExecute - /ViewFamilies / SceneRender - ViewFamilies / Frame 67679 | 67884. PCallStackHash 36D9FDE3378E6CBD8B0994045B39CCF3CA53F4A5 in both reports.
• The command being translated is the compute pass “PruneLightGrid(Min=0,Max=0)” (FPruneLightGridCS), Dispatch(46,1,1). MaxLocalLightIndex = 0 means no local lights with VSMs in that view (MinLocalLightIndex is always 0); the camera was most likely outside the clinic (position not recorded).
• Dispatch 46 is consistent with the main level-editor viewport (about 1.6k × 0.86k px → 26 × 14 × 32 light-grid cells / 256); the 1024 × 384 mirror captures would give 12 groups. Viewport size at crash time was not recorded.
• Not OOM (bIsOOM=0). At dump time: process private commit 17.97 / 23.25 GB (session peaks 18.59 / 29.14 GB), system commit 59% / 55%, 7.3 / 10.6 GB RAM free (crash 1 / crash 2).
• No device-removed, GPU-crash, TDR or WHEA events. GPU crash debugging was off (r.GPUCrashDebugging=0), so there is no DRED or Aftermath data; the fault is a CPU-side access violation.
• The two frame numbers are close, but other 5.8.3 sessions passed at least 149,956 frames without crashing.
Call stack (crashing thread)
Symbolized with the 5.8.3 editor symbols (PDB GUID and CheckSum match the binaries in both dumps); identical in both crashes.
00 UnrealEditor_RHI!FRHIResource::GetResourceInfo+0x39 RHI/Private/RHI.cpp:539
01 (inline) UnrealEditor_D3D12RHI!GetD3D12TextureFromRHITexture D3D12RHI/Private/D3D12Texture.h:250
02 (inline) FD3D12CommandContext::RetrieveTexture D3D12RHI/Private/D3D12CommandContext.h:803
03 (inline) FD3D12ResourceBinder::SetTexture D3D12RHI/Private/D3D12Commands.cpp:538
04 UnrealEditor_D3D12RHI!SetShaderParametersOnContext+0xa76 D3D12RHI/Private/D3D12Commands.cpp:704
05 UnrealEditor_D3D12RHI!FD3D12CommandContext::RHISetShaderParameters(FRHIComputeShader*)+0x67 D3D12Commands.cpp:765
06 UnrealEditor_RHI!FRHICommandSetShaderParameters::Execute+0x67 RHICommandListCommandExecutes.inl:120
07 UnrealEditor_RenderCore!FRHICommand<FRHICommandSetShaderParameters,…>::ExecuteAndDestruct+0xf4 RHICommandList.h:1420
08 UnrealEditor_RHI!FRHICommandListBase::Execute+0x148 RHI/Private/RHICommandList.cpp:546
09 UnrealEditor_RHI!FRHICommandListExecutor::FTranslateState::Translate_ExecuteCommandList+0x298 RHICommandList.cpp:1235
0b UnrealEditor_RHI!FRHICommandListExecutor::FTaskPipe::Execute+0x234 RHICommandList.cpp:755
0f UnrealEditor_RHI!TGraphTask<TFunctionGraphTaskImpl<…>>::ExecuteTask+0xb2
10 UnrealEditor_RHI!UE::Tasks::Private::FTaskBase::TryExecuteTask+0x96
17 UnrealEditor_Core!LowLevelTasks::FTask::ExecuteTask+0x77
1a UnrealEditor_Core!LowLevelTasks::FScheduler::WorkerLoop+0x10e
1f UnrealEditor_Core!FRunnableThreadWin::Run+0x68
21 kernel32!BaseThreadInitThunk+0x17
22 ntdll!RtlUserThreadStart+0x2c
Portable form: RHI+0x9d7a9 ← D3D12RHI+0x77706 ← D3D12RHI+0x6b877 ← RHI+0x90c47 ← RenderCore+0x6c184 ← RHI+0x91c18 ← RHI+0xb80c8 ← RHI+0x92934.
Technical analysis
The same FRHIShaderParameterResource entry is read as UnorderedAccessView by the first loop and as Texture by the second loop of SetShaderParametersOnContext; the minidump shows it as UnorderedAccessView again. Everything after that is a mechanical consequence.
- The command’s ResourceParameters are 3 entries: [0] u0 UAV, [1] u1 buffer UAV (per source, the RDG buffer “Shadow.Virtual.NumCulledLightsGrid”), [2] b1 uniform buffer (ForwardLightStruct). The 60-byte ParametersData matches the FPruneLightGridCS::FParameters prefix (MaxLocalLightIndex = 0).
- First loop (D3D12Commands.cpp:684, UAVs only, cmp byte ptr [rdi+0Ah],2) bound entry [1] as a UAV. Evidence: rsi = [UAV1+0xD8]+0x38 = UAV1+0x38, left by lea rsi,[rcx+38h] at D3D12RHI+0x77558; no instruction on the remaining path writes rsi. This assumes [UAV0+0xD8] == UAV0, as on a single GPU; UAV0 itself is not captured in the dump.
- Second loop (lines 699–704) read entry [1].Type as 0. The Texture case (+0x776f3) is reachable only through jump-table slot 0 (table at D3D12RHI+0x77AF0: 776f3 Texture, 77793 SRV, 77a85 UAV, 7782f, 778d2, 77908); there is no direct branch into +0x776f3..+0x77706. Resource (rcx) and Index (rbx = 1) were read correctly in the same iteration.
- In the dump, entry [1] is again {UAV1, Index 1, Type 2}: Type was read as 2 by the first loop, as 0 by the second, and is 2 at dump time.
- The Texture case calls GetTextureBaseRHI() (call [rax+48h]) on an FD3D12UnorderedAccessView_RHI. That vtable has 5 slots, so +0x48 lands in the next vtable (FD3D12Viewport) on the import thunk of FRHIResource::GetResourceInfo.
- GetResourceInfo(FRHIResourceInfo& Out) writes FRHIResourceInfo{} (0x28 bytes, movups [rdx],xmm0) through rdx. rdx still holds D3D12RHI __ImageBase from lea rdx,[__ImageBase] (+0x776e0), which the switch used to address its jump table. The write hits the read-only PE header, so the written address is always exactly the module base.
Registers at the fault (5 Oct dump): rcx = 0x1306843b900 (UAV1), rsi = 0x1306843b938, r15 = 0x1306cfc4ea0 (entry [1]), rbx = 1, rdx = 0x7ff98be30000 (D3D12RHI base). The 4 Oct dump shows the same pattern at the same in-page offsets.
The writer of the Type byte is not visible: the minidump was written seconds after the exception, all workers are parked, and the heap is mostly not captured; a transient CPU misread cannot be fully excluded. At dump time the RenderThread was already in the next scene render (Render → OnRenderBegin → FScene::Update → LaunchVisibilityTasks → WaitOcclusionTests → WaitOnRHIThreadFence). The D3D12 binder does not compare Parameter.Type with Resource->GetType() (UAV1 is RRT_UnorderedAccessView), so the mismatch is not caught.
What Type of Bug are you experiencing?
Editor
Steps to Reproduce
Steps to reproduce
Not reproducible on demand. The crashes came after 2 h 06 min and 1 h 02 min of editor uptime; another 5.8.3 session ran 8.1 h without it.
- Open a map with Lumen (hardware ray tracing), Virtual Shadow Maps and SceneCapture2D components, with the default parallel rendering settings, and work in the level editor (no PIE).
- Crash 1 (4 Oct): the user was deleting StaticMeshActors by hand in the level viewport; the last delete was logged at 17:11:33 UTC and the crash about 8 s later (estimated from the 9 s AudioMixer timeout logged with the crash at 17:11:51 UTC).
- Crash 2 (5 Oct): no user input; the last logged actions were scripted editor-viewport captures (until 02:21:38 UTC) and a Python script job (finished 02:22:12 UTC); the crash was logged at 02:22:51 UTC, exact exception time not recorded.
Frequency: 2 crashes in about 18 hours of 5.8.3 editor uptime with default settings (4 Oct 18:05 to 5 Oct 22:43 UTC+3, at least 0.36 million frames); too few events to estimate a rate. This signature never appeared on 5.8.1: about 57 hours of editor uptime (1–4 Oct, at least 1.6 million frames, a lower bound from log frame counters, including sessions that ended in unrelated asserts), nor in the 33 earlier crash reports since 2 Sep. Config files matched the 5.8.3 sessions for the last ~20 hours on 5.8.1 (at least 0.89 million frames); on 1–2 Oct they differed slightly and VSM was briefly toggled off in one session. With only two events, the version correlation is suggestive, not proof.
Not indicated by the evidence: out-of-memory, GPU crash or TDR, a driver change, project code, or VSM local lights (MaxLocalLightIndex = 0). There are no WHEA events, and both dumps show the identical pass, entry and offsets, which argues against a random hardware fault; a transient CPU misread or a stray write from another module still cannot be fully excluded, because the minidumps contain no heap.
Launcher manifest SHA1 comparison between 5.8.1 and 5.8.3: the VirtualShadowMaps, Shadows, RenderGraph*, RHI module (RHICommandList, RHIShaderParameters, RHI.cpp), MemStack.cpp, ShaderParameterStruct.cpp and Core task-system sources are identical. Changed (file-size delta; contents not inspectable because the 5.8.1 sources are no longer on disk), among others: D3D12Commands.cpp (+287 B, contains SetShaderParametersOnContext), D3D12StateCache.cpp (−1), D3D12RHI.cpp (+1217), D3D12RayTracing.cpp (+1793), D3D12Util.cpp (+76), D3D12Residency.h (+363), D3D12RHIPrivate.h (+54), d3dx12residency.h; Renderer: SceneCaptureRendering.cpp (+502), DeferredShadingRenderer.cpp (+81), SceneVisibility.cpp (−2); Engine: MaterialRenderProxy.cpp (+2121).
Expected Result
Expected and actual result
• Expected: a recorded command’s shader parameter entries stay unchanged while the command list is translated, and the UAV is bound as a UAV.
• Actual: the second loop sees a different Type for the same entry, binds the UAV as a texture, the virtual call overruns the UAV vtable, and the editor crashes writing to the D3D12RHI image base.
Observed Result
Workaround under test and suggestions
Workaround under test, effect on the crash not yet known: r.RDG.ParallelExecute=1 with r.RDG.ParallelDestruction=0 in DefaultEngine.ini [SystemSettings], active since 5 Oct 22:47 (UTC+3), following Epic’s advice for async RDG lifetime issues in other forum threads. It changes RDG task and deletion timing but does not disable parallel RHI translation.
• Editor cost (2 views, 6 × 10 s interleaved captures per setting): 89.7 fps with defaults vs 88.7 fps with the workaround (89.8 if the first capture after switching, 83.6 fps with frame spikes up to ~30 ms, is excluded). Median frame time unchanged (~11.1 ms), render thread ~11 ms, GPU 9.0–9.8 ms. Frames of 16 ms or more: 0 with defaults vs 0.27% with the workaround (up to ~18 ms; 1.3% including the first capture).
• Suggestion: in SetShaderParametersOnContext, read each entry’s Type once, or check it against Resource->GetType(), so a mismatch fails with a clear message instead of a stray write.
• Question: did the lifetime handling of batched shader parameters, or the D3D12 binding and residency code, change between 5.8.1 and 5.8.3? A comparison run on 5.8.1 is no longer possible on our side.
Attachments and related threads
Attached: Epic_Rapor_5.8.3_D3D12RHI.zip with both crash folders, each holding UEMinidump.dmp, CrashContext.runtime-xml, the session log (Delusion8.log) and Breadcrumbs_Parallel_0.txt.
Related reports (similar family, not the same signature):
• Reproducible GPU crash in the parallel depth prepass after ~2 minutes: 5.8.0/5.8.1, access violation under RHISetShaderParameters in parallel translation.
• Crash in UnrealEditor_D3D12RHI!GetD3D12TextureFromRHITexture: same function as frame 01; Epic suggested a memory stomp or use-after-free.
• New random crash in FD3D12GPUFence::Poll since migration to UE 5.7.4: Epic recommends r.RDG.ParallelExecute=1 for async RDG lifetime issues.
• UE 5.7.4: use-after-free of FD3D12SamplerState in BuildSamplerTable: lifetime bug in the same parameter-binding path.
Affects Versions
5.8
Platform(s)
Windows
Additional Notes
Please contact me on prytheskygames@gmail.com if you want a report with minidump, crash context, log and breadcrumbs, so I can send them.