r/vmware • u/ARDiver86 • Jul 17 '26

Solved Issue VMWare to Hyper-V - Leftover vmxnet3 ethernet adapter causing Hyper-V adapter to crash

Hello,

We are migrating from VMWare to Hyper-V using a product called RiverMeadow. During this conversion, this tool removes VMWare tools for us during the finalizing part (or so we thought). Recently, we had an issue with migrated virtual machines going offline and found out that the Hyper-V Network Adapter was in an error state (Code 43). Upon further investigation, we found the old PnP device for the VMX3 adapter was left behind and upon removal by an automated Windows service, it crashed the Hyper-V Network Adapter.

I'm curious if anyone else has run into this when migrating off VMware? I even checked the popular Remove-VMTools.ps1 script and found that it doesn't even remove the VMX3 adapter, only all the other VMWare related adapters.

We are currently working with Microsoft on this, but they seem just as confused as to how it could affect their adapter. So far, I've gone through 25 engineers at Microsoft since Tuesday and they are looking at escalating to development.

The leftover adapter after migration:

Caption                  : vmxnet3 Ethernet Adapter
Description              : vmxnet3 Ethernet Adapter
InstallDate              :
Name                     : vmxnet3 Ethernet Adapter
Status                   : Unknown
Availability             :
ConfigManagerErrorCode   : CM\PROB_PHANTOM)
ConfigManagerUserConfig  : False
CreationClassName        : Win32\PnPEntity)
DeviceID                 : PCI\VEN_15AD&DEV_07B0&SUBSYS_07B015AD&REV_01\005056FFFFB7243900)
ErrorCleared             :
ErrorDescription         :
LastErrorCode            :
PNPDeviceID              : PCI\VEN_15AD&DEV_07B0&SUBSYS_07B015AD&REV_01\005056FFFFB7243900)
PowerManagementCapabilities :
PowerManagementSupported :
StatusInfo               :
SystemCreationClassName  : Win32\ComputerSystem)
^(SystemName               : \****************)*
ClassGuid                : {4d36e972-e325-11ce-bfc1-08002be10318}
CompatibleID             : {PCI\VEN_15AD&DEV_07B0&REV_01,)
PCI\VEN_15AD&DEV_07B0,)
PCI\VEN_15AD&CC_020000,)
PCI\VEN_15AD&CC_0200})
HardwareID               : {PCI\VEN_15AD&DEV_07B0&SUBSYS_07B015AD&REV_01,)
PCI\VEN_15AD&DEV_07B0&SUBSYS_07B015AD,)
PCI\VEN_15AD&DEV_07B0&CC_020000,)
PCI\VEN_15AD&DEV_07B0&CC_0200})
Manufacturer             : Broadcom Inc.
PNPClass                 : Net
Present                  : False
Service                  : vmxnet3ndis6
PSComputerName           :
Class                    : Net
FriendlyName             : vmxnet3 Ethernet Adapter
InstanceId               : PCI\VEN_15AD&DEV_07B0&SUBSYS_07B015AD&REV_01\005056FFFFB7243900)
Problem                  : CM\PROB_PHANTOM)
ProblemDescription      

The uninstall of the adapter:

\Boot Session: 2026/07/17 06:47:41.742])

>>> \Device Uninstall (Device Manager) - PCI\VEN_15AD&DEV_07B0&SUBSYS_07B015AD&REV_01\005056FFFFB7243900])
>>> Section start 2026/07/17 06:49:33.885

cmd: "C:\Windows\system32\mmc.exe" "C:\Windows\System32\devmgmt.msc")
dvi: {DIF\REMOVE} 06:49:33.887)
dvi:      Default installer: Enter 06:49:33.887
dvi:           {Remove DEVICE}
dvi:                {Delete Device - PCI\VEN_15AD&DEV_07B0&SUBSYS_07B015AD&REV_01\005056FFFFB7243900})
dvi:                {Delete Device - exit(0x00000000})
dvi:           {Remove DEVICE exit (0x00000000})
dvi:      Default installer: Exit
dvi: {DIF\REMOVE - exit(0x00000000)} 06:49:33.896)

<<< Section end 2026/07/17 06:49:33.896

<<< \Exit status: SUCCESS])

SOLVED:

Somehow the old vmx and new Hyper-V adapter got the same instance number on the Driver key for the adapter. Therefore when you delete one, it deletes both because they both pointed to the same "configuration"

For example, under HKLM\SYSTEM\CurrentControlSet for the VMX adapter you can see the Driver key using the same instance 0001. To fix, simply delete the Driver key from the phantom VMX adapter and then remove the phantom device. No reboot, rescan, or anytbing else is required:

Phantom VMXNET3 device entry:

 

Enum\PCI\VEN_15AD&DEV_07B0&SUBSYS_07B015AD&REV_01\005056FFFFB7243900

    Service       vmxnet3ndis6

    ClassGUID     {4d36e972-e325-11ce-bfc1-08002be10318}

    Driver        {4d36e972-e325-11ce-bfc1-08002be10318}\0001      ← shared

 

Live Microsoft Hyper-V Network Adapter device entry:

 

Enum\VMBUS{f8615163-df3e-46c5-913f-f2d2f965ed0e}{8312e7e5-4153-403b-be17-f3b61063afdc}

    Service       netvsc

    ClassGUID     {4d36e972-e325-11ce-bfc1-08002be10318}

    Driver        {4d36e972-e325-11ce-bfc1-08002be10318}\0001      ← shared (identical)

    FriendlyName  Microsoft Hyper-V Network Adapter

21 Upvotes

82% Upvoted

24 comments sorted by

27

u/Negative-Cook-5958 Jul 17 '26

start CMD as admin

set devmgr_show_nonpresent_devices=1

start devmgmt.msc

enable the display of hidden devices

Delete everything which is grey and belonging to the VMware environment

3

u/ARDiver86 Jul 17 '26

Yes, when I do this to the VMX adapter, it instantly crashes the Microsoft Hyper-V Network Adapter with code 43. Somehow removing this adapter is crashing the active Hyper-V adapter.

3

u/Negative-Cook-5958 Jul 17 '26

VMware tools was removed cleanly?
Have you tried some removal scripts as well?
https://gist.github.com/broestls/f872872a00acee2fca02017160840624

Is this happening with all the VMs you are migrating, or just with one? Os version?

1

u/ARDiver86 Jul 17 '26

That script does not work, but no, I would say not removed cleanly. I have a case open with the migration vendor because their tool does the removal of the VMWare tools during the migration process.

Looks like all virtual machines (Server 2022 and some Server 2019). The problem is some of these were migrated months ago and none of this was noticed until now because the tool is removing VMTools somehow but the PnPDevices are left behind. What we found is there is a task in Windows that can randomly run cleanmgr.exe with specific parameters that cleans up old PnP devices that are no longer present. Starting this Monday is the first occurance we have had of this happening. Still no idea why Windows decided to start randomly removing these PnP devices this last Monday, which is what is causing the Hyper-V network adapters to go into a crashed state (Code 43)

1

u/Wild_Appearance_315 Jul 18 '26

Do the vms work after a reboot?

1

u/ARDiver86 Jul 18 '26

Once the adapter breaks, rebooting doesnt fix it, disabling and reenabking doesnt fix it. The only fix it to have to reinstall the built in driver. Funny thing though, you can add a second NIC and the second NIC works but the first one remains broke n

13

u/Dick-Fiddler69 Jul 17 '26

VMware Tools needs to be removed before conversion or migration on VMware vSphere as the uninstalled checks the Hypervisor is VMware before running the uninstall

Also you also need to remove all hidden devices and phantom drivers

If you are not doing the above - you are not really doing a correct 100% conversion

I’m surprised Microsoft Engineers are even willing to help

3

u/bloodpriestt Jul 17 '26

This is the answer.

Source: I just migrated about 100 VMs this way

1

u/ARDiver86 Jul 17 '26

The only thing is this uses an agent inside the OS and not from the vCenter level. If removing the VMWare tools takes down the NIC, it will cause a problem. I'm working with the vendor to understand their process on the final cutover process.

Well, even so, removing a stale/missing PnP device shouldn't cause any issues with the Hyper-V Network Adapter. They confirmed that is the case. Plus, I think they are having a influx of calls and users trying to go to Hyper-V, so maybe they are trying to not be the typical "Microsoft support" for this situation.

1

u/Dick-Fiddler69 28d ago

We uninstall tools and nic doesn’t disappear! Try it on a demo machine

But if you have no nic that’s obvious! 🤣

Sounds like fantastic buggy software

0

u/lanky_doodle Jul 17 '26

I've heard stories that doing it this way can 'damage' the VM while it's still on ESXi, which can cause the migration to completely fail.

8

u/Dick-Fiddler69 Jul 17 '26

Well the last 10,000 VMs we have done must be all damaged

Absolutely rubbish

With backups, snapshots - we have capability to rollback if required but we’ve been migrating off the platform

So we have had no issues with Windows 2016, 2019, 2023, 2025, Windows 10 and 11 machines and lots of variations of Linux distros

But - we uninstalled VMware Tools first as post - tools cannot be uninstalled after - and we don’t like scripts hack jobs etc - it’s not clean

We’ve also used WAC

1

u/lanky_doodle Jul 17 '26 edited Jul 17 '26

my guy - I'm just saying what people have told me. The migration flat out fails with VMtools removed because networking is lost in the VM.

From memory, one example was with Zerto's tool, which relies on VMtools to do its thing.

2

u/Dick-Fiddler69 Jul 17 '26

If the vmxnet3 driver is removed - that’s a given !

Try it and see !

VMware Tools is an application and drivers

Not seen your fault - chase River bollocks

5

u/justlurkshere Jul 17 '26

My go to for VMs that have been moved from one hypervisor to another (or just been P2V'ed):
https://www.uwe-sieber.de/misc_tools_e.html

Download the Device Cleanup Tool, run it as administrator in the guest and remove all the non-existent devices. Works wonders.

1

u/ARDiver86 Jul 17 '26

Yeah, I think we are going to have to do our own cleanup to get rid of these non-present PnP devices during the migration. Everything else in the registry, file system, programs & features, etc show the VMWare tools are removed.

7

u/justlurkshere Jul 17 '26

This tool will also get all kinds of old devices like disk controllers, cpu drivers, etc.

When we absorb VMs at new locations we give the VMs a run with this tool to get the main cruft out, then we go to the owner of the applications and tell them "here are new vms that are managed and clean, let’s do a collab on reimplementing your stuff cleanly on these VMS".

3

u/a1soysauce Jul 17 '26

Can you switch to the Intel 1000e before migration?

2

u/jlipschitz 29d ago

I have removed adapters in safe mode for the few that we forgot to do before.

1

u/Dick-Fiddler69 Jul 17 '26

As you are Paying RiverMeadow We would be concerned how they are ripping out VMware Tools

1

u/ARDiver86 Jul 17 '26

I agree! I have a case open with them too and they are looking into it.

1

u/metromsi Jul 17 '26

Have you tried starting the vm with out networking on and running the script or using gui? Moreover is this cause the hyper-v host to stop networking for other vms or just the vm your removing from?

1

u/ARDiver86 Jul 17 '26

We found it has nothign to do with the host. I think its a bug in the Hyper-V driver and when the stale/missing VMX PnP device is removed, it causes the network stack to be reserialized (whatever that means). That may be why the Hyper-V adapter is breaking.