NdisReinitializePacket
Does Not Completely Reinitialize
A Packet

Symptoms

NdisReinitializePacket does not reinitialize some fields in the NDIS_PACKET. The fields of interest is the unnamed union containing these fields:

Failure to reinitialize these fields can cause unpredictable faults in drivers (particularly NDIS Intermediate drivers) that use a common NDIS packet pool for both Miniport and Protocol operations on an adapter.

The problem occurs when a packet that was previously used for a call to NdisSend is recycled and then re-used in a call to NdisMIndicateReceive.

The most serious fault that can be caused by failing to reinitialize these fields is that a NDIS IM driver's call to NdisMIndicateReceive may fail unexpectedly within NDIS when operating on some adapters (but not all adapters).

Cause

The fact that these fields are not reinitialized by NdisReinitializePacket is not a problem for most uses of NDIS_PACKETs by NDIS Protocols, NDIS Miniports or NDIS full-MAC drivers. In fact, it may not be desirable to perform the additional reinitialization steps described below at all for these types of drivers.

However, the fact that these fields are not reinitialized by NdisReinitializePacket can cause unpredictable faults in an NDIS Intermediate (IM) driver that uses a common NDIS packet pool with packet recycling for both its Miniport-edge and Protocol-edge.

Here is s step-by-step description of the problem:

1. The problem is setup when the NDIS IM driver allocates a NDIS packet, uses it for a successful call to NdisSend and then queues the packet for re-use. At this point some of the MiniportReserved, MiniportReservedEx or MacReserved fields may contain data that was temporarily saved there by the lower-level driver and the WrapperReserved or WrapperReservedEx fileds may contain data that was temporarily saved there by the NDIS wrapper.
    
2. If the driver now reallocates a packet that was previously used for an NdisSend operation (as described in Step 1, above) and then calls NdisReinitializePacket, then the various reserved fields are not reinitialized.
    
   If the driver uses the reallocated NDIS packet for a call to NdisMIndicateReceive, then the leftover uninitialized fields from the previous call to NdisSend are interpreted entirely differently (and incorrectly) by the NDIS wrapper.

On Windows 2000 the uninitialized fields may lead to a fault in efilter.c:

Failure: PNDIS_REFERENCE_FROM_NDIS_PACKET(Packet)->RefCount==0

The problem may manifest itself differently, perhaps because of differing contents of the uninitialized fields. Other observed faults include:

Miniport X MSR LastExceptionFromIp

Without a debugger the behavior observed in this case is a BSOD and system reboot.

The problem is made difficult to debug because some NDIS Miniport drivers do not elect to use the MiniportReserved or MiniportReservedEx fields in the unnamed union or may use them differently. The fault does not occur on these drivers.

Possible Fixes

Zero MacReserved Field After Calling NdisReinitializePacket

This problem can be fixed by simply zeroing the aforementioned unnamed union after calling NdisReinitializePacket when reallocating a previously used NDIS packet.

The simplest way is to zero the 32-byte field named MacReserved. Zeroing this field should zero the unnamed union in its entirety.

Zero MacReserved Field When Send Completes

This problem can also be fixed by simply zeroing the aforementioned unnamed union after each send completes. That is, zero the field before recycling the NDIS packet.

It has been mentioned that this behavior has been fixed in Windows XP by having NDIS zero the necessary fields as it completes each send operation.
 
Such fix for Windows XP offers little joy for those who must support other versions of Windows. In fact, it makes development more complex. It might have been better to have the bug exhibit itself consistently instead of having it occur on some platforms but not others.

Save And Restore MiniportReservedEx Field

Stephan Wolf provided some additional insight and another suggestion:

"IM drivers that use the same NDIS_PACKETs for both send and receive operations should save the value of the 'MiniportReservedEx' field before the send operation and restore it in their send complete handler"

Click here to read the complete text of Stephan's comment.

Use Separate NDIS Packet Pools For Protocol And Miniport Operations

Using separate NDIS packet pools for protocol and miniport operations would also seem to be an approach that would eliminate this problem.

This solution is recommended by Microsoft. They apparently identified this problem in August, 1999 but forgot to document it.

However, this solution would complicate the design of most practical NDIS IM drivers.

Do Not Use NdisMIndicateReceive To Indicate Receive Packets

This particular fault can, of course, be eliminated by eliminating the call to NdisMIndicateReceive. One could use explicit calls to NdisMEthIndicateReceive, etc.

However, this solution would also complicate the design of most practical NDIS IM drivers.

Status

Comments

Please click the following link to send e-mail relating to this PCAUSA Knowledge Base topic:

<Send Mail To KB05050101 Technical Contact>

PCAUSA Home · Privacy Statement · Products · Ordering · Support · Utilities · Resources
Mailing Lists  · PCAUSA Newsletter · PCAUSA Discussion List
 

Rawether for Windows and WinDis 32 are trademarks of Printing Communications Assoc., Inc. (PCAUSA)
Microsoft, MS, Windows, 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.
Send mail to webmaster@pcausa.com with questions or comments about this web site.
Copyright © 1996-2008 Printing Communications Assoc., Inc. (PCAUSA)
Last modified: December 31, 2007