That doesn’t look like the same crash we’re hitting sadly - we’re only rendering a handful of (non-Nanite) skeletal meshes into this scene capture component, so it shouldn’t be hitting this problem, and their description of the way the crash presents is quite different to what we’ve seen.
However we do render Nanite into a different scene capture elsewhere in the game, so it’s probably a good idea for us to integrate this fix anyway. Unfortunately the CLs referenced in that ticket are not visible to us - it looks like they’re on some sort of private development stream for Rune Stubbe (stubbe_ue5_main_edge). I don’t suppose you know if those changes are available in any of the normal streams we have access to?
I’ve attached a .patch of CL46628888 which should be able to apply locally on Windows by opening a Git Bash terminal, navigating to your Engine root and running
patch -p3 -l < UE-5-6-CL46628888-NaniteStreamerCrashFixModified.patchYou may need to modify the -p value depending on what folder you’re in when you run the command. After that you should be able to open P4V and run Actions > Reconcile Offline Work and add the 4 modified files to a changelist.
We’ve still not been able to get any Aftermath crash dumps out of any of these crashes, so any new developments on that front would be a great help!
Unfortunately, I don’t have any updates on this front but have reached out to my colleagues in case they have ideas.
Thanks for the suggestions, but I think we can rule most of these out:
The tester seeing most crashes is on Windows 11 Pro 25H2.
We’re not testing on virtual machines, only physical machines.
We are using DLSS, so it could be involved, but we’ve upgraded DLSS version since we started seeing these crashes. (We had the same thought process as you, and wanted to try and rule it out.) It’s possible that there could be a bug that’s still present in both DLSS 8.1.0 and 8.3.0 of course - but we’ve not seen much pointing towards DLSS as a factor.
We’ve seen the crash when OBS is not running, so I’m fairly confident that’s not involved.
We’ve not had much success finding raytracing issues with d3ddebug until now, but we can try again!
I have been trying to get the aftermath test you described to work today. I confirmed aftermath is initialising correctly in our logs when the crashes happen but it times out and doesn’t write the aftermath dump, we’ve never seen an aftermath dump with a legitimate crash in 5.6 (we have seen them and been able to symbolicate them in previous engine versions). So far I have been able to generate an aftermath dump with GPUDebugCrash hang but my <project>/Saved/ShaderDebugInfo/PCD3D_SM6 directory only contains the hash, usfs and d3dasms, it doesn’t contain dxil unless I run the compile script. Loading the aftermath dump in nsights with the symbol paths set takes a long time to load but ultimately doesn’t manage to symbolicate the dump (ofc as there’s no dxil available). I’m still investigating why the dxil doesn’t generate.
Sorry, we’ve not had a chance to try these latest steps yet, had a busy build deadline! We’re still investigating the crash and will get back to you with this as soon as we can.