Windows User-Mode Driver Framework (UMDF) ..

Windows Driver Frameworks (WDF) is a set of libraries that you can use to develop device drivers that are interoperable with Windows. WDF is comprised of Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF). UMDF is a framework for the creation of user-mode drivers. Like Kernel-Mode Driver Framework (KMDF), UMDF provides an abstraction layer from WDM, handling much of the Plug and Play (PnP) and power management functionality, and allowing the driver to opt in for specific functionality and event handling.

Writing a driver using UMDF version 1.x requires using the COM programming model to write C++ code. While UMDF version 1 is based on the same conceptual driver programming model as KMDF, UMDF 1 implements the model with different components, device driver interfaces (DDIs), and data structures. In contrast, starting in UMDF version 2, you can write a UMDF driver in the C programming language that calls many of the methods that are available to KMDF drivers. All of the interfaces that are shared between UMDF version 2 and KMDF have the same names, parameters, and structure definitions. If your driver uses only shared functionality, or uses conditional macros around calls that are only supported in one framework, you can write a single driver that you can compile with either UMDF or KMDF.

UMDF drivers abstract hardware functionality, run in the user-mode environment, and can access various services. UMDF drivers operate as part of a stack of drivers that manage a device. File system drivers, display drivers, and print drivers cannot be UMDF drivers. 

A UMDF driver interacts with the following system-supplied components:

Driver host process:
The driver host process loads vendor-supplied UMDF drivers and framework DLLs, provides an execution environment for user-mode drivers, and routes messages between drivers in a user-mode stack. The driver host process (Wudfhost.exe) is a child process of the driver manager service. Wudfhost.exe usually runs in the LocalService account, which has minimum privileges on the local computer. An instance of Wudfhost.exe loads one or more UMDF driver DLLs, in addition to the framework DLLs. The driver host process provides a runtime environment that handles interprocess communication (IPC) between the driver manager and the reflector, as well as I/O dispatching, driver loading, driver layering, and thread pool management.

Driver manager:
The driver manager is a Windows service that manages all instances of the Wudfhost driver host process. The driver manager launches and tracks information about each driver host process. Each host is a child process of the driver manager. Only one driver manager exists per system. The driver manager starts during installation of the first UMDF device and runs on the system thereafter.

Reflector:
The reflector is a kernel-mode driver that permits an application and a driver host process (and user-mode device stacks) to communicate. The reflector creates a separate device object for each device instance and handles Plug and Play (PnP) and power I/O requests associated with each device instance. All communication between the application and the driver host process happens through the reflector.

If your driver requires one of these features, you must write a KMDF driver:
While UMDF version 2.0 offers a significant subset of functionality that was previously available only to KMDF drivers, the following features are available only to KMDF drivers. 

• Direct memory access (DMA)
• Bus enumeration
• Functional power states (limited support is available in UMDF)
• Access to WDM objects
• Neither Buffered Nor Direct I/O
• Internal device control requests (IOCTLs)
• Remove lock opt-in for I/O requests

Advantages of Writing UMDF Drivers:

• UMDF drivers contribute to greater operating system stability because they have access only to the address space of the process in which they run.
• Because UMDF drivers run under the LocalService account, they have limited access to a user's data or to system files.
• User-mode drivers operate in a much simpler environment than kernel-mode drivers. For example, kernel-mode drivers must take into account IRQL, page faults, and thread context. In user mode, however, these issues do not exist. User-mode drivers always run in a different thread from the requesting process and can always take page faults.
• UMDF version 2 offers feature parity with KMDF in most areas. For a full comparison, see Comparing UMDF 2.0 Functionality to KMDF.
• UMDF version 2 facilitates converting between KMDF and UMDF. See How to convert a KMDF driver to a UMDF 2.0 driver (and vice-versa).
• You can debug UMDF drivers by using either a user-mode debugger or, starting with UMDF version 2, a kernel-mode debugger.
• You can use the Wdfkd.dll debugger extension commands with KMDF and starting with UMDF version 2. For more info, see Debugger Extensions.

A fundamental goal of the overall WDF model is to provide intelligent defaults, so that you can focus on your device hardware and avoid writing code to perform tasks that are common to most drivers. To achieve this goal, the framework is designed to work with drivers on an "opt-in" basis. When you write a UMDF driver, you provide callback routines for only the events that affect your device. For example, some devices require intervention immediately after they are turned on and just before they are turned off. The driver for such a device can implement callback functions that the framework calls at those times.

The driver includes code to handle only those events for which its device requires device-specific support. All other events can be handled by framework defaults.
In addition, a driver can configure its I/O request queues so that the framework stops dispatching requests while the device is in a low-power state and resumes dispatching after the device has returned to the operational state. Similarly, if an I/O request arrives while the device is in a low-power state, the framework can automatically turn on the device.

Misc Info:

• The Windows 10 WDF source code is now available as open source on GitHub. This means that you can debug your driver using WDF source code. Download it from http://github.com/Microsoft/Windows-Driver-Frameworks.
• The Windows Driver Kit (WDK) 10 samples are also now published to GitHub. Download them from http://github.com/Microsoft/Windows-Driver-Samples.
• Want to benefit from the universal capabilities of UMDF 2? To learn how to port your old UMDF 1 driver, see Porting a Driver from UMDF 1 to UMDF 2.

ref:

Getting started with Windows drivers -

• https://msdn.microsoft.com/en-us/library/windows/hardware/ff554690(v=vs.85).aspx
• https://msdn.microsoft.com/en-us/library/windows/hardware/dn265580(v=vs.85).aspx

Getting started with UMDF - https://msdn.microsoft.com/en-us/library/windows/hardware/dn384105(v=vs.85).aspx

UMDF overview - https://msdn.microsoft.com/en-us/library/windows/hardware/ff560442%28v=vs.85%29.aspx

Choosing driver model - https://msdn.microsoft.com/en-us/library/windows/hardware/ff554652%28v=vs.85%29.aspx

Comparing UMDF 2.0 Functionality to KMDF - https://msdn.microsoft.com/en-us/library/windows/hardware/dn376882(v=vs.85).aspx

How to convert a KMDF driver to a UMDF 2.0 driver (and vice-versa) - https://msdn.microsoft.com/en-us/library/windows/hardware/dn265585(v=vs.85).aspx

Windows Driver Framework(WDF) development guide - https://msdn.microsoft.com/en-us/library/windows/hardware/ff557565(v=vs.85).aspx

What's New for WDF Drivers in Windows 10 Insider Preview - https://msdn.microsoft.com/en-us/library/windows/hardware/ff544296(v=vs.85).aspx