The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
The question I really need answered, in a nutshell, is what is Microsoft's sanctioned way to write OID data from user mode IoT, and where is it documented?
Here's the background:
A while back the topic of sending OID data came up in this thread:
I'm porting some software from Windows CE to Windows 10 IoT Core, and there's a user-mode component that needs to be able to send OID data down the NDIS stack. There seem to be two general approaches to this:
In the original thread, Doron Holan stated, "there is no WMI on IoT." If true, that takes option 1 off the table.
Option 2 is a little strange in that I've only seen this documented for Windows CE. There is a driver named ndisuio.sys on Windows 10 desktop as well as Windows 10 IoT Core, but I have found no documentation on the web nor supporting headers in the SDK.
There's a ndisprot sample at: https://github.com/Microsoft/Windows-driver-samples/tree/master/network/ndis/ndisprot/6x
Thinking that ndisuio.sys might be very nearly the same, I attempted to use ndisuio.sys with the IOCTLs and structures defined in that project, but with no success. From browsing the binary in a hex editor, I guessed that I might be able to call CreateFile() with either \\.\WwanProt or \\.\NdisUio as the device name; the former succeeds, the latter fails with a file share error code regardless of the file share parameters passed in. Beyond that point, though, I can't get an open via DeviceIoControl()/IOCTL_NDISUIO_OPEN_DEVICE to work when the adapter GUID is passed in (I get a general failure error back).
But let's step back a moment; this is silly. Reverse engineering Windows to find undocumented ways to do things is no path towards a stable application.
There is a third path available to me, I think, and that is to take the ndisprot sample and create my own parallel of the ndisuio.sys driver. It seems like a lot of messing around to do something simple that the OS supports internally, but it's at least a path that isn't explicitly unsupported.
My apologies if I've overlooked something obvious.
It looks like you're new here. If you want to get involved, click one of these buttons!
|Upcoming OSR Seminars|
|OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!||Kernel Debugging||30 Mar 2020||OSR Seminar Space|
|Developing Minifilters||15 Jun 2020||LIVE ONLINE|
|Writing WDF Drivers||22 June 2020||LIVE ONLINE|
|Internals & Software Drivers||28 Sept 2020||Dulles, VA|