Hi All,
I have a customer using a Virtual Box VM (windows 7). Our software has to identify the NIC’s to bind its filter drivers too, and for global deployment using a single configuration file we use the NIC Display Name for identification. This has worked for many years and indeed I use virtual box all the time.
However on this particular customers VBox VM the network properties dialog and registry display the following information:
Name: LAN1 Device Name: Intel(R) PRO/1000 MT-Desktopadapter
Name: LAN2 Device Name: Intel(R) PRO/1000 MT-Desktopadapter #2
Now when I run InetCfgComponent to show the Display Name it returns:
LAN1: Intel(R) PRO/1000 MT Desktop Adapter
LAN2: Intel(R) PRO/1000 MT-Desktopadapter #2
So the display name for LAN 2 is correct but why is the display name for LAN1 not the same as what is shown in the network properties dialog?
According to MSDN, INetCfgComponent::GetDisplayName “… retrieves the name of a network component that the network configuration subsystem displays in the property sheet dialog box for a network connection”. This does not appear to be the case for LAN1.
Furthermore I have searched the registry but cannot find the string “Intel(R) PRO/1000 MT Desktop Adapter” which GetDisplayName returns, so where is it getting it from?
Alan
I was too hasty with my first post and should clarify that INetCfgComponent::GetDisplayName is working as per MSDN, where the device name displayed in the Network Adapters properties dialog does match what is returned by INetCfgComponent::GetDisplayName.
However the Network Properties dialog adapter name is different.
So if I run ncpa.cpl to bring up the Network Connections Explorer window it displays “Intel(R) PRO/1000 MT-Desktopadapter” which is not the same as what INetCfgComponent::GetDisplayName returns.
If I then open the properties dialog for this connection, the Networking tab shows “Connect using: Intel(R) PRO/1000 MT-Desktopadapter” which again is not the same as what INetCfgComponent::GetDisplayName returns.
If I then click the Configure button on this dialog to open the adapter properties dialog it does display “Intel(R) PRO/1000 MT Desktop Adapter” which is the same as INetCfgComponent::GetDisplayName.
The adapter name returned by INetCfgComponent:GetDisplayName does not appear anywhere in the registry. Instead the registry has the same string as is shown in the network connections window.
Also setupapi.dev.log does not show the adapter name which INEtCfgComponent:GetDisplayName returns. Here is the extract:
dvi: Enumerating INFs from path list ‘C:\Windows\inf’
inf: Opened INF: ‘C:\Windows\System32\DriverStore\FileRepository\nete1g3e.inf_amd64_neutral_7f08406e40c6ede2\nete1g3e.inf’ ([strings.0407])
inf: Saved PNF: ‘C:\Windows\System32\DriverStore\FileRepository\nete1g3e.inf_amd64_neutral_7f08406e40c6ede2\nete1g3e.PNF’ (Language = 0407)
dvi: Created Driver Node:
dvi: HardwareID - PCI\VEN_8086&DEV_100E&SUBSYS_001E8086
dvi: InfName - C:\Windows\System32\DriverStore\FileRepository\nete1g3e.inf_amd64_neutral_7f08406e40c6ede2\nete1g3e.inf
dvi: DevDesc - Intel(R) PRO/1000 MT-Desktopadapter
dvi: DrvDesc - Intel(R) PRO/1000 MT-Desktopadapter
dvi: Provider - Microsoft
dvi: Mfg - Intel
dvi: ModelsSec - Intel.NTamd64
dvi: InstallSec - E100ECopper
dvi: ActualSec - E100ECopper
dvi: Rank - 0x00ff0001
dvi: Signer - Microsoft Windows
dvi: Signer Score - INBOX
dvi: DrvDate - 05/28/2008
dvi: Version - 8.4.1.0
The really weird thing is that nete1g3e.inf only contains the string “Intel(R) PRO/1000 MT Desktop Adapter” which is the same as INetCfgComponent::GetDisplayName returns and does not contain the string “Intel(R) PRO/1000 MT-Desktopadapter” which is written to the setupapi.dev.log. So if this string is not in the nete1g3e.inf file where does the string originate from?
Alan
I don’t know how the names were separated, but I can give you some background information that might be helpful. Let’s trace the “flow” of names as a NIC is installed.
- All devices match some “model” in an INF. For example:
[Intel.NTx86]
%21140.DeviceDesc% = 21140.ndi, PCI\VEN_1011&DEV_0009&SUBSYS_21140A00&REV_20
The first part is a localized string; go to the string table to find the actual value:
[Strings]
21140.DeviceDesc = “Intel 21140-Based PCI Fast Ethernet Adapter (Emulated)”
When this device is installed, PNP grabs that string and saves it as the DEVPKEY_Device_DeviceDesc property on the devnode.
-
For networking devices, the networking class installer notices the installation of a new device. The class installer reads the DeviceDesc property and tries to make it “unique” across all networking devices. Typically, this means that if you have three devices with DeviceDesc “abc”, then the class installer will leave the first as “abc”; name the second “abc #2”; and the third “abc #3”. These new names are saved to two places: PNP’s DEVPKEY_Device_FriendlyName and networking’s ifDescr.
-
If, later, somebody calls INetCfgComponent::SetDisplayName, that updates BOTH the DEVPKEY_Device_FriendlyName and networking’s ifDescr. However, if somebody calls SetupDiSetDeviceProperty(DEVPKEY_Device_FriendlyName), that only updates the PNP store. (Networking’s class installer isn’t notified that the PNP name has changed, and so networking doesn’t know to update the ifDescr as well).
Now you can probably guess how things can get weird. PNP and networking have their own notion of a device’s “name”. PNP stores it in DEVPKEY_Device_FriendlyName, while networking stores it in ifDescr. There’s a well-known public API to set each of these, but only one of the APIs keeps both in sync.
Various user interfaces will show different things. UIs that are networking-specific (like Network Connections folder) tend to show the ifDescr. But UIs that are generic to all devices (like Device Manager) tend to show DEVPKEY_Device_FriendlyName (via DEVPKEY_NAME).
Incidentally, there’s actually a reason for the split between PNP and Networking. Theoretically, a “network interface” is anything that can send packets, and may not have a precise 1:1 relationship to a PNP device. For example, an NDIS filter has a Network Interface (including its own ifDescr), but it doesn’t have any PNP device associated with it. That’s why network names and PNP names are stored separately.
On 02-May-2013 12:00, xxxxx@brandcomms.com wrote:
The really weird thing is that nete1g3e.inf only contains the string “Intel(R) PRO/1000 MT Desktop Adapter” which is the same as INetCfgComponent::GetDisplayName returns and does not contain the string “Intel(R) PRO/1000 MT-Desktopadapter” which is written to the setupapi.dev.log. So if this string is not in the nete1g3e.inf file where does the string originate from?
OID_GEN_VENDOR_DESCRIPTION ?
– pa
Or, it could be a bug and some bit of code somewhere just munges the name. Easy enough to ascertain. If you just have Windows installed (no other possible interference) what do the names end up being? Is this effect repeated similarly for other adapter types (you could, for example, go install a couple of Microsoft Loopback Adapters and see …) or is it just the particular adapter you are dealing with? But this is where you might want to start thinking about using a PnP Device Id or Instance Id or some other identifier that is not subject to such whims of fancy.
Good Luck,Dave Cattley
Jeffrey - thanks for the detailed reply, very helpful.
Dave - I have to agree with you that using device name strings is proving to be unreliable. So I am thinking of using PnP Device Id from INetCfgComponent::GetPnpDevNodeId as I am only interested in physical network devices. In sample tests the PnP device ID is consistent across same hardware models including the instance specific ID.
Alan.