The client driver exposes a device interface that applications can use to obtain the device's file handle. The most common approach has been to implement a device driver, (termed as a USB client driver in this documentation set) and provide an installation package that installs the driver as the function driver in the device stack above the Microsoft-provided USB driver stack.

If a particular feature is not supported by KMDF, write a hybrid driver that calls WDM routines.If class driver, WinUSB, or UMDF solutions are not options that work for you, write a KMDF-based client driver.If the device needs to be accessed by concurrent applications and your device does not have isochronous endpoints, write a UMDF-based client driver.If your device does not have a Microsoft-provided class driver, and the device is accessed by a single application, then load WinUSB as the function driver.If your device belongs to a USB device class for which Windows includes an inbox driver, you don’t need to write a driver.The following list summarizes the choices discussed in this topic:

To choose the best mechanism for accessing a USB device, start with the simplest approach and move to more complex solutions only if it is necessary. USB device manufacturers must often provide a way for applications to access the device's features. This topic provides guidelines for choosing the best driver model for developing a USB client driver that acts as the device's function driver. Choosing a driver model for developing a USB client driver

Microsoft winusb 2.0