Part 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.

	Part 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.
	Part 3 - Programmatically Installing NDIS Protocol Drivers - (November 23, 2006) Discusses how to programmatically install a NDIS protocol driver using the INetCfg API.

Overview

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

	NDIS 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.
	NDIS 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.

IOCTL_NDIS_QUERY_GLOBAL_STATS

NDIS Query and WMI