Home What's New! NDIS 5 NDIS 6 General Tools Debugging Testing Design Resources



Installing NDIS Protocol Drivers

These short articles discuss the steps involved in signing and installing NDIS protocol drivers.

bulletPart 1 - Self-Signing NDIS Protocol Drivers for Windows Vista (November 22, 2006)

Describes the minimum steps needed to self-sign a NDIS protocol driver for Windows Vista x64 edition.
bulletPart 2 - Making and Signing Driver Packages for NDIS Protocol Drivers on Windows Vista (November 22, 2006)

Describes how to make and self-sign a driver package for installing the WDK NDIS 6.0 NDISPROT driver on Windows Vista x64 edition.
bulletPart 3 - Programmatically Installing NDIS Protocol Drivers - (November 23, 2006)

Discusses how to programmatically install a NDIS protocol driver using the INetCfg API.


Common Error in Sending or Indicating Custom Packets from a NDIS Filter Driver


Many NDIS filter drivers need to have the capability to inject custom packets into the filter stack. The steps involved in implementing this capability include:

  1. Constructing the custom packet. This involves allocating and initializing various resources.
  2. Sending or indicating the custom packet. Call the appropriate NDIS library routine.
  3. Special handling in completion routines. Custom packets dead-end in the completion. They must NOT be completed the same way as pass-through packets.
  4. Freeing custom packet resources.

The Problem

Some newbie developers get steps 1.) and 2.) correct, but still report "I gotta bluescreen after calling.." some NDIS send or indicate routine.

Very often this fault is because the developer neglected to deal with steps 3.) and 4.). When these steps are neglected the custom packet is completed in the same way as pass-through packets. In this case the custom packet is returned to a NDIS component that didn't actually originate the packet. This almost always causes a crash.

Approaches to Solving the Problem

Without going into detail, the key to solving this problem is to modify the completion routine. You must provide something in each packet that you can examine to differentiate between pass-through packets and your own custom packets. There are at least two ways to distinguish between pass-through packets and custom packets that require different completion handling:

Use Different Packet Pools

Allocate multiple pools. Use separate pools for pass-through packets for custom packets. Using this approach call NdisGetPoolXYZ for packets entering at your completion routine and compare the handle with your driver's pool handles. This comparison should allow you to determine whether the packet is pass-through or custom.

Use Packet Context or Reserved Areas
bulletNDIS 5 Intermediate (IM) Driver - You can put extra information in the ProtocolReserved area of each packet on sends or in the MiniportReserved area for indicated packets.
bulletNDIS 6 Lightweight Filter (LWF) Driver - You can put extra information in the Context area of each NBL.

In your completion routine examine the extra information in your reserved or context area . If you identify a custom packet, then handle the differently from pass-through packets. In particular, for your custom packet just free (or re-cycle) the packet resources that you allocated in step 1.) and return.

This advice applies to NDIS 5 Intermediate (IM) drivers as well as to NDIS 6 Lightweight Filter (LWF) drivers. It also applies whether your are sending packets down the network stack or are indicating them up the network stack.

You should also carefully study the NDIS and kernel routines that you use when freeing resources. For example, NdisFreeNetBufferList does NOT necessarily free the NET_BUFFERs in the NBL.

An essential rule of driver resource management is:

If you allocated it, you must free it!

If you aren't methodical in following this advice you may not have a crash, but you will have a memory leak.


Making NDIS Queries from User Mode

This topic describes how to use IOCTL_NDIS_QUERY_GLOBAL_STATS to make some NDIS queries from an ordinary user-mode application.


This topic describes how to use the Windows Management Instrumentation (WMI)  API to make some NDIS queries from an ordinary user-mode application.

bulletNDIS Query and WMI


Hit Counter12/06/09

PCAUSA Home Privacy Statement Products Ordering Support Utilities Resources
Mailing Lists  PCAUSA Newsletter PCAUSA Discussion List
Rawether for Windows, Rawether .NET, WinDis 32 and NDIS Press are trademarks of Printing Communications Assoc., Inc. (PCAUSA)
Microsoft, MS, Windows, Windows Vista, Windows 95, Windows 98, Windows Millennium, Windows 2000, and Win32 are registered trademarks and Visual C++ and Windows NT are trademarks of the Microsoft Corporation.
Copyright 1996-2013 Printing Communications Assoc., Inc. (PCAUSA)
Last modified: December 02, 2013