We observed a similar issue and I found setting up specific/custom transport protocols seemed to fix it for us. I set up a UDP and TCP transport interface (omitting shared memory transport) which may suggest that the collision/hang occurs in setting up the shared memory space which I assume is probably enabled by default. So create this DDS profile (`fastdds_profiles.xml`) ```xml <?xml version="1.0" encoding="UTF-8" ?> <profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles"> <transport_descriptors> <transport_descriptor> <transport_id>CustomTcpTransport</transport_id> <type>TCPv4</type> <interfaceWhiteList> <address>127.0.0.1</address> </interfaceWhiteList> </transport_descriptor> <transport_descriptor> <transport_id>CustomUdpTransport</transport_id> <type>UDPv4</type> <interfaceWhiteList> <address>127.0.0.1</address> </interfaceWhiteList> <non_blocking_send>false</non_blocking_send> </transport_descriptor> </transport_descriptors> <participant profile_name="CustomTransportParticipant" is_default_profile="true"> <rtps> <useBuiltinTransports>false</useBuiltinTransports> <userTransports> <transport_id>CustomTcpTransport</transport_id> <transport_id>CustomUdpTransport</transport_id> </userTransports> </rtps> </participant> </profiles> ``` and then make it available before launching nodes ```bat set FASTRTPS_DEFAULT_PROFILES_FILE=fastdds_profiles.xml ``` Note: this profile also limits discoverability to loopback/localhost (127.0.0.1) more network adapters can be added) Background: Even with the hanging nodes I observed that the ports for all nodes were created which may suggest why they can still be observed from a linux machine, but the nodes didn't completely start which would suggest the nodes are likely to still be non-functional.