支持特殊文件
特殊文件 包括分页文件、转储文件和休眠文件。 如果驱动程序的目标设备是系统可能用于这些文件的存储设备，则驱动程序必须执行以下操作：
- 调用 WdfDeviceSetSpecialFileSupport 以启用或禁用对每种类型的特殊文件的支持。 默认情况下禁用每个驱动程序对特殊文件的支持。
- 枚举子设备的总线驱动程序还应为每个可支持特殊文件的子设备调用 WdfDeviceSetSpecialFileSupport。
- 如果一台设备在支持特殊文件时依赖于另一台设备，请调用 WdfDeviceAddDependentUsageDeviceObject。
（可选）从 KMDF 1.11 开始提供 EvtDeviceUsageNotification 或 EvtDeviceUsageNotificationEx 回调函数，以便在创建或删除特殊文件时通知驱动程序。
如果驱动程序为设备调用 WdfDeviceSetSpecialFileSupport ，并且设备上打开了特殊文件，则框架不允许 PnP 管理器删除或停止设备。
驱动程序调用 WdfDeviceAddDependentUsageDeviceObject 后，它可以调用 WdfDeviceRemoveDependentUsageDeviceObject 以删除设备在另一台设备上的依赖关系。
使用控制设备对象
控制设备对象是不支持即插即用 (PnP) 或电源管理操作的框架设备对象。 驱动程序可以使用控制设备对象来表示仅软件虚拟设备或 旧硬件设备 (即不提供 PnP 或电源管理功能的设备) 。
创建控制设备对象的驱动程序通常还会为设备对象创建符号链接。 应用程序可以通过将符号链接名称传递给 API 元素（例如 Microsoft Win32 CreateFile 函数）来向控制设备对象发送 I/O 请求。
框架不会将控制设备对象附加到 设备堆栈。 因此，当应用程序向控制设备对象发送 I/O 请求时，I/O 管理器会将请求直接传递到创建控制设备对象的驱动程序，而不是将请求传递到堆栈顶部的驱动程序。 但是，其他驱动程序可以调用 IoAttachDevice ，以在控制设备对象上方附加设备对象。在这种情况下，其他驱动程序首先接收 I/O 请求。
控制设备对象的使用
控制设备的两个典型用途是：
1. 如果驱动程序支持一组自定义 I/O 控制代码供应用程序使用，则为 PnP 设备的Filter驱动程序：
如果应用程序尝试使用（例如， 设备接口 的符号链接名称 ）将自定义 I/O 控制代码发送到驱动程序堆栈的顶部，如果驱动程序无法识别自定义 I/O 控制代码，则Filter驱动程序上方的驱动程序可能会使 I/O 请求失败。 若要避免此问题，Filter驱动程序可以创建控制设备对象。 应用程序可以使用控制设备对象的符号链接名称将 I/O 控制代码直接发送到Filter驱动程序。
请注意，Filter驱动程序避免此问题的更好方法是充当总线驱动程序并 枚举 在原始模式下运行的子设备。 换句话说，对于Filter驱动程序支持的每个设备，驱动程序可以 不需要功能驱动程序的 PDO创建物理设备对象。 驱动程序为每个设备调用 WdfPdoInitAssignRawDevice 和 WdfDeviceInitAssignName ，应用程序可以在发送自定义 I/O 控件代码时按名称标识设备。
2. 不支持 PnP 的设备驱动程序：
此类驱动程序必须使用控制设备对象，因为此类设备的设备对象不驻留在设备堆栈中，并且不提供 PnP 功能。
创建控制设备对象
若要创建控制设备对象，驱动程序必须：
1. 调用 WdfControlDeviceInitAllocate 以获取 WDFDEVICE_INIT 结构。
2. 根据需要调用对象初始化方法以初始化WDFDEVICE_INIT结构。 驱动程序只能调用以下初始化方法：
WdfControlDeviceInitSetShutdownNotification
WdfDeviceInitAssignName
WdfDeviceInitAssignSDDLString
WdfDeviceInitAssignWdmIrpPreprocessCallback
WdfDeviceInitSetCharacteristics
WdfDeviceInitSetDeviceClass
WdfDeviceInitSetExclusive
WdfDeviceInitSetFileObjectConfig
WdfDeviceInitSetIoInCallerContextCallback
WdfDeviceInitSetIoType
WdfDeviceInitSetRequestAttributes
3. 调用 WdfDeviceCreate，它使用 WDFDEVICE_INIT 结构的内容来创建框架设备对象。
4. 完成以下初始化操作：
- 如果需要，请为设备创建默认 I/O 队列；
- 如果需要，请调用 WdfDeviceConfigureRequestDispatching；
- 调用 WdfDeviceCreateSymbolicLink 以创建应用程序可用于访问控制设备的符号链接名称；
5. 调用 WdfControlFinishInitializing。
使用控制设备对象的规则
创建控制设备对象的驱动程序必须遵循以下规则：
- 驱动程序无法将控制设备对象的句柄传递给 枚举子设备的框架方法；
- 驱动程序无法将控制设备对象的句柄传递给支持 设备接口的框架方法；
- 驱动程序可以创建 I/O 队列并为队列注册请求处理程序，但框架不允许对队列进行 电源管理；
- 驱动程序可以为控制设备 对象创建文件 对象；
命名控件设备对象
所有控制设备对象都必须命名。 通常，驱动程序将调用 WdfDeviceInitAssignName 来分配设备名称，然后调用 WdfDeviceCreateSymbolicLink 来创建应用程序可用于访问对象的符号链接名称。
如果驱动程序未调用 WdfDeviceInitAssignName 来分配设备名称，框架会自动为控制设备生成名称，但驱动程序无法调用 WdfDeviceCreateSymbolicLink。
驱动程序可以调用 WdfDeviceInitSetDeviceClass ，为控制设备指定设备 设置类 。 设备安装类标识注册表的一个部分，其中包含管理员提供的有关属于安装程序类的设备的信息。
接收系统关闭通知
由于控制设备对象不支持 PnP，因此驱动程序无法注册在设备电源状态更改时通知驱动程序的回调函数。 但是，驱动程序可以调用 WdfControlDeviceInitSetShutdownNotification 来注册 EvtDeviceShutdownNotification 回调函数。 此回调函数在系统即将失去电源时通知驱动程序。
删除控制设备对象
某些驱动程序在卸载驱动程序之前必须删除其控制设备对象，如下所示：
如果驱动程序 (创建不支持 PnP 或电源管理) 的控制设备对象，并且驱动程序还创建支持 PnP 和电源管理的框架设备对象，则驱动程序最终必须在 IRQL = PASSIVE_LEVEL 调用 WdfObjectDelete 以删除控制设备对象。
如果驱动程序创建这两种类型的设备对象，则在驱动程序删除控制设备对象之前，操作系统无法卸载驱动程序。
但是，在框架删除其他设备对象之前，驱动程序不得删除控制设备对象。 若要确定框架何时删除了其他设备对象，驱动程序应为这些对象提供 EvtCleanupCallback 函数。
如果驱动程序创建控制设备对象，但不创建支持 PnP 和电源管理的框架设备对象，则驱动程序不必删除控制设备对象。
在这种情况下，框架在驱动程序的 EvtDriverUnload 回调函数返回后删除控制设备对象。
创建 KMDF 微型端口驱动程序
如果端口/微型端口体系结构允许微型端口驱动程序使用 WDM 或框架接口与其他驱动程序通信，则某些微型端口驱动程序可以使用 Kernel-Mode 驱动程序框架。 例如， 具有 WDM 下边缘的 NDIS 微型端口驱动程序 可以使用框架来实现下边缘。
如果希望微型端口驱动程序使用框架，驱动程序必须：
- 在调用 WdfDriverCreate 之前，在驱动程序WDF_DRIVER_CONFIG结构的 DriverInitFlags 成员中设置 WdfDriverInitNoDispatchOverride 标志。 设置此标志可让端口驱动程序而不是框架截获 I/O 管理器已定向到驱动程序 (IRP) I/O 请求数据包；
- 调用 WdfDeviceMiniportCreate 而不是 WdfDeviceCreate ，为微型端口驱动程序的设备创建框架设备对象。 当微型端口驱动程序通知其设备可用时，微型端口驱动程序应调用 WdfDeviceMiniportCreate ；
- 当驱动程序确定设备已删除时，调用 WdfObjectDelete 以删除 WdfDeviceMiniportCreate 创建的设备对象。由于驱动程序已设置 WdfDriverInitNoDispatchOverride 标志，框架无法确定何时删除设备，并且无法删除设备 object；
- 当端口驱动程序通知微型端口驱动程序即将卸载它时，调用 WdfDriverMiniportUnload ；
仅当基础设备支持即插即用 (PnP) 时，微型端口驱动程序才能使用该框架。 微型端口驱动程序不能使用框架的控制设备对象。
限制适用于 WdfDeviceMiniportCreate 方法创建的设备对象。
