will MiniportReservedEx remain after NdisMIndicateReceivePacket -> ReturnPacket

NTDEV
1

I use the MiniportReservedEx fields to store information in my
NDIS_PACKET before caling NdiMIndicateReceivePacket, and then use that
information in my MiniportReturnPacket to assist with the packet
cleanup.

This works perfectly under NDIS 5.1 but fails spectacularly under NDIS
5.0 (windows 2000) - the last 4 bytes of MiniportReservedEx are cleared.

Am I doing the right thing in storing miniport information in
MiniportReservedEx before calling NdiMIndicateReceivePacket? From the
literature it would seem that those fields are for use only by the
miniport, but maybe it just means that NDIS lets me stomp all over them
while I own the packet.

If not, where can I a VOID *'s worth of context information in my
packet?

Thanks

James

2

“James Harper” wrote in message
news:xxxxx@ntdev…
> I use the MiniportReservedEx fields to store information in my
> NDIS_PACKET before caling NdiMIndicateReceivePacket, and then use that
> information in my MiniportReturnPacket to assist with the packet
> cleanup.
>
> This works perfectly under NDIS 5.1 but fails spectacularly under NDIS
> 5.0 (windows 2000) - the last 4 bytes of MiniportReservedEx are cleared.
>
> Am I doing the right thing in storing miniport information in
> MiniportReservedEx before calling NdiMIndicateReceivePacket? From the
> literature it would seem that those fields are for use only by the
> miniport, but maybe it just means that NDIS lets me stomp all over them
> while I own the packet.
>
> If not, where can I a VOID *'s worth of context information in my
> packet?
>
> Thanks
>
> James

If you need only one void *'s worth, maybe you can just use other
element of MiniportReservedEx, not the last one?

This field is union’ed, and who remembers now how win2k used them.
It could even depend on a service pack.
– pa

3

When you allocate your packet pool do you specify at least
PROTOCOL_RESERVED_SIZE_IN_PACKET as ProtocolReservedLength? Protocols expect
this minimum space for their own work. If you haven’t done this, then
protocols can accidently overwrite the MiniportReserved area.

See the NDIS_PACKET structure.

Hope this helps.

Thomas F. Divine
http://www.pcausa.com

From: “James Harper”
Sent: Wednesday, October 20, 2010 7:10 AM
To: “Windows System Software Devs Interest List”
Subject: [ntdev] will MiniportReservedEx remain after
NdisMIndicateReceivePacket -> ReturnPacket

> I use the MiniportReservedEx fields to store information in my
> NDIS_PACKET before caling NdiMIndicateReceivePacket, and then use that
> information in my MiniportReturnPacket to assist with the packet
> cleanup.
>
> This works perfectly under NDIS 5.1 but fails spectacularly under NDIS
> 5.0 (windows 2000) - the last 4 bytes of MiniportReservedEx are cleared.
>
> Am I doing the right thing in storing miniport information in
> MiniportReservedEx before calling NdiMIndicateReceivePacket? From the
> literature it would seem that those fields are for use only by the
> miniport, but maybe it just means that NDIS lets me stomp all over them
> while I own the packet.
>
> If not, where can I a VOID *'s worth of context information in my
> packet?
>
> Thanks
>
> James
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

4

>

When you allocate your packet pool do you specify at least
PROTOCOL_RESERVED_SIZE_IN_PACKET as ProtocolReservedLength? Protocols
expect
this minimum space for their own work. If you haven’t done this, then
protocols can accidently overwrite the MiniportReserved area.

See the NDIS_PACKET structure.

Hope this helps.

I specify PROTOCOL_RESERVED_SIZE_IN_PACKET as per the docs. The protocol
area comes after the MiniportReservedEx area anyway so I’d be surprised
if that’s really the cause.

James

5

Ok. Sounds good.

Is there a chance that something above you is returning a packet that you
did not own? (Crap happens…). Perhaps add sanity check on the pool handle.
On NDIS 5.0 you can add this macro:

// Not Defined for Windows 2000
#define NdisGetPoolFromPacket(_p) \
(_p)->Private.Pool

Thomas F. Divine

From: “James Harper”
Sent: Wednesday, October 20, 2010 8:27 AM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] will MiniportReservedEx remain after
NdisMIndicateReceivePacket -> ReturnPacket

>>
>> When you allocate your packet pool do you specify at least
>> PROTOCOL_RESERVED_SIZE_IN_PACKET as ProtocolReservedLength? Protocols
> expect
>> this minimum space for their own work. If you haven’t done this, then
>> protocols can accidently overwrite the MiniportReserved area.
>>
>> See the NDIS_PACKET structure.
>>
>> Hope this helps.
>>
>
> I specify PROTOCOL_RESERVED_SIZE_IN_PACKET as per the docs. The protocol
> area comes after the MiniportReservedEx area anyway so I’d be surprised
> if that’s really the cause.
>
> James
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

6

Ok. Sounds good.

Is there a chance that something above you is returning a packet that you
did not own? (Crap happens…). Perhaps add sanity check on the pool handle.
On NDIS 5.0 you can add this macro:

// Not Defined for Windows 2000
#define NdisGetPoolFromPacket(_p) \
(_p)->Private.Pool

Thomas F. Divine

From: “James Harper”
Sent: Wednesday, October 20, 2010 8:27 AM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] will MiniportReservedEx remain after
NdisMIndicateReceivePacket -> ReturnPacket

>>
>> When you allocate your packet pool do you specify at least
>> PROTOCOL_RESERVED_SIZE_IN_PACKET as ProtocolReservedLength? Protocols
> expect
>> this minimum space for their own work. If you haven’t done this, then
>> protocols can accidently overwrite the MiniportReserved area.
>>
>> See the NDIS_PACKET structure.
>>
>> Hope this helps.
>>
>
> I specify PROTOCOL_RESERVED_SIZE_IN_PACKET as per the docs. The protocol
> area comes after the MiniportReservedEx area anyway so I’d be surprised
> if that’s really the cause.
>
> James
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

7

>

“James Harper” wrote in message
> news:xxxxx@ntdev…
> > I use the MiniportReservedEx fields to store information in my
> > NDIS_PACKET before caling NdiMIndicateReceivePacket, and then use
that
> > information in my MiniportReturnPacket to assist with the packet
> > cleanup.
> >
> > This works perfectly under NDIS 5.1 but fails spectacularly under
NDIS
> > 5.0 (windows 2000) - the last 4 bytes of MiniportReservedEx are
cleared.
> >
> > Am I doing the right thing in storing miniport information in
> > MiniportReservedEx before calling NdiMIndicateReceivePacket? From
the
> > literature it would seem that those fields are for use only by the
> > miniport, but maybe it just means that NDIS lets me stomp all over
them
> > while I own the packet.
> >
> > If not, where can I a VOID *'s worth of context information in my
> > packet?
> >
> > Thanks
> >
> > James
>
> If you need only one void *'s worth, maybe you can just use other
> element of MiniportReservedEx, not the last one?
>
> This field is union’ed, and who remembers now how win2k used them.
> It could even depend on a service pack.

Thanks for the hint. All working now… hope I haven’t broken the other
platforms!

I was using the first two PVOID’s of space to hold a LIST_ENTRY to keep
track of the packets while I got them off the comms ring from Xen before
indicating them to NDIS, and the last one to store a pointer to a buffer
that held the per-packet copy of the header (a 64K GSO packet needs to
be split up… I can use each 4K buffer from Xen across multiple NDIS
packets for the payload but each packet needs its own TCP header
synthesized etc). That pointer was what was getting trashed and putting
it first and the LIST_ENTRY last has resolved the problem.

FWIW, the last bit of MiniportReservedEx was getting trashed in
ethFilterDprIndicateReceivePacket according to windbg…

Thanks again.

James

8

So the advice to future developers who encounter this problem on a NDIS 5.0
miniport would be to stick to using the MiniportReserved area only and
assume that the extra fields in MiniportReservedEx could be clobbered.

Glad you tamed it!

Thomas F. Divine
http://www.pcausa.com

From: “James Harper”
Sent: Wednesday, October 20, 2010 7:10 AM
To: “Windows System Software Devs Interest List”
Subject: [ntdev] will MiniportReservedEx remain after
NdisMIndicateReceivePacket -> ReturnPacket

> I use the MiniportReservedEx fields to store information in my
> NDIS_PACKET before caling NdiMIndicateReceivePacket, and then use that
> information in my MiniportReturnPacket to assist with the packet
> cleanup.
>
> This works perfectly under NDIS 5.1 but fails spectacularly under NDIS
> 5.0 (windows 2000) - the last 4 bytes of MiniportReservedEx are cleared.
>
> Am I doing the right thing in storing miniport information in
> MiniportReservedEx before calling NdiMIndicateReceivePacket? From the
> literature it would seem that those fields are for use only by the
> miniport, but maybe it just means that NDIS lets me stomp all over them
> while I own the packet.
>
> If not, where can I a VOID *'s worth of context information in my
> packet?
>
> Thanks
>
> James
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer