NDIS provides NdisGetDeviceProperty, which gives you access to the FDO that
NDIS creates on your behalf. But I don’t see any NDIS function for getting
the adapter context from the FDO. Anyone know of a way to do this?
– arlie
No, there’s no documented way of doing it AFAIK. You need to maintain the
AdapterContext yourself.
Best,
Calvin Guan (Windows DDK MVP)
NetXtreme Longhorn Miniport Prime
Broadcom Corp. www.broadcom.com
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Tuesday, August 09, 2005 2:45 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS adapter context from FDO
NDIS provides NdisGetDeviceProperty, which gives you access to the FDO that
NDIS creates on your behalf.? But I don’t see any NDIS function for getting
the adapter context from the FDO.? Anyone know of a way to do this?
?
– arlie
?
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
What is your exact task?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Arlie Davis
To: Windows System Software Devs Interest List
Sent: Wednesday, August 10, 2005 1:44 AM
Subject: [ntdev] NDIS adapter context from FDO
NDIS provides NdisGetDeviceProperty, which gives you access to the FDO that NDIS creates on your behalf. But I don’t see any NDIS function for getting the adapter context from the FDO. Anyone know of a way to do this?
– arlie
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Considering a design that simplifies an existing device driver. It uses
NdisMRegisterDevice to create separate device objects for each miniport
object (don’t ask). I’m considering eliminating that separate device
object, and instead processing IRP_MJ_DEVICE_CONTROL requests. To implement
those requests, though, I need access to the adapter context created in the
miniport Initialize function.
– arlie
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, August 09, 2005 6:51 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS adapter context from FDO
What is your exact task?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Arlie Davis mailto:xxxxx
To: Windows System Software Devs Interest mailto:xxxxx List
Sent: Wednesday, August 10, 2005 1:44 AM
Subject: [ntdev] NDIS adapter context from FDO
NDIS provides NdisGetDeviceProperty, which gives you access to the FDO that
NDIS creates on your behalf. But I don’t see any NDIS function for getting
the adapter context from the FDO. Anyone know of a way to do this?
– arlie
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx>
Are you planning to get rid of NDIS’s IOCTL dispatch routine?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Arlie Davis
To: Windows System Software Devs Interest List
Sent: Wednesday, August 10, 2005 3:19 AM
Subject: RE: [ntdev] NDIS adapter context from FDO
Considering a design that simplifies an existing device driver. It uses NdisMRegisterDevice to create separate device objects for each miniport object (don’t ask). I’m considering eliminating that separate device object, and instead processing IRP_MJ_DEVICE_CONTROL requests. To implement those requests, though, I need access to the adapter context created in the miniport Initialize function.
– arlie
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, August 09, 2005 6:51 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS adapter context from FDO
What is your exact task?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Arlie Davis
To: Windows System Software Devs Interest List
Sent: Wednesday, August 10, 2005 1:44 AM
Subject: [ntdev] NDIS adapter context from FDO
NDIS provides NdisGetDeviceProperty, which gives you access to the FDO that NDIS creates on your behalf. But I don’t see any NDIS function for getting the adapter context from the FDO. Anyone know of a way to do this?
– arlie
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Replacing it, watching for a few IOCTLs of my own, and then calling the NDIS
IOCTL handler.
– arlie
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, August 09, 2005 9:50 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS adapter context from FDO
Are you planning to get rid of NDIS’s IOCTL dispatch routine?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Arlie Davis mailto:xxxxx
To: Windows System Software Devs Interest mailto:xxxxx List
Sent: Wednesday, August 10, 2005 3:19 AM
Subject: RE: [ntdev] NDIS adapter context from FDO
Considering a design that simplifies an existing device driver. It uses
NdisMRegisterDevice to create separate device objects for each miniport
object (don’t ask). I’m considering eliminating that separate device
object, and instead processing IRP_MJ_DEVICE_CONTROL requests. To implement
those requests, though, I need access to the adapter context created in the
miniport Initialize function.
– arlie
_____
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, August 09, 2005 6:51 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS adapter context from FDO
What is your exact task?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Arlie Davis mailto:xxxxx
To: Windows System Software Devs Interest mailto:xxxxx List
Sent: Wednesday, August 10, 2005 1:44 AM
Subject: [ntdev] NDIS adapter context from FDO
NDIS provides NdisGetDeviceProperty, which gives you access to the FDO that
NDIS creates on your behalf. But I don’t see any NDIS function for getting
the adapter context from the FDO. Anyone know of a way to do this?
– arlie
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
Arlie,
If the required capability is to communicate some novel and proprietary
?controls? and ?status? on a per adapter basis from User Mode, perhaps WMI
would be a good choice? Mapping WMI control plane behavior to vendor
specific controls in NDIS miniports is straight forward and supported.
Alternatively, defining vendor private OIDs and using an agent such as
NDISUIO from User Mode to issue NdisRequest() calls to your driver is
another option that does not step into the world of trying to share
IRP_MJ_DEVICE_CONTROL dispatch with NDIS for a miniport driver.
The advantage in these operations, of course, is that both are dispatched
?thru? the NDIS IRP_MJ_DEVICE_CONTROL handler itself and so NDIS nicely
hands you the Adapter Context when you MiniportRequest handler is called.
To answer your OP however: It is possible to override the IRP_MJ_xxxx
handler, of course. It may be possible to build a ?map? between Adapter
Context and FDO by populating in MiniportInitialize() and clearing it out in
MiniportHalt(). When the IRP_MJ_xxx dispatch ?pre-handler? (the one you
would stick in front of the NDIS handler) needs to process your private
request(s), it could query the map to locate the Adapter Context. If you
don?t need to involve much of NDIS in satisfying the IOCTL, then it might be
safe. If you need to make calls ?into? NDIS using the MiniportHandle
associated with you Adapter Context, I would caution you to be sure that
routines you are calling can be called from ?outside? the Miniport
synchronization that NDIS provides.
I don?t recommend this approach of grabbing the dispatch handlers away from
NDIS. NDIS provides the private OID and WMI mapping mechanisms. The
Auxilary Device Object support added to NDIS (what the driver does now) is
more often used for ?driver? level control although far be it from anyone to
proscribe how it must be used. Per device control via private OIDs with
either WMI or NDISUIO are pretty straight forward and safe.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Tuesday, August 09, 2005 7:19 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS adapter context from FDO
Considering a design that simplifies an existing device driver. It uses
NdisMRegisterDevice to create separate device objects for each miniport
object (don’t ask). I’m considering eliminating that separate device
object, and instead processing IRP_MJ_DEVICE_CONTROL requests. To implement
those requests, though, I need access to the adapter context created in the
miniport Initialize function.
– arlie
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, August 09, 2005 6:51 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS adapter context from FDO
What is your exact task?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Arlie mailto:xxxxx Davis
To: Windows System mailto:xxxxx Software Devs Interest List
Sent: Wednesday, August 10, 2005 1:44 AM
Subject: [ntdev] NDIS adapter context from FDO
NDIS provides NdisGetDeviceProperty, which gives you access to the FDO that
NDIS creates on your behalf. But I don’t see any NDIS function for getting
the adapter context from the FDO. Anyone know of a way to do this?
– arlie
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx>
> If you need to make calls ‘into’ NDIS using the MiniportHandle
associated with you Adapter Context, I would caution you to be
sure that routines you are calling can be called from ‘outside’ the
Miniport synchronization that NDIS provides.
Ahhhhh, that is a key aspect I was missing, and in retrospect, should have
been obvious. My approach is flawed.
The design is (yet another) virtual NDIS device driver. I was considering
modifying the existing design to use IOCTLs implemented directly on the NDIS
FDO for this, in order to simplify the design, but this is apparently
untenable.
– arlie
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Wednesday, August 10, 2005 11:02 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS adapter context from FDO
Arlie,
If the required capability is to communicate some novel and proprietary
‘controls’ and ‘status’ on a per adapter basis from User Mode, perhaps WMI
would be a good choice? Mapping WMI control plane behavior to vendor
specific controls in NDIS miniports is straight forward and supported.
Alternatively, defining vendor private OIDs and using an agent such as
NDISUIO from User Mode to issue NdisRequest() calls to your driver is
another option that does not step into the world of trying to share
IRP_MJ_DEVICE_CONTROL dispatch with NDIS for a miniport driver.
The advantage in these operations, of course, is that both are dispatched
‘thru’ the NDIS IRP_MJ_DEVICE_CONTROL handler itself and so NDIS nicely
hands you the Adapter Context when you MiniportRequest handler is called.
To answer your OP however: It is possible to override the IRP_MJ_xxxx
handler, of course. It may be possible to build a ‘map’ between Adapter
Context and FDO by populating in MiniportInitialize() and clearing it out in
MiniportHalt(). When the IRP_MJ_xxx dispatch ‘pre-handler’ (the one you
would stick in front of the NDIS handler) needs to process your private
request(s), it could query the map to locate the Adapter Context. If you
don’t need to involve much of NDIS in satisfying the IOCTL, then it might be
safe. If you need to make calls ‘into’ NDIS using the MiniportHandle
associated with you Adapter Context, I would caution you to be sure that
routines you are calling can be called from ‘outside’ the Miniport
synchronization that NDIS provides.
I don’t recommend this approach of grabbing the dispatch handlers away from
NDIS. NDIS provides the private OID and WMI mapping mechanisms. The
Auxilary Device Object support added to NDIS (what the driver does now) is
more often used for ‘driver’ level control although far be it from anyone to
proscribe how it must be used. Per device control via private OIDs with
either WMI or NDISUIO are pretty straight forward and safe.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development