-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of yushang
Sent: Thursday, July 08, 2010 7:37 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] opaque _NDIS_MINIPORT_BLOCK?
Hi Dear All,
I’m debuging a miniport dirver , found it seems _NDIS_MINIPORT_BLOCK
is not opaque to driver , because I can found a call like this
2010/7/9 Tim Roberts : > yushang wrote: >> Hi Dear All, >> I’m debuging a miniport dirver , found it seems _NDIS_MINIPORT_BLOCK >> is not opaque to driver , because I can found a call like this > > NDIS_MINIPORT_BLOCK is not opaque. The structure definition present in > ndis.h, plain as day. > >> I guess NDIS has inlined some library call . Is it possible ? Could >> anyone explain this for me ? > > Explain what? > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > 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 >
“Tim Roberts” wrote in message news:xxxxx@ntdev… > yushang wrote: >> Hi Dear All, >> I’m debuging a miniport dirver , found it seems _NDIS_MINIPORT_BLOCK >> is not opaque to driver , because I can found a call like this > > NDIS_MINIPORT_BLOCK is not opaque. The structure definition present in > ndis.h, plain as day. >
Internally ndis.sys may use its own structure, not same as in the public ndis.h. At least, some parts of it.
To expand on what Pavel said – NDIS does indeed use a different miniport block internally. (This is intentional). The upshot is that you must never reach into the miniport block directly, since looking at NDIS.H doesn’t tell you how the NDIS.SYS implementation sees those fields. Instead, use documented macros (like NdisMEthIndicateReceive) and pretend that NDIS_MINIPORT_BLOCK doesn’t exist. Or better yet, move to NDIS6 and the NDIS_MINIPORT_BLOCK will be gone; all macros are replaced with proper exported functions.
I am harping on this issue because some of us just recently spent a lot of time diagnosing a 3rd party product that decided to take the liberty of reaching directly into (the non-ABI portion of) NDIS’s miniport block and twiddling some of the data there. The 3rd party component causes NDIS to bugcheck in Win7 SP1, and we naturally get to clean up that mess…
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Thursday, July 08, 2010 8:38 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] opaque _NDIS_MINIPORT_BLOCK?
“Tim Roberts” wrote in message news:xxxxx@ntdev… > yushang wrote: >> Hi Dear All, >> I’m debuging a miniport dirver , found it seems _NDIS_MINIPORT_BLOCK >> is not opaque to driver , because I can found a call like this > > NDIS_MINIPORT_BLOCK is not opaque. The structure definition present > in ndis.h, plain as day. >
Internally ndis.sys may use its own structure, not same as in the public ndis.h. At least, some parts of it.