Excessive crashes and Blueprint corruption when using Live Coding. How to fix that? [Jet Brains Rider]


  • I’m trying to use UE for quick prototyping with a mixed approach of both C++ and Blueprints, so that means creating Actors and Components constantly, moving and changing them around all the time.
  • Making C++ changes and then compiling them with Live Coding or Hot Reload causes constant Blueprint corruption and UE crashes.
  • Even with small changes such as adding new components to an Actor, renaming components or changing properties of UFUNCTIONs.
    • I’m not talking here about extensive components, even a bare bones component/Actor causes this.
  • Both Live Coding and Hot Reload causes the problem in different ways, but the end result is always corruption and/or crashes.

Update - Solved:

UE Versions

  • I was having the issue with Hot Reload in UE4.7
  • Then I migrated the project to UE 5.0.1 and the issues got even worse with Live Coding, plus UE 5.0.1 crashes even more with what I am going to describe.
  • Windows 10, using Rider


Considering a very simple component:

class GAME_API USomeComponent: public USceneComponent

	UPROPERTY(EditAnywhere, BlueprintReadOnly, meta = (AllowPrivateAccess = "true"))
	UArrowComponent* ArrowComponent;


ArrowComponent = CreateDefaultSubobject<UArrowComponent>(TEXT("ArrowComponent"));
ArrowComponent->AttachToComponent(this, FAttachmentTransformRules::KeepRelativeTransform);

That then is attached to a Character:

  SomeComponent = CreateDefaultSubobject<USomeComponent>(TEXT("SomeComponent"));

Then you create a Blueprint that inherits from ASomeCharacer and create some Blueprint code using the ArrowComponent and you also make changes to the ArrowComponent component in the viewport, for example, you move it around.

Updating the code and then breaking everything

Now, add a new UPROPERTY to USomeComponent and also a new UFUNCTION, tiny changes.

  • If I use Live Coding, the Details Panel of both USomeComponent and USomeComponent.ArrowComponent in the Viewport gets blank (blank as in an empty Canvas Panel slate, no properties or fields are displayed anymore) and all the previous references used in Blueprint get errored and I have to create the Blueprint code from scratch.
  • If I use Hot Reload, the Viewport changes of USomeComponent and USomeComponent.ArrowComponent get reset and the Blueprint references also get errored.
  • Then if I delete the references in Blueprint code and then rewrite the Blueprint code, as soon as I try to get a reference to USomeComponent, let’s say by using a default Blueprint Get Some Component, UE crashes.

Corrupting the whole project with a Component rename

Things get even worse if I change the code ArrowComponent = CreateDefaultSubobject<UArrowComponent>(TEXT("ArrowComponent")); to for example ArrowComponent = CreateDefaultSubobject<UArrowComponent>(TEXT("NEW NAME")); (Just a component rename), and then Live Reload (UE5).

Then I can’t even reopen my project anymore because it keeps crashing on restart.

I use Git, of course, but recovering Blueprints from Git make them incompatible with the C++ changes, thus the end result is the same: corrupted work.


  • Is closing UE, re-building the solution and re-opening the Editor for every header change the way to avoid this?
  • Are Live Coding and Hot Reload only suitable for implementation changes?
  • Is there anything I have to tweak to reduce the amount of corruption and crashes?
  • For quick prototyping is it more suitable to use only Blueprints? (not because of the code itself in my case, but because of the Live Coding issues. If I have to close/reopen the Editor all the time, it goes against the idea of “quick prototyping”).

Unreal’s live coding ability only does a poke patch sort of thing it’s not permanent unless you compile from outside editor

once you got said patch where you want it close the editor and build from VS

e.g. goto visual studio and set your project as default

make sure your projects is on DevEditor, win64 then click local debug

it will build all and compile

you are free to then open the Unreal editor from EGL again and your project shouldn’t lose what you did


So basically the solution is always closing the Editor, building the solution and re-opening the Editor every time I make header changes?


Live Coding is more useful for when your editing while playing for fixing bugs you find etc

means you can sweep through your game and find problems and do a quick patch while you play


or for if you need to build a modular component

just don’t turn off the engine unless you have too and if it crashes build from VS

you shouldn’t lose work then


Ok, thanks. That’s really unfortunate, not really suited for prototyping then. Yesterday for example I counted roughly 120 crashes/corruptions/etc. I can write code quite fast, but then my idea of prototyping is to quickly iterate over constant changes - which is impossible then using C++ with UE (due to this workflow of re-opening the editor all the time or dealing with corruption).

In conclusion, the approach then is to first make a base framework with C++, compile it and then make everything with Blueprints, inheriting from the base framework, without touching the base framework again while doing quick iterations.

i mean you can just don’t close the editor till you finished and then recompile everything in the morning or something


But then I need the new features added via C++ to the Components/Actors to extend and use them with Blueprints. And if I live code/hot reload, they get corrupted anyway. So closing and re-opening the editor constantly is a must to keep getting access to the new features I implement with C++ :frowning:

if your in Engine with live coding active you press CTRL, ALT, F11

it pushes the patch from your code

Thanks. I already run/close UE via running the DevEditor preset from the IDE (Jetbrains Rider) and I also use CTRL+ALT+F11 for Live Coding.

The issues I described here happens in this context.

Basically I should stop treating UE’s C++ like a scripting language for quick iterations. Blueprint should be used instead for quick iterations.

In 4.x, you are mostly correct – you should only use Live Coding when making code changes, not structural changes.

I haven’t used it yet, but I believe 5.x supports reinstancing objects while running, so you can do a Live Coding update, and it will absorb structural changes without destroying things quite so handily.


Unfortunately with UE 5.0.1 the situation is much worse. With UE4, I get components being reset and corrupted Blueprints.

With UE 5 I get all of that + crashes, freezes, etc when using Live Coding.

I don’t have a ton of experience with this myself, but from what I’ve noticed it seems that if you change header files or constructors, live coding is going to get messed up, possibly requiring you to do a FULL CLEAN of intermediate files, regenerate project files and a full rebuild, which is annoyingly slow and wasteful of time.

It seems much safer and more time efficient (e.g. not risking intermediate file corruption) to just close the editor, recompile from Rider and relaunch the editor.

Where hot reload does seem to work great is in runtime-only code, like you want to change how some loop or logic works or whatever. It’s great for iterating the details of what any given function does, but not for iterating the structure itself.

If/when the code structure itself changes, hot reload seems to be more trouble than it’s worth.

1 Like

Thank you, makes sense!

I solved it :white_check_mark::

  • I deleted the Jet Brains Rider plugin folders from the Engine/Plugins/Developers folder and re-generated the project using UE (File → Refresh Rider Project).
  • I added the Jet Brains Rider plugin to the project itself, then refreshed it again.
  • Then I removed the plugin folders from the project and added to the engine source again.

And now, everything works smoothly with Live Coding (UE5). I haven’t tested Hot Reload with UE4 anymore, but now I’m able to quick iterate code changes without those crashes and corruption.

Maybe it was a caching issue with Rider?


I use Rider as a game plugin, not as an engine plugin, and mine stays up to date all the time. Every time Rider itself updates, it wants to update its plugin and I allow it to do so.

Live coding still crashes causes asset (blueprint) corruption if you use it “incorrectly.”

Are you saying that with it installed as an engine plugin, you can now make structural C++ changes and those take effect in the editor without corruption?

No, sorry. I should’ve made it more explicit what was really solved:

  • Live Reload is at least twice as fast after my “fix”.
  • I don’t have Editor crashes with Live Coding anymore (as opposed to 120 crashes on the day of the report). I think that’s my biggest win.
  • Blueprints still get corrupted if they are open in the Editor while I refresh the code with CTRL+ALT+F11.
  • Renaming properties in header files still make me close and re-run the editor, but it’s now quite fast (5 seconds or so), and the Editor doesn’t crash anymore.

Thanks for the clarification. Seems like your issue was caused by an out of date plugin, and not really related to where it was installed.

I’m seeing the same results you see using Rider as a Project plugin rather than an Engine plugin.

1 Like