l 便携式存储设备，比如PDA和手机
l 便携式媒体播放器
l USB块传输设备
l 显示/视频设备
微软认为将这些种类的设备驱动程序移到用户态，可以简化驱动程序的开发，增强Windows操作系统的稳定性。UMDF使用了一种基于COM的接口——COM-Lite。
UMDF驱动程序运行在用户态——运行在WUDFHost.exe进程中。UMDF的模型如下图所示：
UMDF驱动被实现成用户态下的动态链接库。这样的动态链接库使用了COM的编程模式，暴露了一组标准的COM 入口点（entry point）。这样的驱动可以用C或者C++语言编写，它可以使用Win32 API，甚至可以使用活动模板库（ATL）。微软推荐使用C++语言来编写UMDF驱动。虽然从理论上说，UMDF也可以用C语言来编写，但是目前没有例子可以参考。
在目前的UMDF架构中，每个UMDFHost.exe进程只对应一个设备。这意味着如果你有3个被同一个UMDF驱动程序驱动的设备，那么将有3个不同的UMDFHost.exe进程和该UMDF驱动的3个实例——每个设备对应该驱动的一个实例。因为这些驱动运行在不同的进程中，所以你必须自己实现在这些进程间共享数据的机制。
和你的驱动有关联的进程除了宿主进程UMDFHost.exe之外，还有另外一个——UMDF驱动管理器服务（UMDF Driver Manager Service），该进程是UMDF系统的一部分。它负责和你的驱动的UMDFHost.exe进程，还有其他的UMDFHost.exe进程通信。该服务作为设备启动过程的一部分而启动，管理宿主进程的生命周期，并对UMDF的内核态反射器驱动（Kernel Mode Reflector Driver）发出的消息做出响应。
位于内核态的UMDF反射器驱动（或者简单反射器）将用户态和内核态的设备栈（Kernel Device Stack）连接了起来。每个内核态的UMDF设备栈中都安装了一个反射器设备实例。该反射器负责将来自内核态的I/O，电源，以及PnP的消息送达到宿主进程。
用户的一个I/O请求是怎样传给宿主进程进行处理的呢？如上图所示，用户态的应用程序将它对设备操作的请求发送到内核态，而反射器将该请求转发给运行在用户态的某个合适的UMDFHost.exe进程进行处理。这个转发的过程对应用程序是完全透明的——只有UMDF驱动程序知道它运行在用户态。
正如上文提到的，UMDF是一个基于COM的DLL，但是它并不使用让很多COM开发者备受折磨COM的运行时库。因此，UMDF不使用COM来加载，卸载或者同步控制（诸如“公寓”之类）。UMDF仅仅使用COM的编程模型。最简单的方式是把COM接口看作C++中的抽象基类。
UMDF也使用KMDF开发者所熟悉的以下这些抽象基类：
l IWDFDriver
l IWDFDevice
l IWDFFile
l IWDFIoQueue
l IWDFIoRequest
l IWDFIoTarget
l IWDFMemory
l IWDFObject
微软这样设计的目的在于让KMDF开发者可以很容易地上手UMDF。与KMDF一样，UMDF开发者也可以为他们的对象有选择地支持某些回调函数（COM中对应的术语叫做“接口”）。当与这些接口相关联的事件被触发的时候，UMDF框架会自动地调用对应的例程（COM中的术语叫做“方法”）。
正如前面所说的，UMDF拥有一组用来表征UMDF对象的类。这些UMDF对象提供了它们所支持的接口的中所有方法的签名。UMDF驱动支持一个或者多个这样的接口。这些接口中的方法都是纯虚函数，所以UMDF驱动必须负责实现它所支持的接口中的所有方法。用COM的术语来说，你必须创建UMDF类的子类，并且负责在这个子类中实现你的UMDF驱动所要支持的所有接口和方法。