In the previous part of this series, we looked at poorly performing virtual switches. In this part, we’ll look at ways to troubleshoot virtual switches that don’t work at all.

Usually, a switch that doesn’t work at all is the result of a configuration error. The number one way to cause switch failure at creation is to use Hyper-V Manager from a remote computer to create a switch on the same physical adapter that the Hyper-V host is using to connect to the network (2008 R2 and prior). This causes a network disconnect that prevents the tool from finishing the creation process, leaving it in a state in which the switch isn’t created but the host can no longer use it is as a regular network connection, either.

The Easy Way

If possible, use Hyper-V Manager to remove the switch and start over. On 2012, try the Remove-VMSwitch cmdlet. Sometimes, it’s just that easy.

The Hard Way

On a GUI system, you’ll find that the physical adapter is bound to an item called the “Hyper-V Extensible Virtual Switch” and that this item cannot be unchecked. The system will allow it to be uninstalled. If you choose this approach, you can re-add it by clicking “Install” and choosing “Protocol”. This will also remove any switches, including any invalid ones.

NVSPBind

On a non-GUI system, repairing the switch will require a little more effort. Fortunately, there are some tools to help out. First among these is NVSPBIND. This tool gives you access to the bindings in a similar fashion to the GUI tool. It’s not an installable tool; the file you download is a self-extracting archive. When you run it, you’ll give it a target folder. Among the three extracted files is “nvspbind.exe”, which is the tool you’re looking for.

If you run just NVSPIND.EXE with no switches, it will dump a list of all adapters and the protocols that are bound to them. We’re not here for a list, though. We’re here to fix an adapter. You can scroll through the entire list looking for the adapter in question, or you can narrow it down to only the ones with the virtual switch bound to it. What you want first is the actual name of the adapter you’re working on. To find it quickly:

A sample output follows:

From the above, “Ethernet” is the name of the adapter we need. Now, we need that adapter’s GUID. Feed it back through NVSPBIND with the /n switch:

The quotes in the above aren’t strictly necessary since it’s only one word, but you’ll need those quotes if your adapter has more. The output has the ID we need:

Our adapter’s ID is {E868A1F0-A435-4421-BB97-AB506F336419}. Just feed it back into NVSPBIND with the /u switch:

If all is well, the virtual switch protocol will be disabled and all others will be enabled. You should now be able to use the adapter as desired.

NVSPSCRUB

If the above did not clear your issue, the next tool available to you is NVSPSCRUB. (February 18, 2015: Microsoft has removed the archive. The link now points to a personal blog for someone that has copied the contents and made it available online). There is an Unblock button on its properties sheet in Windows Explorer, or you can use the Unblock-File PowerShell cmdlet. This utility is much easier to use than NVSPBIND. If you’re trying to fix a broken switch and NVSPIND didn’t help, run:

You can also use it with /V if you want to clean out any virtual adapters that are no longer functional. The difference between this tool and NVSPBIND is that NVSPBIND will return the adapter to the condition it was in prior to the virtual switch being bound to it, which generally means that it will rebind it to TCP/IP and the Microsoft networking services. NVSPSCRUB will leave it unbound from everything.

NETCFG

NETCFG.EXE is a generic tool built-in to Windows. Its purpose is the installation and uninstallation of protocols, services, and clients on adapters. Start with the uninstallation:

Restart the system.

After it reboots, enter the following, depending on the system:

2008 R2 RTM:

2008 R2 SP1:

2012 and Windows 8:

2012 R2 and Windows 8.1

Note: These operating systems have multiple folders with the wvms_pp.inf driver. The text below references the most current version as of December 18th, 2014. When typing this line, press [TAB] after C:Windowswinsxsamd64_wvms_pp.inf and cycle through until you find the folder with the highest version number. Proceed from there.

Restart the system again, and the protocol will have been removed from all adapters.

Follow-Up

All of the above has been intended to reset the system so that you can try to create a functional switch. Make sure you understand how the switch works. If you’re going to create it on the primary adapter for the host, you must use the “Share” option or the host will be unable to communicate. If the host has another primary connection, do not use the “Share” option.