3.2 Binding Overview

At system installation, the process of installing and properly binding together network components proceeds in several steps:

  1. When setup runs, it selects and runs the .inf files for the drivers to be installed. The setup file for each network driver must create the following registry keys into which binding information is written:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
    \NameOfComponent\Linkage

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
    \NameOfComponent\Parameters

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
    \NameOfComponent\CurrentVersion\NetRules

    Such a setup file must write the net rules for its component to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NameOfComponent
    \CurrentVersion\NetRules. If there are other dependencies, these are written to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
    \Services\    NameOfComponent\Linkage as the value of the OtherDependencies entry.

    If the setup file is for a NIC driver or for an NDIS intermediate driver that exports a virtual NIC, it must write the medium type of the NIC(s) it exports to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
    \Services\    NameOfComponent\Parameters as the value of MediaType. MediaType is read by transports and intermediate drivers to eliminate bindings to NICs of media type(s) not supported by such drivers. Valid media types are defined in ntddndis.h and in the registry as the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
    \NDIS\MediaTypes     value entry. For more information about setting up experimental medium types, see also Section 3.4.8.

  2. Next, the binding engine runs and performs an analysis of the relationship between the network components installed in the system. The binding engine reads the values of the NetRules entries from the registry and writes them to its information database along with rules imposed by the system, called the built-in rules, and the values of the OtherDependencies entries, if any, stored in the registry. The binding engine does its analysis based on this registry information and writes the result to the registry for each network component under its HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
    \    NetworkComponentName\Linkage key as the values of the Bind, Export, and Route entries.

  3. When the Service Controller runs, it loads network drivers based on the dependencies found in the registry. For instance, NetBT has a dependency on TCPIP that is stored in the OtherDependencies entry of its …\Linkage key.

  4. NDIS and network components read the binding information in the registry during driver initialization. NDIS uses binding information to instruct some components, such as NIC drivers, to initialize the underlying adapters. NDIS reads this binding information in the registry to discover what adapters are managed by each NIC driver and calls each such NIC driver at its MiniportInitialize function once for each such adapter NDIS discovers in the registry.

    If it does not register a ProtocolBindAdapter function with NDIS, a transport protocol driver or an intermediate driver either reads the registry to discover what underlying adapter(s) it can bind to, or the driver can be statically bound to an underlying NIC and, as a result, always "know" to what adapter name it will bind itself. Otherwise, a transport's or intermediate driver's ProtocolBindAdapter function will be called when NDIS discovers the NIC(s) to which the transport or intermediate driver can bind itself are up and available for I/O operations.

Any network component can also specify that its bindings must be reviewed after the binding analysis is complete. To request a second execution of a component’s setup file, the component's .inf script writes a value of one at the Review entry of the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NameOfComponent
\CurrentVersion registry key. During its binding-review processing, the .inf reads the results of the binding operation that was stored in the registry and adds to or modifies the information. See Section 3.5 for a more complete discussion of a binding review.

After initial system setup, the NCPA can be run to modify the network configuration. For instance, the user can run NCPA to add or delete a network card and its driver. If this occurs, the binding engine is run again and any ensuing new binding results are written into the registry. Whenever NCPA is run to carry out a requested operation, the .inf scripts for all the network components also will be run, just as at system setup time, including all requested review passes.