VirtualBox

Opened 7 years ago

Last modified 3 years ago

#16808 new defect

Removed network adapters are still showing in bridged networking

Reported by: viaujoc Owned by:
Component: network Version: VirtualBox 5.1.22
Keywords: bridged networking adapter Cc:
Guest type: all Host type: Windows

Description

When I run "vboxmanage list bridgedifs", I get a list of adapter that still contains adapters that are not in the system anymore. In my case, I used to have VLANs adapters that were created using the Intel ANS utility. The VLAN were since removed but are still showing in VirtualBox bridged networking. This is annoying.

In the log below, all adapters having a HardwareAddress of 00:00:00:00:00:00 are not in the system anymore but are still listed in all VirtualBox bridged networking list.

I tried removing and reinstalling VB, removing and reinstalling the NDIS6 Bridged Network Driver, nothing works, the old adapters are still showing up in the list. The Windows registry does not contain any references to the GUID of the removed adapters anymore. Why is VB still

C:\Program Files\Oracle\VirtualBox>VBoxManage list bridgedifs
Name:            Intel(R) Ethernet I210-T1 GbE NIC
GUID:            da04ab21-b3e6-4bad-b6ad-497cfcd15188
DHCP:            Enabled
IPAddress:       192.168.4.170
NetworkMask:     255.255.255.3
IPV6Address:
IPV6NetworkMaskPrefixLength: 0
HardwareAddress: a0:36:9f:cd:99:ad
MediumType:      Ethernet
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-Intel(R) Ethernet I210-T1 GbE NIC

Name:            Intel(R) Ethernet I210-T1 GbE NIC - VLAN : untagged Intranet
GUID:            42ffbcdd-fad9-4a1e-bc7f-de92582df835
DHCP:            Disabled
IPAddress:       0.0.0.0
NetworkMask:     0.0.0.0
IPV6Address:
IPV6NetworkMaskPrefixLength: 0
HardwareAddress: 00:00:00:00:00:00
MediumType:      Ethernet
Status:          Down
VBoxNetworkName: HostInterfaceNetworking-Intel(R) Ethernet I210-T1 GbE NIC - VLAN : untagged Intranet

Name:            Intel(R) Ethernet I210-T1 GbE NIC - VLAN : VLAN 5 DMZ
GUID:            dbc6c4c8-8e06-4b50-a0ba-b82766724257
DHCP:            Disabled
IPAddress:       0.0.0.0
NetworkMask:     0.0.0.0
IPV6Address:
IPV6NetworkMaskPrefixLength: 0
HardwareAddress: 00:00:00:00:00:00
MediumType:      Ethernet
Status:          Down
VBoxNetworkName: HostInterfaceNetworking-Intel(R) Ethernet I210-T1 GbE NIC - VLAN : VLAN 5 DMZ

Name:            Intel(R) Ethernet I210-T1 GbE NIC - VLAN : VLAN 1 Gestion
GUID:            d59e7f43-fc7f-4830-902a-74881b6354db
DHCP:            Disabled
IPAddress:       0.0.0.0
NetworkMask:     0.0.0.0
IPV6Address:
IPV6NetworkMaskPrefixLength: 0
HardwareAddress: 00:00:00:00:00:00
MediumType:      Ethernet
Status:          Down
VBoxNetworkName: HostInterfaceNetworking-Intel(R) Ethernet I210-T1 GbE NIC - VLAN : VLAN 1 Gestion

Name:            Intel(R) Ethernet I210-T1 GbE NIC - VLAN : VLAN 3 Tests
GUID:            146679e9-63c0-439f-a968-1545520a0e34
DHCP:            Disabled
IPAddress:       0.0.0.0
NetworkMask:     0.0.0.0
IPV6Address:
IPV6NetworkMaskPrefixLength: 0
HardwareAddress: 00:00:00:00:00:00
MediumType:      Ethernet
Status:          Down
VBoxNetworkName: HostInterfaceNetworking-Intel(R) Ethernet I210-T1 GbE NIC - VLAN : VLAN 3 Tests

Change History (9)

comment:1 by Socratis, 7 years ago

Please file Windows related bugs with Microsoft. AFAIK, VirtualBox queries the host for all network adapters. If your network adapters show up, and you don't want them to, then you should clean up your Windows devices.

That's a Windows problem, not a VirtualBox one I'm afraid...

comment:2 by viaujoc, 7 years ago

I have already cleaned and verified my Windows devices using a couple of utilities and procedures listed in the link you provided. None of the removed network adapters are showing up but VB is still listing them. Can you provide more details on how VB is looking up for bridged networking devices? Does the VirtualBox NDIS6 Bridged Networking Driver maintain a cached list of adapters that it is bound to?

comment:3 by viaujoc, 7 years ago

The GUID "146679e9-63c0-439f-a968-1545520a0e34" (the one of my last ghost NIC in VB) does not even exist in my Windows registry anymore. A search for it in regedit yields not results. So where is VB taking it from then?

comment:4 by viaujoc, 7 years ago

Here is the content of my VBoxSVC.log after running the "vboxmanage list bridgedifs" command that outputs non existent adapters.

VirtualBox COM Server 5.1.26 r117224 win.amd64 (Jul 27 2017 12:32:13) release log
00:00:00.000000 main     Log opened 2017-08-26T08:19:38.491088900Z
00:00:00.000000 main     Build Type: release
00:00:00.000000 main     OS Product: Windows 10
00:00:00.000000 main     OS Release: 10.0.15063
00:00:00.000000 main     OS Service Pack: 
00:00:00.031252 main     DMI Product Name: Z9PA-U8 Series
00:00:00.031252 main     DMI Product Version: 1.0X
00:00:00.031252 main     Host RAM: 32718MB (31.9GB) total, 29988MB (29.2GB) available
00:00:00.031252 main     Executable: C:\Program Files\Oracle\VirtualBox\VBoxSVC.exe
00:00:00.031252 main     Process ID: 8260
00:00:00.031252 main     Package type: WINDOWS_64BITS_GENERIC
00:00:00.031252          VirtualBox: object creation starts
00:00:00.031252          Home directory: 'C:\Users\jocelyn\.VirtualBox'
00:00:00.031252          Installed Drivers:
00:00:00.031252            C:\WINDOWS\system32\DRIVERS\VBoxNetLwf.sys (Version: 5.1.26.17224)
00:00:00.031252            C:\WINDOWS\system32\DRIVERS\VBoxUSBMon.sys (Version: 5.1.26.17224)
00:00:00.031252            C:\WINDOWS\system32\DRIVERS\VBoxDrv.sys (Version: 5.1.26.17224)
00:00:00.031252          Loading settings file "C:\Users\jocelyn\.VirtualBox\VirtualBox.xml" with version "1.14-windows"
00:00:00.125009          HostDnsMonitor: old information
00:00:00.125009            no server entries
00:00:00.125009            no domain set
00:00:00.125009            no search string entries
00:00:00.125009          HostDnsMonitor: new information
00:00:00.125009            server 1: 192.168.4.129
00:00:00.125009            domain: intra.intplus.net
00:00:00.125009            no search string entries
00:00:00.125009          HostDnsMonitorProxy::notify
00:00:00.156261          VD: VDInit finished
00:00:00.156261          Loading settings file "D:\Virtual Machines\Fluor00\Fluor00.vbox" with version "1.16-windows"
00:00:00.156261          VirtualBox: object created
00:00:05.245345 main     VirtualBox: object deletion starts
00:00:05.245345 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={4afe423b-43e0-e9d0-82e8-ceb307940dda} aComponent={MediumWrap} aText={Medium 'D:\Virtual Machines\Fluor00\Fluor00-disk1.vmdk' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:00:05.245345 Watcher  ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={0169423f-46b4-cde9-91af-1e9d5b6cd945} aComponent={VirtualBoxWrap} aText={The object is not ready}, preserve=false aResultDetail=0
00:00:05.245345 main     VirtualBox: object deleted

comment:5 by Manschwetus, 7 years ago

I digged my way through the vbox source and found, the adapters list is basically generated based on GetAdaptersAddresses.
I build the example on my own, changing it to use same call parameters as in VBox source, the removed adapters are not listed in its output, but VBoxManage list bridgedifs still shows, them. I also checked/cleaned registry and all, there is no trace for the adapters or their GUIDs on the whole system, except in Virtual Box.

I upgraded from 5.1.28 yesterday to 5.1.30 and today to 5.2, even I uninstalled VBox several times and rebooted, activated, reactivated NDIS, used Ghostbuster and all hints microsoft has regarding this matter, no trace of this interfaces elsewhere except VBox.

Concluding there must be something in the VBox code storing this information somewhere permanently and retrieving it. Would be helpful to get hint where this could be (a list of locations VBox stores information on Windows), then I could uninstall it again and try to clean this up.

Sadly Windows is extremely pitty regarding the adapter naming, so I could try to rename it, but not sure if this will break other things, as my problem is that I have a previously existing virtual adapter with the same name as the current, on VM startup VBox tries to resolve configured name and starts for the vanished one, ending up in device not present.
As a workaround, is there a way to configure bridge device by GUID instead of name?

comment:6 by Socratis, 7 years ago

I tried to simply disable, not completely remove, one of my three network adapters in the following hosts (actually one physical computer with triple booting):

  • Win7-32bit (SP1, build 7601)
  • Win7-64bit (SP1, build 7601)
  • Win10-64bit (1607, build 14393.1198)

In all cases, and although VirtualBox was already running, the "disabled" adapter disappeared from the list of available adapters in the Bridged drop-down menu. I'm not sure why a "deleted" adapter still shows up.

Even if you migrate a VM from one computer (A) to another one (B), where the Bridged adapter exists in A but not in B, VirtualBox will try to automagically correct the situation. It doesn't keep a "cache" of adapters.

BTW, all 3 of my hosts are as plain vanilla as they come.

comment:7 by Manschwetus, 7 years ago

Interesting, maybe someone could elaborate which API calls are used to generate the list, maybe I missed one or misread things. As when we have an idea how the seriously removed adapters make it in the list, I could try to find the source of the information. So sample programs with the individual calls would be helpful, to see which one introduces the invalid information.

Maybe it is relevant, that this are/have been ANS VLan nics.

comment:8 by DmitryDoe, 5 years ago

Got the same problem. While looking for soultion, found this post https://stackoverflow.com/a/48134640
It helped me. There were adapters with identical names under different GUIDs, some still present along with removed ones (after win10 upgrades and dealing with Intel ANS VLANs). Copying the post:


All you need to do is to delete adapter's subkey from this key (Warning: only delete the unwanted ones! do not delete your normal (i.e. non virtualbox) network adapters!):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkSetup2\Interfaces

Be aware that you need TrustedInstaller permission. To obtain such permission I used this tool: https://github.com/jschicht/RunAsTI

Last edited 5 years ago by DmitryDoe (previous) (diff)

in reply to:  8 comment:9 by TJJ, 3 years ago

Replying to DmitryDoe:

Got the same problem. While looking for soultion, found this post https://stackoverflow.com/a/48134640
It helped me. There were adapters with identical names under different GUIDs, some still present along with removed ones (after win10 upgrades and dealing with Intel ANS VLANs). Copying the post:


All you need to do is to delete adapter's subkey from this key (Warning: only delete the unwanted ones! do not delete your normal (i.e. non virtualbox) network adapters!):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkSetup2\Interfaces

Be aware that you need TrustedInstaller permission. To obtain such permission I used this tool: https://github.com/jschicht/RunAsTI

Thanks, I just encountered the same when the Win 10 2004 update broke Intel's NIC Teaming (configured through the Intel PROSet software).

The NIC Team adapter was no-longer visible in network devices, but VirtualBox was still displaying this phantom device in the options for the VM bridge adapter settings.

Additionally once I'd updated PROSet and recreated the Team adapter using the same device name, VirtualBox would bind to the old phantom device not the new one. Deleting the phantom devices from the indicated registry location fixed the issue.

I'm not sure if it's Windows' uninstallation of network devices that's erroneously leaving phantom devices behind, or VirtualBox's improper handling of these phantom devices. Seems likely to be the latter, as I've yet to come across another application that offers these phantom devices as valid selections.

Last edited 3 years ago by TJJ (previous) (diff)
Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use