Rendering Crash in 5.7 - PreshadowCacheLayout.RemoveElement

Anyone else encounter this? I only see it in packaged build, but it’s persistent!

If it helps, here’s some notes on my project’s settings:

  • No Lumen, no Nanite, no VSMs, no raytracing
  • Baked lighting, using all Stationary lights. Some dynamic lights from gameplay elements.
  • Modified shadow configs:
    • r.Shadow.MinResolution=64
    • r.Shadow.TexelsPerPixel=2

[2026.05.27-17.26.38:641][987]LogWindows: Error: Assertion failed: Scene->PreshadowCacheLayout.RemoveElement( CachedShadow->X, CachedShadow->Y, CachedShadow->ResolutionX + CachedShadow->BorderSize * 2, CachedShadow->ResolutionY + CachedShadow->BorderSize * 2) [File:D:\build++UE5\Sync\Engine\Source\Runtime\Renderer\Private\ShadowSetup.cpp] [Line: 3170]

Hello there @HeliusCarthaxis!

The error you are getting suggests the engine is having a problem when accessing a particular shadow map from your scene. When UE tries to remove this shadow from the cache, and said shadow is nowhere to be found, the whole thing crashes.

This is mostly due the shadow cache being overloaded and running out of space, and it only happens in the packaged build because the editor has more memory available, hidding the issue. And the first thing I would check, is about running r.Shadow.TexelsPerPixel at 16.

That value translates into having every actor in your scene generating shadow maps 16 times larger than usual, which will result in a guaranteed overload. I would test setting it to 4, or even 2. Yet, if the issue persists, try by defaulting it back to 1.

On the other hand, we can increase the engine’s capacity to handle your shadows, by increasing the cache limits. User the following cvars, or add them to your DefaultEngine.ini file:

r.Shadow.MaxCSMResolution=2048
r.Shadow.WholeSceneShadowCacheMb=200

One more thing to check, is how many of your actors need to cast shadows in the first place, as every single object in your level under a stationary light can contribute to the issue. If there are any elements that can work with no shadows, simply select them, go into their details panel, and uncheck “Cast Shadow”

After applying these steps, test by repackaging your build, and see if the crash remains active. Hope this helps, and good luck!

I there! I very much appreciate the help, I want to continue investigating this and will really appreciate your insight into it. It’s driving me nuts!

I edited the post based on some changes I did locally. For clarity, I ended up changing the texels to 2 and updated a bunch of lights across our levels to compensate for the changes (we really liked crisp shadows so i mostly just set the shadow filtering to 1 and reduced the bias/slope bias to 0).

So I think we should have way less of an overload with that. I can definitely look to see what actors don’t need shadows, but these are small levels overall so I don’t think we have too much of an issue there.

I did go into our most common gameplay element that spawns dynamic lights attached to an actor and turned off shadow casting on that.

Unfortunately, still getting the crash! What else can I look at?

In addition, here’s a quick render of the error + the shadow rendering stats just in case…

(Sorry that my above message didn’t reply properly to you, I must have misclicked something!)

This is often provoked by toggling cached preshadows, changing shadow resolution/quality CVars at runtime, or resizing/feature-level transitions. Check whether r.Shadow.CachePreshadows or preshadow-related CVars were being changed near the crash.

I agree, something has changed with cached shadows. The attached screenshot shows that Cached Shadowmaps are empty at the time of the crash, which confirms that UE was trying to clean up a map, failed to do so, then crashed.

Meaning, something in your build is altering shadow parameters. I would suggest checking around your blueprints and actors, looking for anything affecting r.Shadow values on play. And once you do, either disable the ones you can, or move them to DefaultEngine.ini, so they run at startup only.

Fascinating. Thanks for the replies all. I will be taking a deeper look in the near future and will report back. I don’t believe that we’re doing any runtime changes like those, but perhaps there’s something somewhere I’m not accounting for. But, regardless, these are good leads.