NDIS and network adapters

The TCP/IP stack implements protocol logic; it doesn't talk to hardware directly. NDIS (Network Driver Interface Specification) is the layer underneath it — the contract between upper networking layers and the drivers that actually manage physical or virtual network adapters.

The driver roles NDIS coordinates

Following the same layered-driver pattern already covered in Drivers & device stacks, NDIS coordinates several distinct driver roles:

• Miniport drivers — the hardware-specific layer, managing a physical or virtual adapter directly and exposing the fundamental send/receive primitives NDIS itself standardizes.
• Protocol drivers — implement a networking protocol's binding to the adapter (TCP/IP itself binds this way, from NDIS's point of view).
• Filter drivers — sit in between, able to observe or modify traffic as it passes from protocol drivers down to miniports and back, without owning either end of that relationship themselves.

NDIS's job is standardizing how all three of these interact: consistent entry points, consistent state management, and a consistent binding model, so that a filter driver written by a third party can insert itself between essentially any protocol stack and essentially any adapter, without needing custom integration work for each combination.

Why "offload" settings live here, and why they matter this much

Modern network adapters can implement parts of the protocol-processing work in hardware rather than leaving it entirely to software — checksum calculation, segmentation of large sends into properly-sized packets, and more, offloaded onto the adapter's own processor. These offload capabilities are exposed and configured at exactly this NDIS/miniport layer. This is precisely why toggling an offload setting can change CPU usage and throughput dramatically: it's genuinely moving real computational work between the CPU and the adapter's own hardware, not adjusting some minor, cosmetic configuration knob. A misbehaving offload feature (a known driver bug interacting badly with a specific offload) is also a classic, well-documented cause of subtle networking problems that look like higher-layer bugs but are actually resolved by disabling one specific hardware feature.

"The NIC driver" is usually more than one component

A common oversimplification: assuming a networking problem, once narrowed down to "the driver," must be a single, monolithic NIC driver misbehaving. In practice, what's often loosely called "the driver" is a stack in its own right — a miniport managing the actual hardware, plus potentially several filter drivers (a VPN client's filter, a virtualization platform's virtual switch filter, a security product's inspection filter) all bound into the same NDIS chain. A problem attributed to "the network driver" can just as easily originate in one of these filters as in the hardware-facing miniport itself.

A worked example: a VPN client changing observed network behavior

A VPN client commonly installs its own NDIS filter driver (or, in some designs, a virtual miniport representing the VPN's own virtual adapter) specifically so it can intercept, encrypt, and redirect traffic before it reaches the physical adapter. This is exactly why installing or enabling a VPN can change performance and behavior even for traffic that isn't obviously "going through the VPN" from the application's point of view — the filter is positioned at the NDIS layer, genuinely inside the packet path for that adapter binding, not merely configuring routing from outside.

A common mistake

Searching only for "the NIC driver" when investigating a networking problem, rather than considering the full NDIS binding chain (miniport plus every filter bound above it), routinely misses the actual cause — modern machines commonly have several NDIS filter drivers installed by entirely unrelated software (security products, virtualization platforms, VPN clients), any one of which can independently affect behavior.

Where this connects

• Filtering & firewalling covers a specific, security-focused use of exactly this filter-driver mechanism.
• Drivers & device stacks covers the general layered-driver pattern NDIS is a specialized application of.