When a protocol driver wants to read or write messages formatted in its protocol's format from or to the network, the driver must do so using a network adapter. Because expecting protocol drivers to understand the nuances of every network adapter on the market (proprietary network adapters number in the thousands) isn't feasible, network adapter vendors provide device drivers that can take network messages and transmit them via the vendors' proprietary hardware. In 1989, Microsoft and 3Com jointly developed the Network Driver Interface Specification (NDIS), which lets protocol drivers communicate with network adapter drivers in a device-independent manner. Network adapter drivers that conform to NDIS are called NDIS drivers or NDIS miniport drivers. The version of NDIS that ships with Windows 2000 is NDIS 5.
On Windows 2000, the NDIS library (\Winnt\System32\Drivers\Ndis.sys) implements the NDIS boundary that exists between TDI transports (typically) and NDIS drivers. As is Tdi.sys, the NDIS library is a helper library that NDIS driver clients use to format commands they send to NDIS drivers. NDIS drivers interface with the library to receive requests and send back responses. Figure 13-18 shows the relationship between various NDIS-related components.
Figure 13-18 NDIS components
One of Microsoft's goals for its network architecture was to let network adapter vendors easily develop NDIS drivers and take driver code and move it between Consumer Windows and Windows 2000. Thus, instead of merely providing the NDIS boundary helper routines, the NDIS library provides NDIS drivers an entire execution environment. NDIS drivers aren't genuine Windows 2000 drivers because they can't function without the encapsulation the NDIS library gives them. This insulation layer wraps NDIS drivers so thoroughly that NDIS drivers don't accept and process IRPs. Rather, the NDIS library receives IRPs from TDI servers and translates the IRPs into calls into the NDIS driver. NDIS drivers also don't have to worry about reentrancy, in which the NDIS library invokes an NDIS driver with a new request before the driver has finished servicing a previous request. Exemption from reentrancy means that NDIS driver writers don't need to worry about complex synchronization, which is made even more tricky because of the parallel execution possible on a multiprocessor.
The NDIS library hides from both TDI transports and NDIS miniport drivers the fact that it uses IRPs to represent network requests. It does so by requiring TDI transports to allocate an NDIS packet by calling NdisAllocatePacket and then passing the packet to an NDIS miniport by calling an NDIS library function (NdisSend, for example). On Windows 2000, the NDIS library uses IRPs to implement NDIS packets, but on Consumer Windows, it doesn't.
Although the NDIS library's serialization of NDIS drivers simplifies development, serialization can hamper multiprocessor scalability. Standard NDIS 4 drivers (the Windows NT 4 version of the NDIS library) don't scale well for certain operations on multiprocessors. Microsoft gave developers a deserialized operation option in NDIS 5. NDIS 5 drivers can indicate to the NDIS library that they don't want to be serialized; the NDIS library will then forward requests to the driver as fast as it receives the IRPs that describe the requests. Responsibility for queuing and managing multiple simultaneous requests falls on the NDIS driver, but deserialization confers the benefit of higher multiprocessor performance.
NDIS 5 also includes the following features:
The interfaces that the NDIS library provides for NDIS drivers to interface with network adapter hardware are available via functions that translate directly to corresponding functions in the HAL.
Listing the Loaded NDIS Miniports
The Ndiskd kernel debugger extension library includes the !miniports and !miniport commands, which let you list the loaded miniports using a kernel debugger and, given the address of a miniport block (a data structure Windows 2000 uses to track miniports), see detailed information about the miniport driver. The following example shows the !miniports and !miniport commands being used to list all the miniports and then specifics about the miniport responsible for interfacing the system to a PCI Ethernet adapter. (Note that WAN miniport drivers work with dial-up connections.)
kd> .load ndiskd Loaded ndiskd extension DLL kd> !miniports Driver verifier level: 0 Failed allocations: 0 Miniport Driver Block: 817aa610 Miniport: 817b1130 RAS Async Adapter Miniport Driver Block: 81a1ef30 Miniport: 81a1ea70 Direct Parallel Miniport Driver Block: 81a21cd0 Miniport: 81a217f0 WAN Miniport (PPTP) Miniport Driver Block: 81a22650 Miniport: 816545f0 WAN Miniport (NetBEUI, Dial Out) Miniport: 81a21130 WAN Miniport (IP) Miniport Driver Block: 81a23290 Miniport: 81a22130 WAN Miniport (L2TP) Miniport Driver Block: 81a275f0 Miniport: 81a25130 Intel 8255x-based PCI Ethernet Adapter (10/100) kd> !miniport 81a25130 Miniport 81a25130 : Intel 8255x-based PCI Ethernet Adapter (10/100) Flags : 20413208 BUS_MASTER, INDICATES_PACKETS, IGNORE_REQUEST_QUEUE IGNORE_TOKEN_RING_ERRORS, NDIS_5_0, RESOURCES_AVAILABLE, DESERIALIZED, MEDIA_CONNECTED, NOT_SUPPORTS_MEDIA_SENSE, PnPFlags : 00010021 PM_SUPPORTED, DEVICE_POWER_ENABLED, RECEIVED_START CheckforHang interval: 2 seconds CurrentTick : 0001 IntervalTicks : 0001 InternalResetCount : 0000 MiniportResetCount : 0000 References: 3 UserModeOpenReferences: 0 PnPDeviceState : PNP_DEVICE_STARTED CurrentDevicePowerState : PowerDeviceD0 Bus PM capabilities DeviceD1: 1 DeviceD2: 1 WakeFromD0: 0 WakeFromD1: 1 WakeFromD2: 0 WakeFromD3: 0 SystemState DeviceState PowerSystemUnspecified PowerDeviceUnspecified S0 D0 S1 D1 S2 PowerDeviceUnspecified S3 PowerDeviceUnspecified S4 D3 S5 D3 SystemWake: S1 DeviceWake: D1 WakeupMethodes Enabled 6: WAKE_UP_PATTERN_MATCH WAKE_UP_LINK_CHANGE WakeUpCapabilities of the miniport MinMagicPacketWakeUp: 4 MinPatternWakeUp: 4 MinLinkChangeWakeUp: 4 Current PnP and PM Settings: : 00000030 DISABLE_WAKE_UP, DISABLE_WAKE_ON_RECONNECT, Allocated Resources: Memory: f4100000, Length: 1000 IO Port: 1440, Length: 40 Memory: f4000000, Length: 100000 Interrupt Level: 9, Vector: 9 Translated Allocated Resources: Memory: f4100000, Length: 1000 IO Port: 1440, Length: 40 Memory: f4000000, Length: 100000 Interrupt Level: 12, Vector: 39 MediaType : 802.3 DeviceObject : 81a25030, PhysDO : 81a93cd0 Next DO: 81a63030 MapRegisters : 819fc000 FirstPendingPkt: 0 SingleWorkItems: : 81a254e8 : 81a254f4 : 81a25500 : 81a2550c : 81a25518 : 81a25524 DriverVerifyFlags : 00000000 Miniport Open Block Queue: 8164b888: Protocol 816524a8 = NBF, ProtocolContext 81649030 8191f628: Protocol 81928d88 = TCPIP, ProtocolContext 8191f728 Miniport Interrupt 81a00970
The Flags field for the miniport that was examined indicates that the miniport supports deserialized operation (DESERIALIZED), that the media is currently active (MEDIA_CONNECTED), and that it is an NDIS 5 miniport driver (NDIS_5_0). Also listed are the adapter's system-to-device power-state mappings and the bus resources that the Plug and Play manager assigned to the adapter. (See the section "The Power Manager" in Chapter 9 for more information on power-state mappings.)
The NDIS model also supports hybrid TDI transport-NDIS drivers, called NDIS intermediate drivers. These drivers lie between TDI transports and NDIS drivers. To an NDIS driver, an NDIS intermediate driver looks like a TDI transport; to a TDI transport, an NDIS intermediate driver looks like an NDIS driver. NDIS intermediate drivers can see all network traffic taking place on a system because the drivers lie between protocol drivers and network drivers. Software that provides fault tolerant and load balancing options for network adapters, such as Microsoft's Network Load Balancing Provider, are based on NDIS intermediate drivers. The packet scheduler that is part of Microsoft's Quality of Service (QoS) implementation is another example of an NDIS intermediate driver.
NDIS 5 introduces a new type of NDIS driver—a connection-oriented NDIS miniport driver. Support for connection-oriented network hardware (for example, ATM) is therefore native in Windows 2000, which makes connection management and establishment standard in the Windows 2000 network architecture. Connection-oriented NDIS drivers use many of the same APIs that standard NDIS drivers use; however, connection-oriented NDIS drivers send packets through established network connections rather than placing them on the network medium.
In addition to miniport support for connection-oriented media, NDIS 5 includes definitions for drivers that work to support a connection-oriented miniport driver:
Figure 13-19 shows the relationships between these components.
Figure 13-19 Connection-oriented NDIS drivers
Using Network Monitor to Capture Network Packets
Windows 2000 Server comes with a tool named Network Monitor that lets you capture packets that flow through one or more NDIS miniport drivers on your system by installing an NDIS intermediate driver. Before you can use Network Monitor you need to have the Windows 2000 Network Monitor Tools installed on your system. To install these tools, open Add/Remove Programs in Control Panel, and select Add/Remove Windows Components. Select Management And Monitoring Tools, click Details, select Network Monitor Tools, and click OK.
After you've installed Network Monitor Tools, you install Network Monitor by following these steps:
- Bring up the Network And Dial-Up Connections application by right-clicking on the My Network Places icon on the desktop and selecting Properties or by selecting Network And Dial-Up Connections from the Settings option on the Start menu.
- Right-click on a local adapter, select Properties, and click the Install button in the Local Area Connection Properties dialog box.
- Select Protocol, and click the Add button.
- Choose Network Monitor Driver, and click OK
After the Network Monitor driver has installed, you can launch Network Monitor by selecting it from the Programs, Administrative Tools folder in the Start menu.
Network Monitor might ask you which network connection you want to monitor. After selecting one, begin monitoring by pressing the Start Capture button in the toolbar. Perform operations that generate network activity on the connection you're monitoring, and after you see that Network Monitor has captured packets, stop monitoring by clicking the Stop And View Capture button (the stop button that has glasses next to it). Network Monitor will present a view of the capture data like the following:
The screen shot shows the SMB (CIFS) packets that Network Monitor captured as remote files were accessed from the system. If you double-click on a line, Network Monitor will switch to a view of the packet that breaks it apart to show various layered application and protocol headers as shown in the following screen shot:
Network Monitor also includes a number of other features, such as capture triggers and filters, that make it a powerful tool for troubleshooting network problems.