[2025.10.13-16.35.07:098][ 0]LogThreadingWindows: Error: Runnable thread Foreground Worker #1 crashed.
[2025.10.13-16.35.07:098][ 0]LogWindows: Error: === Critical error: ===
[2025.10.13-16.35.07:098][ 0]LogWindows: Error:
[2025.10.13-16.35.07:098][ 0]LogWindows: Error: Fatal error!
[2025.10.13-16.35.07:098][ 0]LogWindows: Error:
[2025.10.13-16.35.07:098][ 0]LogWindows: Error: Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0x0000000000000018
[2025.10.13-16.35.07:098][ 0]LogWindows: Error:
[2025.10.13-16.35.07:098][ 0]LogWindows: Error: [Callstack] 0x00007ff78d13461e Project_Name-Win64
Hello everyone. I’m getting this error with my packaged game. After 4-5 minutes of starting, the game gives a fatal error and nothing is written. The crash log only shows the log above. Please help me. I don’t want my two-year project to be wasted.
Unreal Version is: 5.6.1
Thanks everyone.
Nawrot
October 15, 2025, 12:05pm
2
Get installed debug symbols for your game and editor + engine.
When this is done, you need some way to write to log that is working in packaged game.
When you have a way to write log to text text file what actually happened in game. Like GameBeginPlay started, various actors in level started, etc. You can see at what point all is crashing.
Yup finding it in editor is trivial, not so much in packaged game. Hopefully crash report will give you clues, but if not you are about to hunt elephant in africa using bisection.
1 Like
There could be many reasons for this, and that crash-message does not provide much information. Your project is working in PIE and standalone mode? I remember of a similar issue, caused by an asset that had no direct reference and hence was not included in the packaging. So it was not found in the packaged game and caused constant crashing. But, there could be many reasons for this and that was just one.
Hello @kilichamza77 ,
I did end up finding the cause of this crash. It was some really bad code. I think back when I wrote this code, I was trying to write a simple delay without the usual matching callback. After I commented it out, I’ve had zero crashing issues in multiple play tests spanning hours at this point, so I know this is what was causing it.
Whatever you do, please DO NOT copy and use this code. This was very difficult to pinpoint, and I only saw it because I was rewriting some code for the class as a pa…
Hope it helps!
This is packed game. Also I got crash log in debug mode here is:
[2025.10.15-15.13.43:914][852]LogWindows: Could not start crash report client using ../../../Engine/Binaries/Win64/CrashReportClient-Win64-Debug.exe#4 crashed.TSharedPipelineStateCache<FWorkGraphPipelineStateInitializer,FWorkGraphPipelineState * __ptr64>::DiscardAndSwap'::5’::<lambda_1>::operator()() LowLevelTasks::FTask::Init<UE::Tasks::Private::FTaskBase::Init’::2'::<lambda_1> >'::13’::<lambda_1>,0>::CallAndMove() #4
Nawrot:
Get installed debug symbols for your game and editor + engine.
When this is done, you need some way to write to log that is working in packaged game.
When you have a way to write log to text text file what actually happened in game. Like GameBeginPlay started, various actors in level started, etc. You can see at what point all is crashing.
Yup finding it in editor is trivial, not so much in packaged game. Hopefully crash report will give you clues, but if not you are about to hunt elephant in africa using bisection.
Thank you for your answer. But I dont have so much experince on c++. Here is my crash log: [2025.10.15-15.13.43:914][852]LogWindows: Could not start crash report client using ../../../Engine/Binaries/Win64/CrashReportClient-Win64-Debug.exe#4 crashed.TSharedPipelineStateCache<FWorkGraphPipelineStateInitializer,FWorkGraphPipelineState * __ptr64>::DiscardAndSwap'::5’::<lambda_1>::operator()() LowLevelTasks::FTask::Init<UE::Tasks::Private::FTaskBase::Init’::2'::<lambda_1> >'::13’::<lambda_1>,0>::CallAndMove() #4
Nawrot
October 15, 2025, 4:06pm
7
Get login to chat GPT, it can explain what caused crashes. However for your crash it was not great at it.
also:
Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0xffffffffffffffff
That means Unreal tried to read from an invalid GPU memory address (effectively nullptr / -1) while issuing rendering commands.
But chaty gpt gave some nice tips:
Switch build configuration
Run the project in Development Editor instead of DebugGame .
Enable GPU crash debugging
-gpucrashdebugging
This will make Unreal generate a GPU crash dump (in Saved/Crashes), which you can open in Visual Studio or the Unreal Crash Reporter for more detail.Enable D3D12 debug layer DefaultEngine.ini:
[/Script/WindowsTargetPlatform.WindowsTargetSettings]
bEnableD3DDebugLayer=True
Then check the Output Log after running — it’ll tell you exactly what GPU resource was invalid.Update or change graphics drivers
Update to the newest NVIDIA / AMD drivers.
Try running with -vulkan (to test if it’s a D3D12-specific crash).
Check for asset unloading / async tasks
Make sure no background task (like async level streaming or procedural generation) is modifying UObjects or materials directly without using ENQUEUE_RENDER_COMMAND.
Delete and rebuild shaders
Delete DerivedDataCache, Intermediate, and Saved folders.
Let UE rebuild all shaders — corrupted or mismatched ones can cause this.
I will try thanks friend.
nande
October 15, 2025, 10:19pm
9
you usually give great tips but i have some disagreements with this one.
those are generic at best.
that’s not true. maybe a bit slower. it actually has more asserts than development. but it’s not unstable.
Nawrot:
bEnableD3DDebugLayer
doesn’t even exists.
Nawrot:
Update or change graphics driver
the equivalent of “have you tried turning it on and off”. though these can help, sure, but very generic.
if you’re going to reinstall the drivers, make sure to uninstall them using the tool in nvidia site, also use the studio, not the game version.
i don’t think that exists. but you can set your target rhi on the project settings to vulkan, you’d have to disable dx11 and 12, though i’d bet that’s not the issue.
can you share the full logs? that locks some info. how much vram you have?
seems like you have 16G of ram, and only 6G free. with most of your virt memory used.
it might be that you’re running out of ram, hence the nullptr. 16gigs is quite tight to work with ue.
maybe ran out of vram,.
since it’s after 5 minutes, maybe it’s trying to do something and run out of mem.
what gpu do you have?
RAM 16GB
GPU: AMD RX 6700 XT 12 GB
nande
October 15, 2025, 10:30pm
11
that seems solid. 8 is tight, 12 should be good. also disregard my suggestion of nvidia drivers.
maybe is the system’s ram.
do you get a ton of cpu usage? that might be shader compilation.
you can tweak how intense the shader compilation is, though by default is pretty conservative.
CPU usage is at normal levels. I tried the graphics settings at both the lowest and highest levels, but the result was the same: a crash. I also disabled Lumen and Nanite, but the result was the same.
nande
October 15, 2025, 10:40pm
13
does your project uses cpp? or it’s just bps?
you don’t get that error during editor right?
try packaging your game for development and try again. when you do that the config files are stored near the executable. when packaging for shipping it uses system wide configs, so you might be using an old config that its creating issues.
I m using c++ and bp. And no error during editor. I tried debuggame, shipping and development. Still fatal error.
Sorry I dont understand fully here.
nande
October 15, 2025, 10:48pm
15
if you use cpp there’s a slight chance you might introduce the nullptr there.
it also occurs on a bg thread, are you using asynctasks for something? if so, can you share the code?
hmmm. there are ini files, that stores a ton of settings for the game. some of those settings can make your game crash or overload the system. some settings change from version of the engine to engine.
when you run a shipping game it stores the ini files in somewhere like appdata, so you can reistall the app 100 times and it will still use the old ini files.
when you run a development, it stores them in the same folder. so you delete the folder and the config is gone. so next time it starts from fresh.
the top one is development, the bottom is shipping. teh bottom doesnt store the settings there.
settings can have important values
for shipping the config files are stored in another place, system wide.
[2025.10.13-14.57.00:052][751]LogThreadingWindows: Error: Runnable thread Background Worker #1 crashed. [2025.10.13-14.57.00:052][751]LogWindows: Error: === Critical error: === [2025.10.13-14.57.00:052][751]LogWindows: Error: [2025.10.13-14.57.00:052][751]LogWindows: Error: Fatal error! [2025.10.13-14.57.00:052][751]LogWindows: Error: [2025.10.13-14.57.00:052][751]LogWindows: Error: Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0xffffffffffffffff [2025.10.13-14.57.00:052][751]LogWindows: Error: [2025.10.13-14.57.00:052][751]LogWindows: Error: [Callstack] 0x00007ff6c4509bb0 Project_Europe2-Win64-DebugGame.exe!FD3D12ContextCommon::BindDiagnosticBuffer() TSharedPipelineStateCache<FWorkGraphPipelineStateInitializer,FWorkGraphPipelineState * __ptr64>::DiscardAndSwap'::5’::<lambda_1>::operator()() LowLevelTasks::FTask::Init<UE::Tasks::Private::FTaskBase::Init’::2'::<lambda_1> >'::13’::<lambda_1>,0>::CallAndMove() #1 [2025.10.13-14.57.00:084][751]LogExit: Executing StaticShutdownAfterError [2025.10.13-14.57.00:086][751]LogWindows: FPlatformMisc::RequestExit(1, FRunnableThreadWin::GuardedRun.ExceptionHandler) [2025.10.13-14.57.00:086][751]LogWindows: FPlatformMisc::RequestExitWithStatus(1, 3, FRunnableThreadWin::GuardedRun.ExceptionHandler) [2025.10.13-14.57.00:086][751]LogCore: Engine exit requested (reason: Win RequestExit) here is log maybe help you to understand problem.
I made several changes to the DefaultsEngine file. I also tried the default settings, but the problem still didn’t go away. However, in some different DefaultEngine settings, the game crashed within the first few seconds.
nande
October 15, 2025, 10:59pm
18
can you share the whole file please?
that’s missing info. drag the file, don’t copy paste the text please.
ok, which where the settings that affected the crash?
DefaultEngine_Error.ini (6.3 KB)
DefaultEngine.ini (3.9 KB)
DefaultEngine_Error closes in the first seconds. The other one closes after a few minutes.
nande
October 15, 2025, 11:07pm
20
sorry i meant the log file. but the ini helps
