Dependency Handling for Network Components

Services can be dependent upon other services or drivers, which can be dependent upon others, and so on. The system can establish these types of dependencies:

Specific Dependencies

A specific dependency is simply the name of a necessary service. By default, the system generates explicit names for all dependent services discovered during bindings generation. Specific dependencies are marked in the Registry as a value of the Use entry under the component's NetRules subkey.

For example, assume the Workstation service is dependent upon NBF. NBF is connected to two adapter cards and so is dependent upon their drivers. The system marks NBF as dependent upon the two network card drivers and marks the Workstation service as dependent upon the network card drivers and NBF.

Group Dependencies

It often happens that a service should be loaded if any member of a set of dependencies successfully loads. In the previous example, the Workstation service fails to load if either of the network card drivers fails to initialize.

Groups are used to support this approach. Any service (driver, transport, or others) can identify itself as being a member of a service group. All Windows NT network card drivers, for example, are treated as members of the group NDIS.

Group dependencies are marked in the Registry as a value of the Use entry under the component's NetRules subkey. Groups are symbolic names listed in the CurrentControlSet\Control\GroupOrderList subkey.

Static Dependencies

A static dependency is a required service in all circumstances and is unrelated to how the system otherwise determines bindings.

When the system computes dependencies, it discards any previously listed dependencies. To guarantee that a service is always configured to be dependent upon another service, you can create the value entry OtherDependencies under the component's Linkage subkey. The OtherDependencies value is of type REG_MULTI_SZ, so it can contain the names of as many services as needed.