Unfortunately, we are still seeing GPU crashes even with our pre-emptive NAN fix 
The crashes are coming from the same shader (TranslucentLightInjectionShaders), and occur in the same place in ShadowGetPhysicalPage with an MMU fault accessing memory
[Attachment Removed]
That’s unfortunate to hear. I think your goal with this issue now should be to try to isolate and replicate the issue.
Were you able to try any of the isolation tests above (regarding having two directional lights, and testing with / without the light blueprints I noted were in your scene) to see if you can find some common factor in your lighting setup that might be causing the crash? Those BP_SE__EmoDungeonBrazier lights seem like they might be blueprints. Is there any logic attached to those that could be modifying your lighting at runtime? Other than the safety changes you made, do you have any other custom engine modifications? It’s possible one of these could be inadvertently causing the issue. Could you try setting up a similar lighting setup in a blank project to see if you can replicate the crash. Maybe try this with your own engine version, as well as the unmodified launcher engine to see if it is caused by anything you have changed in your engine.
You might also want to try adding some extra logging, or if you can attach a debugger and replicate the crash then setting breakpoints in the following code might give you some extra clues as to the cause of the issue. It looks like the VSM physical page memory is allocated in FVirtualShadowMapArrayCacheManager::SetPhysicalPoolSize. If the PhysicalPagePool settings change for some reason, there is some logging here already that should output the following message: “Recreating Shadow.Virtual.PhysicalPagePool due to size or flags change. This will also drop any cached pages.”. This code path would cause your previous VSM physical page to get deleted. So you should check for this message in your logs. FVirtualShadowMapArrayCacheManager::FreePhysicalPool is called to free the physical page memory (and not re-allocate it), and currently doesn’t have any logging. So I would suggest adding some here to see if your VSM memory is getting dropped for some reason. I would only really expect this to get called if you disabled VSMs at runtime for some reason. But its possible some erroneous piece of code is doing this, so it’s probably a good idea to add some logging here to catch this if it is happening.
Regards,
Lance Chaney
[Attachment Removed]
Thanks for the info. I’ll take a look at that BP and look to try and setup a simpler test case that can repro the issue. We’re not aware of any custom engine modifications in this area of the code, but I’ll double check.
We’ve not seen any “Recreating Shadow.Virtual.PhysicalPagePool” messages in the logs for these GPU hangs.
I’ve now added the extra logging to FVirtualShadowMapArrayCacheManager::FreePhysicalPool as recommended.
[Attachment Removed]
I’ve added the logging to FVirtualShadowMapArrayCacheManager::FreePhysicalPool and found that this warning is reported 100-1000s of times in the GPU crash sentry logs.
I’ve tried to repro this in the Editor and found this function is called every frame when an an editor viewport window is active. The callstack shows its coming from FVirtualShadowMapArrayCacheManager::ExtractFrameData with bAllowPersistentData set to false. This causes bDropAll to be true and it to call FreePhysicalPool(GraphBuilder).
[Image Removed]I’ve noticed that VirtualShadowMapPersistentData is set to false in both EnableAdvancedFeatures() and DisableAdvancedFeatures() in ShowFlags.h
There is this comment in the Enable which may be relevant
// Have VSM drop all persistent data each frame
// TODO: Revisit some of the cases that trigger this; if they clean up the scene renderers this is not necessary
SetVirtualShadowMapPersistentData(false);
[Attachment Removed]
This is expected behavior for several viewports in editor (thumbnails, material editor, static mesh editor, etc). These always have virtual shadow map persistent data show flags turned off (these are under the show menu in your main editor viewport, but are unavailable in most other viewports). To clarify, are you getting these logs from a packaged version of the game? or are these logs from the editor version only?
If you’re getting logs showing this is happening in a packaged version of the game, then it’s probably worth attaching a debugger to the packaged version to check what is causing these. FVirtualShadowMapArrayCacheManager::FreePhysicalPool doesn’t trigger for me in a build, at least in a very simple test scene. There are only a couple of code paths that look like they could trigger this, one being if VSMs are somehow disabled (maybe something is toggling VSMs on/off in your project). The other is this drop all from the showflags.
Regards,
Lance Chaney
[Attachment Removed]
Hi Lance,
We are seeing the same GPU crash issue in both packaged Game and Editor builds. The crash occurs more frequently in Editor builds.
We are not seeing the VSM free messages in Game build logs, only from Editor builds.
We are not enabling/disabling VSM shadows at runtime.
Thanks
Jon
[Attachment Removed]
Did you have any luck setting up a simpler test case that can reproduce the issue. If I can get a reproduction on my end that I can report this as a bug and likely get it fixed.
Regards,
Lance Chaney
[Attachment Removed]
Hey Alex - Thanks for reaching out.
We’ve seen the crash with many drivers ranging from Aug 2024 (560.94) up to Sep 2025 (581.57).
We have bindless resources enabled to allow for texture collections, with the index coming from the custom instance data of instanced static mesh components for some materials.
[Attachment Removed]
Thanks Ola.
We’re going to try disabling bindless resources and will report back.
[Attachment Removed]
Hey there, apologies for the delayed reply. We were moving to UE v5.7 and hoping to use the MINIMAL bindless resource mode to avoid using bindless for all resources in the hope this may solve the issue.
Unfortunately this had its own issues. Enabling minimal bindless (rhi.bindless=minimal) caused multiple runtime errors at start-up.
[ASSERT] Assertion failed: IsCompatibleWithBindlessResources(ShaderPair.Data) [File:Z:\Realms_prev\UnrealEngine\Engine\Source\Runtime\D3D12RHI\Private\D3D12Util.cpp] [Line: 1412]
Mismatched dynamic resource usage. <unknown> doesn't support binding with stages that use dynamic resources (F279CB6EF3C7183E2D722C2C7537AD3CA5483189)
In order to see the resource name showing as <unknown> we enabled r.Shaders.ExtraData. However, enabling this also stopping the runtime errors!?! After a bit more digging I found it was this code that prevented the runtime errors:
// temporary change until nsight supports reconstructing reflection data from PDB; don't strip reflection if CFLAG_ExtraShaderData is specified
bStripReflection = !Input.Environment.CompilerFlags.Contains(CFLAG_ExtraShaderData);
We decided that using any bindless (all or minimal) seems risky and we’re reworking some materials to avoid bindless entirely.
We should have this done shortly and can report back.
[Attachment Removed]
Hi,
We’ve encountered the same GPU crash and have gathered some clues from our nv-gpudmps and logs:
1.InjectTranslucencyLightingVolume uses two cascades, and each cascade samples the same shadowmap. However, cascade 0 never causes a crash, while cascade 1 consistently does. From your post, it’s the same.
[Image Removed]2.The crash occurs regardless of the shadowmap type used by cascade 1, including VSM, CSM, and point light (cube shadowmap). Even in a scene with only a point light, cascade 1 can still trigger a GPU crash when sampling ZCubeDepthSM.
[Attachment Removed]
Hello [mention removed]!
I’m also struggling with GPU hang, my issue is very likely identical to the original issue posted in this topic by [mention removed]. Could you share insights on your workaround?
On my side, I’ve introduced following changes:
Those changes only made the crashes less often. There are still crashes happening on some machines.
Best regards
[Attachment Removed]
Hi,
We just set InjectTranslucencyLightingVolume pass NeverParallel flag. Since then it seems never hung again.
You could try whether it works~
Regards.
[Attachment Removed]
Many Thanks - We’ve cherry picked those changes into 5.7 and I’ll let you know if we see any more intermittent GPU crashes 
[Attachment Removed]
Good news - We’ve not seen any of those GPU crashes after taking the recommended fix above.
[Attachment Removed]