Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
This topic describes how a User-Mode Driver Framework (UMDF) driver supports kernel-mode clients, starting in UMDF version 2.
A kernel-mode client is a kernel-mode driver that sends I/O requests to your UMDF driver. The kernel-mode driver might be above the UMDF driver, in the same device stack, or it might be in a different device stack.
The kernel-mode driver can forward I/O requests that it has received from a user-mode application, or can create new I/O requests and send them to the user-mode driver.
How to support kernel-mode clients in a UMDF driver
To enable a UMDF driver's support for kernel-mode clients, the INF file of the UMDF driver must include a UmdfKernelModeClientPolicy directive in its INF DDInstall.WDF section.
The framework provides two methods that are useful to drivers that support kernel-mode clients. A driver can call the WdfRequestGetRequestorMode method to determine whether an I/O request came from kernel mode or user mode. If the I/O request came from user mode, the driver can call WdfRequestIsFromUserModeDriver to determine whether the request came from an application or another user-mode driver.
Restrictions on kernel-mode drivers
A UMDF driver can process I/O requests from a kernel-mode driver only if the kernel-mode driver meets the following requirements:
The kernel-mode driver must be running at IRQL = PASSIVE_LEVEL when it sends the I/O request.
Unless the driver has set the UmdfFileObjectPolicy INF directive to AllowNullAndUnknownFileObjects, each I/O request that a kernel-mode driver sends to a user-mode driver must have an associated file object. The framework must have previously been notified that the I/O manager created the file object. (Such notification causes the framework to call the user-mode driver's EvtDeviceFileCreate callback function, but that callback function is optional.)
The I/O request cannot contain an IRP_MJ_INTERNAL_DEVICE_CONTROL function code.
The I/O request's buffers must not contain pointers to additional information, because the user-mode driver cannot dereference the pointers.
If the I/O request contains an I/O control code that specifies the "neither" buffer access method, the kernel-mode driver must send the I/O request in the process context of the application that created the I/O request. For more information about how to support the "neither" method in a UMDF driver, see Managing Buffer Access Methods in UMDF Drivers.
The UMDF driver might modify an I/O request's output data, in user mode. Therefore, the kernel-mode driver must validate any output data that it receives from the user-mode driver.
The kernel-mode client should typically validate the Information value that a UMDF driver passes to WdfRequestCompleteWithInformation. If the client is a KMDF driver, it can call WdfRequestGetCompletionParams to obtain this information in an IO_STATUS_BLOCK structure.
Typically, the framework does not validate the information value that a UMDF driver passes to WdfRequestCompleteWithInformation. (This parameter usually specifies the number of transferred bytes.) The framework validates the information value only for output buffers, and only for the buffered I/O data access method. (For example, the framework verifies that the number of transferred bytes does not exceed the output buffer size of a read operation, if the access method is buffered I/O.)