Fix STATUS_NDIS_MULTICAST_FULL (0xC0230009) in VMs

When This Hits

You'll see STATUS_NDIS_MULTICAST_FULL (0xC0230009) inside a Windows VM — either a Hyper-V guest or VMware VM. The VM suddenly can't reach certain hosts on the network. Ping fails to some IPs, but others work fine. Or you'll see the error in netsh output or in event log entries from the network adapter.

The trigger is almost always a multicast storm — usually Bonjour/mDNS (192.168.1.255) or IGMP queries from the virtual switch. A VM running Docker, Kubernetes, or even iTunes can flood the adapter. I've also seen it from a misconfigured load balancer sending multicast heartbeats.

Root Cause

The virtual NIC has a hard limit on how many multicast MAC addresses it can hold in its internal filter list. On Hyper-V, that limit is 256 entries per adapter. VMware ESXi typically sets it to 64 or 128. Once the list fills up, new multicast traffic gets dropped — and the OS reports STATUS_NDIS_MULTICAST_FULL. The NIC literally runs out of room to track multicast groups.

Don't bother blaming the physical switch or the host's NIC — the culprit is always the virtual adapter's tiny multicast table.

Fix It — Step by Step

Step 1: Confirm the Error

Open an admin PowerShell on the affected VM and run:

Get-NetAdapter -Name * | Select-Object Name, Status

Then check the multicast list with:

netsh interface ip show joins

If you see STATUS_NDIS_MULTICAST_FULL in Event Viewer under Microsoft-Windows-NetworkProfile/Operational, you've confirmed it.

Step 2: Clear the Multicast List

Stop the VM, then restart it. That's the quick fix — resets the virtual NIC's multicast table. But it'll fill up again unless you fix the source.

Step 3: Find the Flooding Application

Run this in an admin PowerShell to see open UDP sockets listening on multicast addresses:

Get-NetUDPEndpoint | Where-Object {$_.LocalAddress -match '224\.' -or $_.LocalAddress -match '239\.'}

Look for processes tied to mDNS (port 5353), SSDP (port 1900), or IGMP (no port, protocol 2). Kill or disable the offender — usually it's a Docker daemon, a multicast DNS responder, or a media app like Spotify or iTunes.

Step 4: Increase the Multicast Limit (if you can't stop the source)

On Hyper-V, you can't increase the limit per adapter — it's hardcoded in the synthetic NIC driver. But you can move the VM to use a legacy network adapter instead. Right-click the VM > Settings > Add Hardware > Legacy Network Adapter. Remove the synthetic adapter. This uses the old emulated NIC (DEC 21140), which has no multicast limit.

Caveat: Legacy adapters are slower and lose features like SR-IOV and VMQ. Use only if you can't stop the flood.

On VMware, edit the VM's .vmx file and add:

ethernet0.filtering.enable = "FALSE"

This disables the multicast filter entirely — the hypervisor passes all multicast traffic to the VM. Reboot the VM after saving.

Step 5: Filter Multicast at the Virtual Switch

If the flood comes from outside the VM, add a port ACL on the hypervisor. On Hyper-V:

New-VMNetworkAdapterAcl -VMName "YourVM" -Direction Inbound -RemoteIPAddress 224.0.0.0/4 -Action Deny

This blocks all multicast inbound to that VM. On ESXi, you can use a distributed virtual switch's traffic shaping rules to drop multicast.

Still Failing? Check These

• Host firewall — Make sure IGMP snooping isn't blocking legitimate traffic on the physical switch. That can cause retransmit storms.
• Virtual switch version — On Hyper-V, older switches (Windows Server 2012 R2) had a bug that didn't expire multicast entries. Upgrade to Server 2019 or later.
• VM memory — If the VM is memory-constrained, the NDIS driver can behave oddly. Give it at least 2GB.
• Driver version — Update the VM's network adapter driver from the VM tools (integration services on Hyper-V, VMware Tools on ESXi). I've seen this fixed by a fresh VMware Tools install.
• Last resort — Move the VM to a different host and test. If the error disappears, the source is likely the virtual switch on the original host.