Fixing 0X80340009: NDIS Multicast List Full on Windows

What's Actually Happening Here

Your network interface card (NIC) has a hardware filter table that tracks which multicast MAC addresses it should accept. That table is not infinite—most consumer NICs hold between 256 and 1024 entries. When you hit that limit, the OS throws 0x80340009 (NDIS_MULTICAST_FULL). The NIC literally has no room to add another multicast group.

This error usually pops up when you're running multiple virtual machines (Hyper-V, VMware), doing heavy video streaming over multicast, or using multicast-based service discovery (like mDNS/Bonjour) on a busy network. I've seen it most often on Windows 10 Pro with Hyper-V running 4+ VMs, or on Windows Server 2019 with DHCP scopes configured for multicast forwarding.

Cause 1: Too Many Multicast Subscriptions (The Most Common)

Your NIC is subscribed to more multicast groups than its filter table can handle. This happens naturally when you have many apps that listen on unique multicast addresses—think video surveillance software, financial trading terminals, or multiple VM switches each with their own multicast traffic.

Diagnose It

Open PowerShell as admin and run:

Get-NetAdapter -Name '*' | Get-NetAdapterStatistics | Select-Object Name, MulticastPacketsReceived

If that number is in the hundreds of thousands and climbing fast, it's a symptom, not the cause. To check the actual table size, you'll need a tool like netsh or Wireshark, but the quickest tell is when the error appears. If it happens after adding a new VM or enabling a feature like multicast DNS, that's your clue.

The Fix: Reduce Multicast Subscriptions

1. Disable unnecessary multicast listeners. In Hyper-V, go to each VM's settings > Network Adapter > Advanced Features. Uncheck “Enable DHCP Guard” if you don't need it (it adds multicast filters). For VMware Workstation, edit the VM's .vmx file and add ethernet0.filterAllowedMulticast = "FALSE" to restrict multicast.
2. Turn off LLMNR and mDNS if not needed. These protocols subscribe to 224.0.0.252 and 224.0.0.251. Run services.msc, find “Function Discovery Resource Publication”, set it to Disabled.
3. Restart the network adapter. This clears the filter table temporarily. In Device Manager, right-click your NIC > Disable, then Enable. This buys you time to address the root cause.

The reason step 3 works is that disabling the adapter flushes the entire multicast filter table in the NIC's firmware. But it'll fill up again if you don't reduce subscriptions.

Cause 2: Outdated or Buggy NIC Driver

Some NIC drivers have bugs that hold onto multicast entries even after the subscribing process exits. Realtek and Qualcomm Atheros chipsets are notorious for this. The filter table leaks entries over time, and eventually you get 0x80340009 even under normal load.

The Fix: Update or Roll Back the Driver

1. Open Device Manager, expand Network adapters, right-click your NIC, select Properties.
2. Go to the Driver tab, note the current version.
3. Check the manufacturer's site (Intel, Realtek, Broadcom) for a newer driver. Don't use Windows Update drivers—they're often months old. Download the latest from the chipset vendor.
4. If you recently updated and this error started, click “Roll Back Driver” to revert to a known-good version.
5. After installing, reboot and test.

I've fixed this on Realtek PCIe GbE Family Controller (driver 10.68 from 2022 was leaking entries) by moving to the official Realtek driver 10.74 from their site. The error vanished.

Cause 3: Virtual Switch Overload (Hyper-V / VMware)

Virtual switches create their own multicast filter entries on the physical NIC. Each VM connected to an external virtual switch adds at least one multicast address for its own MAC. If you're running 10+ VMs all on the same external switch, you eat up the filter table fast.

Diagnose It

In PowerShell, run:

Get-VMNetworkAdapter -VMName * | Select-Object VMName, MacAddress, SwitchName

Count how many unique MAC addresses are on the same external switch. If it's over 200 and your NIC has a 256-entry limit (common on Intel PRO/1000), you're at risk.

The Fix: Spread VMs Across Multiple Switches

1. Create a second external virtual switch on a different physical NIC if you have one. Move half your VMs to it.
2. If you only have one NIC, use internal or private switches for VMs that don't need external network access. That removes their multicast entries from the physical NIC.
3. As a last resort, enable MAC address spoofing on the VM settings. This lets the VM use a single shared multicast entry for all traffic, reducing table usage. Go to VM Settings > Network Adapter > Advanced Features > Enable MAC Address Spoofing.

The reason enabling MAC spoofing helps is counterintuitive: when spoofing is on, Hyper-V doesn't add individual multicast filter entries per VM—it puts the physical NIC into promiscuous-like mode for multicast, bypassing the filter table limit. But it's a security trade-off since VMs can then receive all multicast traffic.

Quick-Reference Summary