SUMMARY
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."