Hi All,
I would like to know the best way to notify an event to application from NDIS 5.x miniport driver. The notification should carry data along with it. (similar to data blobs in media specific indication in NDIS 6.x)
Regards,
Vinay
Hi All,
I would like to know the best way to notify an event to application from NDIS 5.x miniport driver. The notification should carry data along with it. (similar to data blobs in media specific indication in NDIS 6.x)
Regards,
Vinay
Pending OID request? NdisMRegisterDevice?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Hi All,
>
> I would like to know the best way to notify an event to application from NDIS 5.x miniport driver. The notification should carry data along with it. (similar to data blobs in media specific indication in NDIS 6.x)
>
> Regards,
> Vinay
>
I recommend you research two alternatives depending on the ‘frequency’ of this event, whether or not your system can afford to miss events, and the amount and timeliness of the data.
Pend in I/O request (IOCTL) to an auxilary device created by the miniport for such purposes. Complete the request when the event happens and place the data for the event in the output buffer.
Use WMI mapping of NDIS status notifications to ‘publish’ the event to WMI and subscribe to the WMI event from usermode. See OID_GEN_SUPPORTED_GUIDS in the NDIS docs for more information and a starting point.
Good Luck,
Dave Cattley
Date: Thu, 17 Feb 2011 05:47:05 -0500
From: xxxxx@gmail.com
To: xxxxx@lists.osr.com
Subject: [ntdev] event notification from NDIS 5.x miniport to application/service (WinXp)Hi All,
I would like to know the best way to notify an event to application from NDIS 5.x miniport driver. The notification should carry data along with it. (similar to data blobs in media specific indication in NDIS 6.x)
Regards,
Vinay
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Thank you Maxim S. Shatskih and Dave Cattley, for your inputs.
Will investigate on the alternates provided.
Any pointer/info on the alternates would be more helpful.
Regards,
Vinay
WMI events are really simple to use in your driver, once you get the hang of WMI. All you have to do is indicate up a status indication, and NDIS takes care of translating it to WMI and dispatching it to usermode. Clients are also really easy to create in script (PowerShell in particular!). C# also has a good API, I think. It is a little tricker to create a client using the C++ or C COM API, but there’s enough sample code out there, and it can be done. Furthermore, once you have one event working, it’s really easy to add more kinds of events, and WMI automatically scales from 1 to many listening clients.
The hard part of WMI is getting your project bootstrapped. There’s almost no sample code on how to expose WMI from an NDIS driver, and even less so on how to emit events. So it can be really tough to get started. If you do go this route and you post an email here with “NDIS NDIS WMI WMI” in the subject line, I’ll hopefully notice it and do my best to help out with any specific questions you run into. You’ll also do well do dig up a copy of the e100 sample driver (which has been retired from current versions of the WDK because of its design flaws, but its demonstration of WMI integration is fine).
IOCTLs are a very tried-and-true technique. Everybody knows how IOCTLs work, anybody can answer your questions, and there’s buckets of sample code and tutorials out there. However, your final product will have a few more lines of code in kernel mode, and there are many more opportunities to accidentally introduce races, and security vulnerabilities. Furthermore, if you ever want to go from 1 client to N clients, you’ll have to do a bit of extra work in kernel mode.
A pending OID request won’t work, because it would block all other OIDs until it completes.
Finally, if you happen to require absolute guarantees of event delivery even when the system is severely resource constrained, you cannot use WMI. There are a couple places in NDIS where, if a pool allocation fails, we will silently drop the event without informing you. With IOCTLs, it’s possible to pre-allocate all the memory up-front, and have nofail event delivery. (This requires a LOT of careful design, and most folks don’t need it, however. There are VERY few useful things your usermode service could do with the event if the system can’t allocate any pool.)
So in summary, I think WMI would be a little more elegant in the end, and there’s a fantastic scripting story with WMI, but it’s harder to get started. You’ll almost certainly have working code sooner if you go the IOCTL route instead. Most miniports choose IOCTLs.