bbt636 I understand your situation. Unfortunately, the steps to reproduce the issue are currently unclear, making it difficult to investigate further without a reproduction project. Could you prepare a minimal Unreal Engine project where the problem can be reliably reproduced and email it to us?: contact@esotericsoftware.com
Please include the URL of this forum thread in the email so we know the context. Then we can take a look at what's wrong.

I went through the log, and while it does mention the incorrectly initializede FSpineEvent structs, it doesn't give me a stack trace for the crash which would allow me to understand what is happening.

Is there any way you could share your project either here or privately via email (contact@esotericsoftware.com) with steps to reproduce the issue?

bbt636 Thank you for sending the video and project files! We were able to reproduce the crash and will investigate the cause of the problem. As soon as we find out anything, we will let you know in this thread.

This is extremely hard to figure out I'm afraid. I've been banging my head against it for a few days, without much progress. UE's garbage collector is ... peculiar.

I've pushed a supposed fix, please give it a try.

The issue: spine-ue exposes TrackEntry instances. These are wrapped inside a USpineTrackEntry, so users of blueprints can easily access and modify them, e.g. set mix durations etc. These are UObjects and thus eligible for UE garbage collection. Normally, the garbage collection happens after the underlying TrackEntry is disposed. Disposal of a TrackEntry triggers a callback in the USpineWidget or USpineSkeletonAnimatinComponent, which will then set the USpineTrackEntry::entry field to nullptr. However, sometimes, under specific circumstances, that callback has no chance to be executed before the USpineTrackEntry::BeginDestroy() method, which is triggered by the UE garbage collector, is invoked. This can lead to a situation, where the USpineTrackEntry::entry points to a freed memory region, while USpineTrackEntry::BeginDestroy() is trying to access the ::entry field. That results in a crash.

The solution: do not access ::entry in the BeginDestroy() method. While this sounds trivial, I had to trace through everything to make sure this doesn't mess with other state, which is part of why resolving this took so long.