TekOnline

When Windows Network Diagnostics Removed a Hyper-V Switch Fabric

Automated network repair tools are useful on a normal desktop. On a Hyper-V host that runs the router for the site, they can be a lot more dangerous.

On June 16, 2026, a TekOnline Hyper-V host lost almost all of its virtual networking after a Windows network diagnostics session. The pfSense VM was restored from Veeam, but the outage stayed exactly the same.

That was the clue that mattered: the VM was not the broken part.

The missing layer was the Hyper-V switch fabric on the host.

The Environment

The host was not a simple single-NIC lab box. It was carrying a virtual router and several internal networks:

  • Windows Hyper-V host.
  • pfSense VM acting as the main router/firewall.
  • Multiple physical NICs mapped to Hyper-V external switches.
  • Several Hyper-V internal switches for isolated VM networks.
  • Home Assistant and Ubuntu Server VMs behind pfSense-managed networks.
  • A USB 4G dongle path used for failover testing.

The pfSense VM had clearly named virtual adapters:

WAN
Upstairs
Downstairs
Redundant
Security
J-Server
Ubuntu
4G-Dongle

That naming decision paid for itself during recovery. When the switches disappeared, the VM adapter names still described the intended topology.

The Symptom

Hyper-V Manager showed blank or missing switch assignments. The pfSense VM still had its virtual NICs, but those NICs were no longer connected to their matching virtual switches.

A quick PowerShell check showed the scale of the damage:

Get-VMSwitch

Only one switch remained:

Name : nat
Type : Internal

Everything else was gone.

That explained why restoring pfSense did not help. The pfSense VM configuration was only one side of the path. The Hyper-V switches it connected to were host-level objects, and those objects were missing.

The Timeline

The Windows event logs told the story.

At 12:21:25 PM, Windows started the built-in diagnostics package:

C:\windows\diagnostics\system\networking

At 12:21:26 PM, Windows logged that the Network Diagnostics Framework started because the user requested a diagnostics session. The originating application was Firefox.

At 12:21:27 PM, the diagnostic engine ran a resolution.

Then the host networking changed:

  • Hyper-V Virtual Machine Management stopped.
  • Host Network Service stopped.
  • External Hyper-V switch NIC bindings were removed.
  • Physical NICs behind WAN, Upstairs, Downstairs, Security, and 4g dongle were no longer bound to their expected virtual switches.
  • sdiagnhost.exe initiated a restart as J-SERVER\Administrator.

After the reboot, Windows was alive, but the Hyper-V switch objects were not.

The failure looked like a pfSense problem because pfSense sat in the middle of every important network path. It was really a host network reset problem.

Is This A Known Hyper-V Failure Mode?

There is a known class of Hyper-V problems around Windows network reset, virtual switch bindings, and adapter reconfiguration.

Microsoft documents Hyper-V virtual switch creation failures where the physical adapter still has the vms_pp binding, which is the Microsoft Virtual Network Switch Protocol. Their workaround is to inspect and modify adapter bindings with PowerShell, including:

Get-NetAdapterBinding-ComponentID"vms_pp"Disable-NetAdapterBinding-Name"<Adapter Name>"-ComponentID"vms_pp"

Microsoft Q&A threads also describe Windows “Network Reset” leaving Hyper-V virtual adapters or switches in a broken state, and note the broader rule that network software, VPN clients, and virtual switches may need to be reconfigured after a reset.

What we did not find is an official Microsoft article that says, in plain terms, “Network Diagnostics will delete all Hyper-V VM switch mappings.” So the precise behavior in this incident should be treated as observed evidence from this host, not a universal guarantee.

The practical conclusion is still clear enough: on a Hyper-V host, automated network repair can disturb the same bindings Hyper-V depends on. If that host runs a virtual router, the blast radius is much larger than a normal workstation network reset.

Why The Veeam Restore Did Not Fix It

Veeam had usable restore points for pfSense, Home Assistant, Ubuntu Server, and the host. Restoring pfSense worked as a VM restore, but it could not recreate the missing Hyper-V switches.

That is because the switch fabric lives outside the guest VM:

Physical NIC
    -> Hyper-V external switch
    -> VM network adapter
    -> pfSense interface

Restoring the guest can recover the last two layers. It does not automatically rebuild the first two.

A full host restore may have worked, but it was the heavier option. The faster recovery path was to reconstruct the switch topology from logs and inventory.

Reconstructing The Switch Map

The old Hyper-V switch data still contained the switch names and physical NIC bindings.

External switches:

WAN        -> Ethernet 17 / Intel(R) Ethernet Connection (14) I219-LM
Upstairs   -> Ethernet 8  / Intel(R) 82580 Gigabit Network Connection
Downstairs -> Ethernet 9  / Intel(R) 82580 Gigabit Network Connection #2
Security   -> Ethernet 10 / Intel(R) 82580 Gigabit Network Connection #3
4g dongle  -> Ethernet    / Remote NDIS based Internet Sharing Device #6

Internal switches:

J-Server
Ubuntu
Redundant
Home assistant
Host2
wg0_pfsense

The pfSense adapter names matched the switch names:

pfsense adapter: WAN        -> switch: WAN
pfsense adapter: Upstairs   -> switch: Upstairs
pfsense adapter: Downstairs -> switch: Downstairs
pfsense adapter: Security   -> switch: Security
pfsense adapter: J-Server   -> switch: J-Server
pfsense adapter: Ubuntu     -> switch: Ubuntu
pfsense adapter: Redundant  -> switch: Redundant
pfsense adapter: 4G-Dongle  -> switch: 4g dongle

That made the rebuild mechanical instead of guesswork.

Recovery Sequence

The recovery was done in layers:

  1. Capture the current Hyper-V and host network state.
  2. Recreate the internal switches.
  3. Recreate the external switches against the correct physical NICs.
  4. Reconnect the pfSense VM adapters to the matching switches.
  5. Reconnect Home Assistant to Upstairs.
  6. Reconnect Ubuntu Server to Ubuntu.
  7. Remove unwanted default routes Windows picked up on internal networks.
  8. Verify pfSense interface IPs and downstream VM connectivity.

After the repair, pfSense reported the expected interface addresses again:

WAN:        118.209.19.216
Upstairs:   192.168.2.1
Security:   192.168.4.1
J-Server:   192.168.5.1
Ubuntu:     192.168.6.1
Redundant:  192.168.7.1
4G-Dongle:  192.168.100.123

Home Assistant came back on:

192.168.2.193

Ubuntu Server needed a separate adjustment. It had been configured with fixed 8 GB startup memory, and the host could not allocate that much at the time. Changing it to Dynamic Memory with a 3 GB startup and 8 GB maximum allowed it to boot.

The Route Trap

One secondary issue appeared after the switches were recreated: Windows learned routes on networks where it should not have been making routing decisions.

That can happen when the host has management access to multiple Hyper-V networks. It is especially risky when one of those networks is supposed to be behind pfSense.

After a Hyper-V switch rebuild, check the host route table:

Get-NetRoute-AddressFamily IPv4 |
  Sort-Object DestinationPrefix, InterfaceMetric |
  Format-Table ifIndex, DestinationPrefix, NextHop, RouteMetric, ifMetric

For router VM environments, the host should not accidentally prefer a lab, internal, or failover adapter as its default path. If it does, the host can bypass the firewall or make troubleshooting look inconsistent.

What To Capture Before Changing Anything

When Hyper-V networking breaks, the temptation is to click around until traffic comes back. That is risky when a pfSense VM is the router.

Capture evidence first:

Get-VMSwitch | Format-List * > vmswitch-before.txt
Get-VMNetworkAdapter-All | Format-Table VMName,Name,SwitchName,Connected,MacAddress,IPAddresses > vmnics-before.txt
Get-NetAdapter | Format-Table Name,InterfaceDescription,Status,MacAddress,LinkSpeed > netadapter-before.txt
Get-NetRoute-AddressFamily IPv4 > routes-before.txt
ipconfig /all > ipconfig-before.txt

Then check event logs:

Microsoft-Windows-Hyper-V-VmSwitch-Operational
Microsoft-Windows-Hyper-V-VMMS-Admin
Microsoft-Windows-Diagnosis-Scripted/Operational
System

Those logs were more useful than the VM restore in this incident because they showed what changed on the host.

Prevention

For Hyper-V hosts running infrastructure VMs, we recommend treating virtual switch configuration like firewall configuration. Document it and export it before troubleshooting.

At minimum, keep:

  • Switch names.
  • Switch types: External, Internal, Private.
  • Physical NIC bindings for external switches.
  • VM adapter names.
  • VM adapter MAC addresses.
  • Expected switch for each VM adapter.
  • Expected pfSense interface for each adapter.
  • Expected subnets and gateway IPs.

For pfSense specifically, clear adapter names and stable MAC addresses are worth the effort. When a router VM has eight NICs, “Network Adapter” repeated eight times is not operationally safe.

Final Takeaway

Do not run Windows network reset or automated network diagnostics on a Hyper-V host unless you are prepared to rebuild the virtual switch layer.

On a normal desktop, network reset is usually an inconvenience. On a Hyper-V host running a virtual router, it can remove the road underneath every VM.

The backups still mattered, but they were not the fastest fix. The fastest fix was evidence-based reconstruction:

logs
    -> old switch map
    -> recreated switches
    -> reconnected VM adapters
    -> verified pfSense interfaces

That is the main lesson from this incident. Back up the VMs, but also document the host networking they depend on.

References

Posted

in

by

jcianci12

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *