UDP messages were received by clients running on other machines. Clients on the same machine (a Windows Server 2008 R2 box running Microsoft Failover Cluster), however, did not receive any message.
For me as a developer, the following analysis was a fun excursion into sysadmin territory, something I only get to do occasionally.
netsh interface ipv4 show joins
you can see which interfaces are joined to which multicast groups. In other words, you can see on which interface the client listens on for incoming multicast messages.
In Windows Server 2008 R2 Microsoft introduced a special adapter called Microsoft Failover Cluster Virtual Adapter (see  and ). This adapter is hidden in the network adapter UI, but it shows up in the output of the
On the machine in question, the client had joined the multicast group using this virtual adapter instead of the physical adapter that was actually receiving the multicast messages.
When joining a multicast group, an application can specify the interface to use in the ip_mreq structure. In fact, Microsoft recommends it.
The network interface with the lowest value for the routing metric for a destination IP address of 126.96.36.199 is the default interface for IPv4 multicast.
However, if the application does know not anything about the interfaces available on the machine, it can instruct the operating system to use the default multicast interface. This default multicast interface is determined by the IP routing table. You can view the routing table by running the command
As it turns out, the virtual adapter was added to the IP routing table with a metric lower than that of the physical adapter; meaning the virtual adapter would be chosen over the physical one.
I compared the routing table on the non-working machine to one from a machine that did receive multicast messages. After I had adjusted the metric for the virtual adapter, clients started receiving multicast messages. No reboot required.