Best Of

You're using KMDF (which is the correct thing to do). KMDF handles the device context for you. It's wrapped up in the WDFDEVICE.

What did you do that got ERROR_INVALID_FUNCTION? I may be wrong, but it's possible you have a misunderstanding. Remember that DeviceIoControl does not return an error code. It returns 1 for success, 0 for failure. If it returns failure, THEN you call GetLastError() to find the error code. So, if you get a 1 back from DeviceIoControl, it means everything worked fine, NOT that you had ERROR_INVALID_FUNCTION.

What is the device context? The device context holds all of the global data that a driver needs in order to service its hardware. Remember that each driver can support multiple pieces of hardware. If you should happen to have 5 identical network cards, for instance, the network driver will only be loaded once. But as each device comes on line, it gets a new device context. The driver will store the register addresses and all the current state in the device context. So, when an ioctl comes in, the ioctl handler is passed the corresponding device context, so it knows which device it is working on.

The debate of C vs C++ in the kernel is a long one. For a long time, C++ was officially "discouraged", even though several of the device classes always used it. Streaming drivers have ALWAYS been in C++, for example. These days, C++ is officially supported. KMDF itself is actually written in C++, but they expose a C API to support all of the C programmers. You should use whatever language makes you the most comfortable. I always use C++ for my drivers.

I suspect you want to use a Service SID. Look up service isolation... you can lock-down your device object and only allow access to the service with the specific SID.

Peter

You don't need to be multi-threaded to do this properly

Strictly speaking, absolutely correct. I was a bit quick to conflate what I think is the best way to do this with what you absolutely MUST do.

They key point here is that you'll need to have multiple IRPs in progress simultaneously, so that your driver will always have one available when it needs to notify user-mode.

I'd do that with a multi-threaded app using completion ports, but... that's just one way of doing it. Mr. Roberts' pseudo-code will work just fine as well.

Peter

Because of there is only one IRP in queue.

Are you seriously suggesting that you used RemoveHeadList without checking whether the list was empty first? And when you got a BSOD you seriously could not figure out how to fix that? YOU have to decide how you will handle this case. Presumably, if there is no one to notify, you will just return without doing anything, but it gives me grave concerns about your programming ability that you couldn't figure this out. This is just basic defensive programming.

You don't need to be multithreaded to do this properly. All you need is 3 or 4 OVERLAPPED structures, presumably in an array. Each one will need its own event. You can then store the event handles in another array. Then, in your while loop, you use "WaitForMultipleObjects" and pass it the array. The return value will tell you which request completed. Approximately like this:

OVERLAPPED olap[4];
HANDLE events[4];
for( int i = 0; i < 4; i++ ) {
    events[i] = CreateEvent( ... );
    ZeroMemory( &olap[i], sizeof(OVERLAPPED) );
    olap[i].event = events[i];
    DeviceIoControl( ... , &olap[i] );
}
while( 1 ) {
    result = WaitForMultipleObjects( 4, events, ... );
    if( result is not an error ) {
        int which = result - WAIT_OBJECT_0;
        GetOverlappedResult( hDriver, &olap[which], &nRead, TRUE );
        ZeroMemory( &olap[which], sizeof(OVERLAPPED));
        olap[which].event = events[which];
        DeviceIoControl( ..., &olap[which] );
    }
}

And, by the way, you are supposed to clean out the OVERLAPPED structure every time before you use one, by zeroing out everything except the event, as I did above.

You cannot install an unsigned driver on Windows 10 unless the kernel debugger is attached.

@johnhoulding You're still missing the point, Mr. Houlding.

You don't want to share ANY events between your driver and your user-mode app. You don't want to use any global memory.

Do it this way:

1) User allocates a buffer that is, for example, 4K (just call malloc)
2) User sends IOCTL (as I said before, you'll want to send the IOCTL asynchronously) with the pointer to the buffer that was just allocated above as the OutBuffer in the IOCTL. Make sure the driver defines the IOCTL using the CTL_CODE macro, specifying METHOD_BUFFERED. In practice, you probably want the app to have multiple of these IOCTLs in progress at the same time so that the driver always has one on its queue when it needs it (see the steps below).
3) Driver gets this IOCTL, calls IoMarkIrpPending, and puts it on a list. Create a listhead for this list in your Device Extension (the data structure to use is LIST_ENTRY). You can use InsertTailList and queue Irp->Tail.Overlay.ListEntry for the list.
4) NEXT... your driver gets called back in its Create Process Notify callback. From within that callback, the driver removes an IRP from the list (that was previously put on the list in step 3, above... use RemoteHeadList). Copy the name/path or whatever you want to the OutBuffer of the IOCTL IRP that you just removed from the list. You get the pointer to the OutBuffer from the IRP, in the Irp->AssociatedIrp.SystemBuffer field. Just memcpy the data. Remember how many bytes you copied!
5) Complete the IOCTL IRP: Fill in Irp->IoStatus.Status with STATUS_SUCCESS and Irp->IoStatus.Information with the number of data bytes you copied to the IOCTL OutBuffer... call IoCompleteRequest. Again... all of the things in Steps 4 and 5 are done in your notification callback.
6) Back in your user-mode app, the app now sees the IOCTL is complete (perhaps the app has called GetOverlappedResult or perhaps you're using a completion port) and now the data you copied to the OutBuffer in your driver's notification callback is available to the app in his OutBuffer.
7) When the user-mode app finishes processing the returned data, it sends the IOCTL back to the driver to use again.

Don't use shared events. Don't use shared/global memory.

I hope that helps,

Peter