We experienced Out of Memory crashes on several of our users’ machines a couple days ago within our network, all around the same time. This only happened to users on 5.7.2 (we also support the use of 5.4, but this wasn’t present in users using that engine). What we noticed in each of their crash logs was variations of this UDP message spammed millions of times, causing the crash logs to be several GB in size in each case. The IPs in each case were varied, but the spam were variations of this message:
[2026.02.09-20.52.15:111][717]LogUdpMessaging: Warning: FUdpMessageProcessor::UpdateReassemblers Discarding 1/2 of stale message segments from Sender=10.5.74.125:59593, Sequence=0
What kinds of services cause LogUdpMessaging like this? Each user was working in a localized animation project connected to Perforce, and not using Multiuser, Pixel Streaming or VCAM as far as we know. Any kind of leads would be greatly appreciated, as we’ve never seen this before. It seems like it only happened a couple times within the same day, and we haven’t seen it again. We’ve also upgraded to 5.7.3 now as well.
Attached below is one example of a crash log - we had several these appear across all of our 5.7.2 users on the same day.
[Attachment Removed]
UDP Messaging is used by a few tools but typically it does not need to communicate outside of the localhost. The default settings (0.0.0.0:0) allow it to join multicast groups that are on the subnet which is why all of your connected UE sessions are “talking” to each other. You can go into the project settings for UDP Messaging and change the default unicast address to be 127.0.0.1:0 and that will force all communication to the loopback device and it will not be allowed to communicate with other editors / clients on the network. That should resolve the spamming that you are seeing.
[Attachment Removed]
Thanks Jason - we’ll give that a shot.
I’d like to add we’re seeing the same series of crashes today to our 5.7 users. Do you know what could possibly inflict this log spam across everyone’s machines like this? We haven’t seen it happen since I reported this a couple weeks ago, the behavior seems very random.
Hoping that adjusting the default unicast address will prevent it again in the future.
[Attachment Removed]
Additionally, can we confirm it’s this setting here?
[Attachment Removed]
Yes that is the correct setting. By default it is setup to listen on the IF_ANY address which will allow Unreal to communicate with any Unreal Editor on the same subnet. If you have a large number of computers on the subnet all connected to UE then I can see this default setting being a problem.
[Attachment Removed]
Hey there - we switched the unicast address to 127.0.0.1:0, but unfortunately the same crash occured again today to our 5.7 users. The crash log looks the same as the log I uploaded above, with the same warning spammed millions of times. Tt seems like the projects are still speaking to each other.
Any ideas on what would still be causing this?
[Attachment Removed]
Hi Joshua,
It should have prevented it from joining the multicast group on any interfaces that would respond to messages from external machines. In the new logs can you check for the following lines:
[2026.02.09-20.58.07:074][ 0]LogUdpMessaging: Initializing bridge on interface 0.0.0.0:0 to multicast group 230.0.0.1:6666.
[2026.02.09-20.58.07:074][ 0]LogUdpMessaging: Display: Unicast socket bound to '0.0.0.0:56209'.
[2026.02.09-20.58.07:078][ 0]LogUdpMessaging: Display: Added local interface '10.5.74.70' to multicast group '230.0.0.1:6666'
[2026.02.09-20.58.07:078][ 0]LogUdpMessaging: Display: Added local interface '127.0.0.1' to multicast group '230.0.0.1:6666'
It should say Unicast socket bound to `127.0.0.1:portno`. If it is not bound to the local loopback then it will still commnincate with other nodes on the network. You can also force it via command line using
-UDPMESSAGING_TRANSPORT_UNICAST=127.0.0.1:0
[Attachment Removed]
Hello Jason,
Thank you for the suggestion.
Could you let me know how do you use that command line?
I tried this in the Cmd,
-UDPMESSAGING_TRANSPORT_UNICAST=127.0.0.1:0but it seemed not to do anything, for it gave me nothing when I then ran this to see if it returned the address -UDPMESSAGING_TRANSPORT_UNICAST.
I also tried this in Cmd(no ‘-’),
UDPMESSAGING_TRANSPORT_UNICAST=127.0.0.1:0but it printed this
Usage: UDPMESSAGING <Command>
Command
RESTART = Restarts the message bridge and message tunnel, if enabled
SHUTDOWN = Shut down the message bridge and message tunnel, if running
STATUS = Displays the status of the UDP message transport
Thanks!
[Attachment Removed]
Also, we made this change in the project settings, but the crash isn’t gone:
[Image Removed]
Then I added a temp cvar to make these functions do nothing. Do you think it’s enough to block any packages sending/receiving via UDP protocol? If not, could you point me a way to completely block it? Thanks!
[Image Removed]
[Attachment Removed]
That will block any message processing from happening so as a test you could enable that workaround. I would like to understand if we are seeing the same issue that has been fixed in ue5-main or if this is something new. Can you send an updated log with the latest crash?
[Attachment Removed]
Thanks Jason.
This is one of the crash logs of yesterday. Please let us know if you need anything else.
[Attachment Removed]
Hey Jason!
Out of curiosity how could we tell what the source of the UDP messaging is? We were testing recently and continued to see discarded udp resonses after disabling pixel_streaming and virtual_camera. You had mentioned several tools which leverage UDP and it would be nice to know what does so we don’t inadvertently kneecap one of our workflows.
Thanks,
[Attachment Removed]
Hi,
The latest logs indicate that it is still using 0.0.0.0:0 which is the IF_ANY address and means that the messaging will join the multicast group on all adapters which explains why it it is trying to respond to a 10.1.74.x addresses. You can see that on Line 1116 in the log file you provided. You have to make sure the settings are saved out to your engine config for the project. On startup you can override the project settings when you launch UE. For example,
D:\ue5main\Engine\Binaries\Win64\UnrealEditor.exe D:\ue5main\MyProject\MyProject.uproject MyLevel -UDPMESSAGING_TRANSPORT_UNICAST=127.0.0.1:0There are a bunch of tools that use messaging. A few from the VP side -> Multi-user, Live Link, and Time Data Monitor. VCam does not use this data channel and relies on the Pixel Streaming Data channel. There are also other plugins that may use Message Bus framework to communicate and since UdpMessaging provides a transport for Message Bus there could be others, e.g. Chaos Visual Debugger we found was incorrectly handling network ping responses and broadcasting much wider than necessary.
[Attachment Removed]
Thank you Jason, I will double check it.
I wonder is there a cvar for that?
[Attachment Removed]
There is no cvar but you could add one. See UdpMessagingModule.cpp -> ParseCommandLine() and InitializeBridge() functions.
[Attachment Removed]
Thanks Jason.
I just made the change to set UnicastEndpoint to 127.0.0.1:0 by default in InitializeBridge(). And now it prints this in the log
LogUdpMessaging: Initializing bridge on interface 127.0.0.1:0 to multicast group 230.0.0.1:6666.
I will release the change to our artists and will keep you posted.
[Attachment Removed]
Hi Jason,
It has been stable since my latest change for over a week. I would say the crash is gone on our side.
Thank you for the support, and we will let you know if we run into any related issues.
[Attachment Removed]