REG: Network Adapter Cards Entries, PART 1

Last reviewed: May 8, 1997
Article ID: Q102999

The information in this article applies to:

Windows NT operating system version 3.1
Windows NT Advanced Server version 3.1

The article contains REGISTRY entries for the Network Adapter Cards, Part 1. These subgroups are included:

NetRules Subkey
Linkage Subkey Entries for Network Components

For the Parameters Subkey entries, see the article Network Adapter Cards Entries, Part 2.

Network Adapter Cards Entries

This section describes specific Registry entries related to network adapter cards and the drivers for network adapters. Windows NT supports network adapter drivers under the NDIS 3.0 specification (Network Device Interface Specification). The CurrentControlSet\Services subkey for a network driver or adapter card includes the standard entries found in the Services subkeys, with the following default values:

Entry Value     Value

Error Control   0x1 (normal)
Start           0x3 (load on demand)
Type            0x1 or 0x4 (driver or adapter)

The following sections describe entries in the other areas of the Registry that contain configuration information for network adapter cards and their drivers, including:

NetRules subkeys under HKEY_LOCAL_MACHINE\SOFTWARE for drivers and adapters.
Linkage subkey entries under HKEY_LOCAL_MACHINE\SYSTEM for drivers and adapters, defining information about bindings for the component.
Parameter subkey entries under HKEY_LOCAL_MACHINE\SYSTEM for network card adapters, defining specific information such as the IRQ number, I/O base address, and other details. (In "Network Adapter Cards Entries, PART 2".)

The information provided here is chiefly to be used for informational and troubleshooting purposes. The settings for either the NDIS driver or the network adapter card should be changed using the Network icon in Control Panel.

For information about Registry values for other network services, see the appropriate article in the "Network Services Entries" article series. For TCP/IP entries that are specific to network adapter cards, see the articles "TCP/IP Transport Entries" Part 1 and Part 2.

NetRules Subkey Entries

During network reconfiguration (that is, when you use the Network icon in Control Panel to make changes), the system reads the values stored in the NetRules subkeys for information used to bind the network components. The Registry path for these value entries is the following:

For adapter card drivers and network services, where the driverName subkey is the name of the network card’s driver, as defined by the system:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft

     \driverName\CurrentVersion\NetRules

For network adapter cards, where the netcard# subkey is a number, beginning with 01 for the first network adapter:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT

     \CurrentVersion\NetworkCards\netcard#\NetRules

Bindable     REG_MULTI_SZ    fromClass toClass  Yes|No Yes|No  value

Defines a possible binding and its constraints. For example: bindable = ndisDriver ndisAdapter non exclusive 100

This example specifies that components of class "ndisDriver" can be bound to those of class "ndisAdapter." For the other fields in this example:

Non indicates that the component of class ndisDriver can accept other bindings.
Exclusive indicates that the component of class ndisAdapter cannot accept other bindings.
100 indicates the relative importance (weight) of this binding; that is, in cases of competition, it will be discarded in favor of other bindings whose weight is greater.

Because this value entry is a REG_MULTI_SZ, as many criteria for binding as necessary can be defined by a single component.

This value entry is optional, because there are a few predefined binding rules, and binding rules defined anywhere in the system apply to all network component classes.

Bindform     REG_SZ   ObjectName  Yes|No Yes|No [container|simple|streams]

The ObjectName field contains the name (or name prefix) by which the component is identified by the system. This value must be the same as the name in the related CurrentControlSet\Services subkey. Names for adapters are created by the system and override the Bindform setting. The first Yes|No pair indicates whether the component is to receive binding information directly in its Linkage subkey. The second Yes|No pair indicates whether the device name is supposed to appear in generated binding strings.

The final optional value in this entry indicates how binding device names are constructed. This value is required for software components.

Class    REG_MULTI_SZ    NewClassName  OldClassName|basic [Yes|No]

Allows a component to define a new class. As many new classes as necessary can be defined by any component.

NOTE: These classes are not related to the OLE and DDE classes defined under HKEY_LOCAL_MACHINE\SOFTWARE\Classes.

Class names do not need to be defined within any particular component. The system adds the new definition to its database without regard to origin. The order of Class entries is irrelevant. However, results are indeterminate if classes are referred to that are not defined anywhere in the system.

This entry is optional, because there are a few predefined classes, and class definitions made anywhere in the system apply to all network components. Because any network component can define new classes, be careful that the names used are unique within all possible installable network components. The following shows the predefined class names in the first release of Windows NT. This list, of course, cannot be exhaustive.

Predefined Class     Adapter Card Type

ee16Driver           Intel EtherExpress 16 LAN
ee16Adapter          adapter

elnkiiAdapter;       3Com Etherlink II adapter

elinkiiDriver

ibmtokDriver;        IBM Token Ring adapter

ibmtokAdapter

lanceDriver;         DEC Lance adapter

dec101Adapter

lt200Driver;         Daystar Digital LocalTalk
lt200Adapter         adapter

ne2000Driver;        Novell NE2000 adapter

ne2000Adapter

proteonDriver;       Proteon adapter

p1390Adapter

ubDriver; ubAdapter Ungermann-Bass Ethernet

                     NIUpc adapter

wdlanDriver;         SMC (WD) adapter

smcisaAdapter

The final optional value indicates whether this class is a "logical end- point" for the bindings protocol; the default value is No.

Hidden     REG_DWORD     0 or 1

Suppresses the display of the component (adapter or network software) in the Network dialog box in Control Panel.

Usually, all networking components discovered in the Registry are displayed in the two list boxes in the Network dialog box in Control Panel. Setting this value to 1 prevents the item from being displayed, which means it cannot be configured or removed by the user.

Interface    REG_MULTI_SZ

Allows a single component to make available more than one type of capability to other components in the system. The format for this value is:

Interface = interfaceName upperClass "objectName" namingMethod

Value               Meaning

interfaceName       The tokenized name of the secondary
                    interface.

upperClass          The class to which the interface
                    belongs. (LowerClass is the same as
                    the primary interface.)

objectName          The Windows NT device name to be

created.

namingMethod        Determines how the bindings appear.


Review      REG_DWORD     0 or 1

Indicates whether a component requests bindings review. If set to 1 (or nonzero), the system reinvokes this component’s .INF file after bindings have been changed. This allows network components to modify the binding information or request additional information from administrators about the new or altered connections.

Type     REG_SZ     component className  [lowerClass]

Defines the type of the component in terms of abstract network component classes. If the optional lower class name is absent, the first (or upper level) class type name is used for both its upper and lower classes.

This value is required for network software and network adapter cards.

Component          Meaning
Type

Adapter            A piece of hardware

Driver             A software component associated
                   directly with a piece of hardware.

Transport          A software component used by services.

Service            A software component providing capability
                   directly to user applications.

Basic              A token used to represent a fundamental
                   class name (that is, a class with
                   no parent).


Use     REG_SZ     service|driver|transport|adapter [Yes|No]  [Yes|No]

Defines the role played by the component. If this entry is absent, the value of Service is assumed. This value entry only appears for software items.

A hardware device is automatically assumed to be an adapter. Each network component may identify itself as a driver, transport, or service to clarify its role. This distinction is as follows (note the lowercase for the values):

Value     Meaning

driver    Exists only to support one or more
          adapters. If no bindings are generated
          (or permitted by the user) that include
          a particular driver, that driver is not
          loaded. However, no error is generated,
          since no "denial of service" has occurred.

service   Provides end-user functionality, and every
          attempt is made to support its operation.
          An EventLog entry is generated if a service
          is present in the system for which there is
          no available transport (the number of
          possible bindings is zero).

transport Exists only to support services. Like a

          driver, it is not loaded unless necessary.

The final two Yes|No values in this entry are optional; if present, each must be either Yes or No. The first value indicates whether driver group names are used instead of specific driver dependencies. The second value indicates whether transport group names are used instead of specific transport dependencies. These values cause the system to generate references to dependencies based upon their group names, not by their specific service names.

For example, the LanmanServer is marked as Yes Yes; this means that its transport and driver dependencies are at the group level; so LanmanServer will be loaded if any one of its transport dependencies and any one of its driver dependencies successfully load.

The RawRules entry appears under the following Registry path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NCPA\CurrentVersion

RawRules      REG_MULTI_SZ     (rule 1 data) (rule 2 data) ...

Contains the rules for the binding algorithm, and consequently allows direct interaction with the bindings inference engine through unrestricted rule addition. The system simply combines all RawRules with the generated configuration rule set before running the inference engine.

IMPORTANT: The RawRules value entry is not directly supported, and should be avoided unless absolutely necessary.

Under this same Registry path for NCPA, a volatile subkey appears named ConfigChanged whenever the network configuration is changed. This allows the system to change the Cancel button to Close in the Network dialog box under Control Panel. It also causes the system to prompt the user to restart the system each time the Network icon is chosen before a system restart has occurred.

Linkage Subkey Entries for Network Components

Each network component that the system determines to be required can be given bindings, which establish the relationships between network software components, as described in "Bindings for Network Components" in the "Windows NT Resource Kit," Chapter 11, "Overview of the Windows NT Registry." All bindings are created by the system and should not be changed by the user, except by choosing the Bindings button in the Network dialog box in Control Panel.

Whether the bindings actually appear in the Registry depends upon the Bindform value for the component in its NetRules subkey.

The binding information is stored in three value entries in the Linkage subkey for a component under the Services subkey. The Registry path for each Linkage subkey is the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

     \ServiceName\Linkage

If a binding is disabled, the settings are stored under a Disabled subkey under the Linkage subkey. These values are in exactly the same format as for active bindings.

For a network component, there might be more than one subkey under its Services key: one for the driver and one for the network adapter card, plus additional subkeys for services that might be installed with the network adapter. Also, entries for adapter cards for AppleTalk, DLC, NWLink, and TCP/IP are described in their respective articles in the "Network Services Entries" article series. See Part 1 for a complete listing.

Bind     REG_MULTI_SZ     ObjectName ObjectName ...

Each string in this value entry is the name of a Windows NT object created by the underlying software. The names are based on the object names declared in the Bindform entry under the NetRules subkey.

Export     REG_MULTI_SZ     ObjectName ObjectName ...

Each string in this value entry indicates the name that should be added in the system to allow access to the corresponding bound object. The names are based on the object names declared in the Bindform entry under the NetRules subkey.

Route     REG_MULTI_SZ     "Name of service" "Name of service"...

Each string in this value entry indicates the exact path through the binding protocol represented by the binding. The names of services are used, surrounded by quotation marks.

Each element of these multistring values has a one-to-one correspondence with the others; that is, Bind[1] is to Export[1] and Route[1] as Bind[2] is to Export[2] and Route[2].

In addition to generating binding information, the system determines each network component’s complete set of dependencies, and stores them in the related subkey in the CurrentControlSet\Services key. For examples using these value entries, see "Bindings for Network Components" in the "Windows NT Resource Kit," Chapter 11, "Overview of the Windows NT Registry."

Reference: "The Windows NT Resource Kit for Operating System Version 3.1".

Additional query words: prodnt
Keywords : kbother ntregistry
Version : 3.1
Platform : WINDOWS

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: May 8, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.