Help debugging Pure virtual function error in packaged game

I have been searching on these forums and have found a lot of people who get this same error on packaged games, however none of the “fixes” worked or seem to be the cause for me.

Error:
Pure virtual function being called while application was running (GIsRunning == 1).

Fatal error: [File:D:\build++UE5\Sync\Engine\Source\Runtime\Core\Private\Windows\WindowsPlatformMisc.cpp] [Line: 441] Pure virtual function being called

This only pops up in the packaged game, not in the editor as I was going through and testing everything. I first thought it was in transition from one level map to the next, but a second person got the error in a completely different spot when the player died.

The only plugin I am using is paperZD and it’s fully updated. I am working in 5.3.2.

I thought I had narrowed it down to a specific level, but I cleared the whole level and packaged again and it’s still happening. I am at a complete loss. This is my first game I am making for fun to learn UE5 and this is really disheartening.

Can anyone please give me any tips for debugging this and at least figuring out what is causing the error? I’m happy to attach my crash logs if that helps, but I have gone through the logs and must be missing something because it never points to a specific asset or any info that helps me narrow down what to fix. I feel like I’m missing some vital way to debug or troubleshoot this. Any advice that gets me closer to figuring out what is making this happen would be greatly appreciated!

Hi, I would recommend including the entire stack trace.

The referenced file:line is a just an error handler, you will need to look further down (up?) the stack for clues as to what is happening.

Thank you for the reply. Here is the whole end of the error log (this is where it starts loading map2, which seems to be the most consistent place this happens). The only thing I see is the animation error, but that happens when loading map1, and map1 never has the crash.

Do you think this is something that accumulates? I’ve also checked all “animations” I can think of on everything and didn’t find anything empty or invalid. (I’m using blueprints btw if that’s another clue).

[2024.07.02-00.55.08:370][237]LogNet: Browse: /Game/Maps/map2
[2024.07.02-00.55.08:370][237]LogLoad: LoadMap: /Game/Maps/map2
[2024.07.02-00.55.08:370][237]LogWorld: BeginTearingDown for /Game/Maps/map1
[2024.07.02-00.55.08:372][237]LogWorld: UWorld::CleanupWorld for map1, bSessionEnded=true, bCleanupResources=true
[2024.07.02-00.55.08:372][237]LogSlate: InvalidateAllWidgets triggered. All widgets were invalidated
[2024.07.02-00.55.08:408][237]LogStreaming: Display: 0.041 ms for processing 1089 objects in RemoveUnreachableObjects(Queued=0, Async=0). Removed 121 (198->77) packages and 315 (395->80) public exports.
[2024.07.02-00.55.08:409][237]LogAudio: Display: Audio Device unregistered from world ‘None’.
[2024.07.02-00.55.08:414][237]LogUObjectHash: Compacting FUObjectHashTables data took 0.58ms
[2024.07.02-00.55.08:417][237]LogStreaming: Display: FlushAsyncLoading(51): 1 QueuedPackages, 0 AsyncPackages
[2024.07.02-00.55.08:425][237]LogAudio: Display: Audio Device (ID: 1) registered with world ‘map2’.
[2024.07.02-00.55.08:425][237]LogWorldSubsystemInput: UEnhancedInputDeveloperSettings::bEnableWorldSubsystem is false, the world subsystem will not be created!
[2024.07.02-00.55.08:425][237]LogChaos: FPhysicsSolverBase::AsyncDt:-1.000000
[2024.07.02-00.55.08:426][237]LogAIModule: Creating AISystem for world map2
[2024.07.02-00.55.08:426][237]LogLoad: Game class is ‘GM_Platformer_C’
[2024.07.02-00.55.08:436][237]LogWorld: Bringing World /Game/Maps/map2.map2 up for play (max tick rate 0) at 2024.07.0map17.55.08
[2024.07.02-00.55.08:436][237]LogWorld: Bringing up level for play took: 0.009765
[2024.07.02-00.55.08:567][237]LogTemp: Warning: No animation class defined on ‘Animation’, cannot create instance.
[2024.07.02-00.55.08:568][237]LogLoad: Took 0.197674 seconds to LoadMap(/Game/Maps/map2)
[2024.07.02-00.55.08:571][237]LogSlate: Took 0.000356 seconds to synchronously load lazily loaded font ‘…/…/…/SNF_V2/Content/Fonts/Super-Mario-World.ufont’ (11K)
[2024.07.02-00.55.08:572][237]LogSlate: InvalidateAllWidgets triggered. All widgets were invalidated
[2024.07.02-00.55.08:574][238]LogSlate: Took 0.000288 seconds to synchronously load lazily loaded font ‘…/…/…/Engine/Content/Slate/Fonts/Roboto-Regular.ttf’ (155K)
[2024.07.02-00.55.08:575][238]LogSlate: Took 0.000050 seconds to synchronously load lazily loaded font ‘…/…/…/SNF_V2/Content/Fonts/Super-Mario-World.ufont’ (11K)
[2024.07.02-00.55.08:575][238]LogSlate: Took 0.000394 seconds to synchronously load lazily loaded font ‘…/…/…/Engine/Content/EngineFonts/Faces/RobotoBold.ufont’ (160K)
[2024.07.02-00.55.11:449][239]Message dialog closed, result: Ok, title: Message, text: Pure virtual function being called while application was running (GIsRunning == 1).
[2024.07.02-00.55.11:449][239]LogWindows: Error: appError called: Fatal error: [File:D:\build++UE5\Sync\Engine\Source\Runtime\Core\Private\Windows\WindowsPlatformMisc.cpp] [Line: 441]
Pure virtual function being called

[2024.07.02-00.55.11:449][239]LogWindows: Windows GetLastError: The operation completed successfully. (0)

That doesn’t include the stack trace unfortunately, that would have been written into a separate crash report. These get written in ‘%PROJECT_DIR%/Saved/Crashes’ when it happens in the the editor, not sure where they would go for a shipping build sorry.

Each crash will generate a directory with a name along the lines of ‘crashinfo-YourProject-pid-BIG_HEX_NUMBER’ and within you would find a Diagnostics.txt, which contains the stack trace.

As to the cause, it is almost certainly a memory bug, something has been freed while there are references to it still existent, which then get used leading to a vtable lookup snafu and the resulting (inaccurate/impossible) error message.

Thank you so much for your replies. This is incredibly helpful. As you can tell, I’m new to this and trying to learn.

One problem though, I went into my /Saved/Crashes/UECC-Windows-2961A978417DC6851DD239B1E374C850_0000 folder and don’t see a “Diagnostics.txt” file. The memory issue you explained makes sense in theory, so I was going to dig in here to see if there’s more specifics. Here are the files I have:

CrashContext.runtime-xml ← This doesn’t seem helpful
CrashReportClient.ini ← Also doesn’t seem helpful
MyGame.log ← This is what I pulled the logs I pasted above from
UEMinidump.dmp ← this appears to be all hex

Is there a setting I need to turn on in UE5 to make it generate a Diagnostics.txt file when it crashes? Or maybe do I need to package it with the debug settings rather than shipping?

Thank you for taking the time to help me understand this and point be toward the actual info that’ll help me fix and understand what’s going on!!!

Yeah, I should have thought that through better… there will be no DIsgnostics.txt for a packaged build, the information you need is actually in the dump file, the hex numbers are address offsets to functions, to make sense of them you will need debug symbols.

My ability to help past this point is greatly diminished by the fact that I haven’t used Windows on my own machines for close to a decade, and my day-to-day (where I do still generally use Windows) is web stuff, not C++.

Back in the day, I believe Visual Studio could do this (load the dmp, point it at the pdb, and voilà: readable stack trace). That maybe the case still, I really don’t know. This would also require the pdb file, and I have no idea how you would get that with a Blueprint only project.

This doco page may (or may not) have some useful information:

Hey, you got me more on track to actually figuring this out than any other post or video I’ve been able to find. I appreciate the help! I’m starting to think it’s possible it’s a memory thing too. (because it happens around the same time, but not at the exact same time) for different people who have tested it since. I use “cast to” to manipulate variables a lot (because I was following and learning from tutorials), so maybe cleaning those up will help.

But yeah, thanks for info. I do appreciate it.