Network Architecture in Windows NT-based Operating Systems

May 2002

Introduction
Drivers
NDIS
Registry
INFs
Reference

Introduction

This document describes the Microsoft Windows NT/2000/XP/.NET network subsystem architecture. It is intended to be used in the process of writing windows network drivers. I'm really confused by the installation and binding process of Network components (particularly IM drivers), so this is also an attempt for me to get my facts straight. Don't take what you read here as gospel, and please feel free to point out problems or improvements.

The Windows networking subsystem is composed of a set of kernel-mode drivers, a set of user-mode services and DLLs, and their configuration data stored in the registry. Most of this document is devoted to understanding the registry-based configuration details.

Drivers

There are lots of drivers that make up the networking subsystem. In general, they are divided into two classes:

NDIS - Handles network cards, protocols, clients, and services. The bottom of this stack is physical hardware and the top is a TDI interface. These include drivers written by Microsoft as well as third-party drivers. The defining characteristic of an NDIS driver is that it plugs into the NDIS architecture; in other words, it calls NDIS functions and registers callbacks that NDIS calls.
TDI and other non-NDIS stuff - Handles the user-mode interface to protocols. Implements stuff like Named Pipes, Mailslots, Winsock, and so on.

These drivers are all kernel-mode .sys files that communicate with one another via either callback functions or IRPs. Like all drivers, they have entries in the Service Control Manager (SCM) database found at HKLM\System\CurrentControlSet\Services in the registry. Most of the driver files themselves are located in the standard place, %SystemRoot%\System32\Drivers.

NDIS

NDIS (Network Device Interface Specification). The NDIS subsystem forms most of the nuts and bolts of the networking on the computer. NDIS is responsible for getting packets from hardware up to TDI drivers for handing to apps. It's big and complicated.

NDIS is primarily implemented via callback functions. There is a main subsystem driver (ndis.sys), which sets up the framework for packet handling, and there are drivers that are basically just libraries of callbacks that the NDIS system calls when certain things happen.

The NDIS subsystem takes care of much of what network drivers used to have to do. For example, ndis.sys provides the ISR for all incoming packets. It also provides commonly-used data structures such as packets, and takes care of driver-to-driver communication across a well-defined interface.

There are several kinds of NDIS drivers:

Miniport drivers (class: Net, GUID: {4D36E972-E325-11CE-BFC1-08002BE10318}) - basically just network card drivers. They are the first to be called by NDIS when a packet comes in. They control hardware features of the card and basically just shuffle packets from the protocols to the hardware.
Protocol Drivers (class: NetTrans, GUID: {4D36E975-E325-11CE-BFC1-08002BE10318}) - NDIS Protocol drivers implement protocols. Pretty obvious - there's a tcpip.sys, for example, that implements the TCP/IP protocol. They receive packets up from Miniports and down from services, clients, and from TDI.
Client Drivers (class: NetClient, GUID: {4D36E973-E325-11CE-BFC1-08002BE10318}) - NDIS Client drivers are things like "Client for Microsoft Networks" and such. They are higher-level drivers responsible for things like providing a Netbios client API to user applications.
Service Drivers (class NetService, GUID: {4D36E974-E325-11CE-BFC1-08002BE10318}) - NDIS Service drivers include things like File and Print Services, Services For Macintosh, etc.
Intermediate Drivers - These hybrid drivers set between protocols and miniports and actually export two "edges": a lower edge that looks like a protocol and an upper edge that looks like a miniport. In this way, it layers itself in the driver stack and is able to see all packets going to and from the miniports.

These components associate themselves with one another via "binding". The binding process informs the NDIS framework about the order in which packets are to be passed from one driver to the next.

The Registry

All NDIS configuration is contained in the registry. The data is contained in several places:

HKLM\System\CurrentControlSet\Control\Class\{Class-specific GUID} - these four keys (one corresponding to each driver type) tell the device manager and its associated device installers which class installer .dll to use to install devices of the given class. They also name the class (as above), provide a descriptive name, pick an icon for the class for device manager displays, and name the property page provider. In the case of the Network classes, they all use NetCfgx.dll for both the class installer and the property page provider. NDIS Intermediate drivers get one instance per filtered miniport.
- Net GUID: This key contains a subkey for each configured miniport. They are numbered sequentially from 0000. Each adapter key has the same structure. At the top level, a number of adapter-specific configuration parameters are set. These include hardware-related settings, driver information (date, version, etc), installation settings (inf location, etc), and each miniport has a NetCfgInstanceId GUID that functions as the unique identifier for the miniport. My orinoco's guid is {1462C527-B728-4277-AAE6-AC1B5F1C01B6}. Filter drivers (NDIS Intermediate drivers) have a FilterInfId which is set to the network component ID of the service portion. [1]
  - The first subkey under the adapter id is Linkage. It contains three values: Export, RootDevice, and UpperBind. Export is the name of a device object that gets exported to the object manager namespace. This is just the GUID from the adapter subkey. RootDevice seems to always just be the adapter GUID as well. UpperBind is the network component name of the thing the miniport binds to at its upper edge, as specified in the driver's INF file.
    Again, NDIS IM drivers are an exception. Instead of RootDevice just having the instance GUID in the MULTI_SZ array, it actually has that GIUD plus the GUID of one other miniport, in that order. I think that's the way a filter driver associates itself with the next object down in the stack. Because there is one instance of the IM for each underlying Miniport to be filtered, this mechanism winds up filtering all existing Miniports.
  - The second subkey is Ndi. This is where the Ndi-related stuff from the INF winds up. Ndi stands for "Network Device Installer" and provides parameters to the installation and binding engine on how to handle the given device. The Ndi key itself can have a Service value that identifies the Windows service name associated with the driver. NdisWan also has a BindForm value with NdisWanIp in it.
    One exception to this case is with NDIS Intermediate drivers. They do not have an Ndi key.
    When it exists, the Ndi key has one subkey, Interfaces. The Interfaces key has two values: UpperRange and LowerRange. These are binding class names that the given component can bind to on its upper and lower edges. These can be Microsoft-specified or made up by the programmer to force private binding. There doesn't seem to be a place that these values are defined, so it looks like they are called into existence by .inf files.
    I've also seen additional keys, like 'params', under Ndi, but I think they're just driver-defined parameters and such, and are specific to the driver as provided by the manufacturer.
- NetTrans GIUD: Nothing seems to ever be here other than the standard stuff mentioned above, plus two extra values (NoDisplayClass and NoInstallClass) both set to 1, presumably to prevent them from showing up in the device manager tree.
- NetClient GUID: Same as NetTrans.
- NetService GUID: Same as NetTrans

HKLM\System\CurrentControlSet\Control\Network - Additional network control information. Again, there is one subkey for each class GUID, plus an additional GUID for the IR port, if present. There is also a Connections key.
- Net GUID: Contains a subkey for each "real" miniport. Presumably this is where Windows looks when it's trying to decide which adapters to show in the network control panel. There is a subkey for each network adapter that is to be shown (the key name is the component's GUID), and a Descriptions key.
  The adapter keys have no values and one sub-key each, Connection. Here we find the PnPInstanceId value, set to the Plug-n-Play ID of the device, as well as Name, which is the display name for Network Control Panel and Device Manager. Sometimes (real lan adapters usually?) there is a ShowIcon value also, which seems to always be set to 1.
  The Descriptions key has a value for the display name of each of the miniports. The data seems to always be set to 1, except in the case of an NDIS IM driver, in which case it's set to 1 2 3 ..., presumably allowing the GUI to figure out how to decorate the names of the miniports in device manager.
- NetClient GIUD: Contains a subkey for each network client component installed. The Client for Microsoft Networks is one such component. Much of the information that was found in the class key above for the miniports is found here for the rest of the components. The component's componentId, Inf inforiation, characteristics, and description are found here.
  Each client guid has a subkey Ndi. The Ndi key has ClsId, which is looks like it's an Instance GUID, CoServices, which appears to be the list of services the Ndi installs with the component, Service, which is the Win2k service name. The Ndi key has one subkey, Interfaces, which again defines binding relationships. The MS client's LowerRange value of netbios,netbios_smb means it can bind to any netbios or netbios_smb drivers below it. Its UpperRange of winnet5, which is also the upperRange for a few NetService. That word doesn't appear anywhere else in the registry, though, so I wonder if it would still work if it were noupper or something.
  Another option concerning the ClsId key: this might be the class Id of the interface object for the device manager.
- NetService GUID: basically the same stuff as the NetClient GUID, except there are usually more services than clients installed. My mostly-empty Win2k box has 8 services. Most are (noupper, nolower), which I only barely understand - does that mean they don't participate at all in the binding process? Hmmm...
  Filter drivers have more than this. Because filter drivers are two-part[1], the service appears here. The NDI key, in addition to the other stuff it has, lists FilterClass, FilterDeviceInfFile, FilterDeviceInfId, and HelpText. The Interfaces key lists noupper and nolower as filter types, but it also has a FilteredMediaTypes value populated by the INF. Posfire has Ethernet,tokenring,fddi,wan as the value data here.
- NetTrans GUID: A comprehensive listing of the protocol components installed in the system. Each installed protocol gets its own subkey named with its component GUID. I'm not sure where this GUID comes from. Each component has an Ndi subkey, and optionally other subkeys like linkage and parameters. The following components can be found on one of my test computers: TCP/IP, IrDA, WINS (i.e. NetBT), NetBt_SMB, NdisWAN, L2TP, PPTP, CommView network monitor, and probably winpppoe and winpcap, and netmon.
  The Ndi key has the standard stuff - ClsId, HelpText, Service, etc. The Interfaces subkey of the Ndi key contains the same old, mostly confusing, bindings stuff. There is occasionally a linkage key, with Bind, Export, and Route, in similar style as the miniport information above. In particular, this happens with Netbios_Smb.
- The final key is Connections. Its only value is ClassManagers, a multi-sz with three GUIDs in it.

HKLM\System\CurrentControlSet\Services - Holds service control manager entries for all of the device drivers that make up the networking subsystem. All drivers must have an entry in the SCM database (here) in order to be started by the system. The drivers keep much of their configurable or dynamic data here in driver-specific subkeys. In addition to the drivers, each physical miniport gets a GUID corresponding to its NetcfgInstanceId.
All of these keys have the standard windows service stuff - start type, path, etc. They also all have an enum subkey that holds the PnP ID and location on the enumeration tree of the device(s) in question.
- Adapter GUIDs - These SCM entries represent the physical NICs in the system. They have a Parameters subkey which has a subkey for each of the installed (bound?) network protocols. The TCP/IP subkey is where all the per-interface TCPIP configuration values are at. Here you find the basic protocol configuration stuff - IP address, subnet, DHCP info, etc. this is the only key without the standard service stuff.
- Ndis - service for the NDIS wrapper/library/subsystem/whatever. This is the first and main network subsystem driver to load. In addition to the standard stuff, Ndis has MediaTypes, NetDetect, and Parameters subkeys. I don't have a test box with anything in the MediaTypes key, and the Parameters key only has a processoraffinity value that presumably has to do with MP systems. The NetDetect key has values for legacy buses (ISA and EISA). The ISA key is empty other than bustype = 1. The EISA key has bustype = 2, and also has a subkey for 26 built-in EISA NIC drivers. Each key holds the EISA device ID of the corresponding NIC, as well as a mask key that is mysterious. Remember, NDIS is the network metadriver, and since all the nics are supposed to just use miniport drivers, Ndis really does most of the enumeration of the non-pnp stuff that a legacy device driver would normally i do.
- NdisTapi - this service creates two device nodes (found in the enum key) - NdisWanIP and PPTPMiniport.
- NdisWan - this service also has a linkage key in addition to the others. The linkage key has the usual bind, export, and route keys. Each has a list of device objects in the form of \Device\{GUID}. The GUIDs correspond to the RAS-capable adapters in Control\Class\NetGUID. I have devices here for pptp, async, l2tp, irda, and irdamodem.
- NDProxy - nothing unique here
- NetBios - This service key controls the Netbios service. This also has a linkage key with Bind, Export, and Route keys, and adds a LanaMap for keeping track of Lanas. The Bind value contains devices referencing the GUIDs of the adapters that Netbios is bound to. I have binding to my ethernet card, as well as two mystery GUIDs that I can't find anywhere else except in NDISWan and TCPIP\Interfaces. Hmmm.
- NetBT - Netbios-over-tcpip service - Also has a linkage key with similar device exports and binds. Also has an OtherDependancies value that lists TCP/IP.
  In addition, NetBT has a parameters key that is structured similarly to TCPIP's. Global parameters such as timeouts, etc., are in the Parameters key, and interface-specific parameters are set in one of the interface subkeys under parameters. The interfaces are of the form Tcpip_{GUID}, and correspond to the TCPIP interfaces.
- Tcpip - handles the TCPIP.SYS driver, which provides the basic stack, plus contains all of the TCPIP-related config data. In addition to the standard keys, the following extra keys are present:
  - Linkage - like the other linkage keys, has Bind, Export, and Route values. The Bind value points to the device object of the physical NIC and to NdisWanIP. The export values are of the form \Device\TCPIP_{GUID}, where the GUID corresponds to a miniport. I have two extra guids here that I'm not sure about.
  - Parameters - Holds all the global TCP/IP configuration parameters. Also has a bunch of subkeys:
    Adapters - has no values of its own but lists the two targets specified in the bind value above: the device object of the physical NIC and NdisWanIP. The NIC entry has two values: an IpConfig value with data set to TCPIP\PARAMETERS\{adapter's GUID} and an LLInterface value with empty data. The NDISWANIP key has four values: IpConfig, set to TCPIP\PARAMETERS\{the two mysterious GUIDs}; IpInterfaces, set to some apparently meaningless binary data; LLInterface with data WANARP, and NumInterfaces set to 2.
    DNSRegisteredAdapters - this key is empty on both test boxes.
    Interfaces - this subkey has a GUID for each interface enumerated by the Adapters key, including the ones identified by NdisWanIp. Inside each subkey are interface-specific tcp/ip configuration parameters.
    PersistentRoutes - has a value name for each route saved as a persistent route
    Winsock - has some winsock-specific config parameters including a big old binary value that I don't understand.
  - Performance - looks like config data for performance management counters, etc.
  - ServiceProvider - Winsock config parameters, including name resoultion priority a la nsswitch.conf

INF files

All of the madness that we just went through in the registry happened because INF files told it to. In particular, network INF files are interpreted in combination between the Network Device Installer and Device Manager. Device Manager does the generic stuff like PnP identification and driver selection, and it looks like it also handles the basics of file copying, service creation, registry modifications, etc. Then, at some point after Device Manager is done, the Network Device Installer is invoked and takes another pass through the system at configuration of the network components. Here, bindings are processed and components are logically linked together to form the networking subsystem.

As can be imagined, INFs are very flexible, but they're not very well documented. The best source of documentation of the INF format is in the DDK (with overlapping but slightly different info in Win9x and WinNt versions). The platform SDK also has some INF-related info. Beyond that, the best references are sample INFs provided in the DDK and third-party INFs from other vendors.

Reference

GUIDs

{4D36E972-E325-11CE-BFC1-08002BE10318} - Net - miniports are members of this class, and NetCfgx.dll provides the Net class installer.
{4D36E975-E325-11CE-BFC1-08002BE10318} - NetTrans - network protocols are members of this class. NetCfgx.dll provides the NetTrans class installer.
{4D36E973-E325-11CE-BFC1-08002BE10318} - NetClient - Network clients class. Class installer is also NetCfgx.dll
{4D36E974-E325-11CE-BFC1-08002BE10318} - NetService - Network Service class. Class installer provided by NetCfgx.dll
{1462C527-B728-4277-AAE6-AC1B5F1C01B6} - My Orinoco card's NetCfgInstanceId GUID

[1] NDIS Intermediate drivers are one binary with two parts. The "lower edge" looks like a protocol (like TCP/IP or something). The "upper edge" looks like a miniport. This binary is installed with a pair of INFs. The weird part is that one INF is a NetService INF and the other is a Net inf. The NetService is the one that gets fed to the network control panel since the Net component is hidden by its INF. However, there is not an entry in the NetService GIUD. Marking the driver as filter does weird things to the NDI.