本文主要是介绍WDF驱动开发-PNP和电源管理(三)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
对于PNP设备来说，理解它们的启动和删除顺序，以及意外移除顺序非常重要，在早期，经常有拔插U盘导致windows重启的例子，这就是意外移除带来的问题。
功能或Filter驱动程序的启动顺序
下图显示了框架调用 WDF (KMDF 和 UMDF V2) 功能或Filter驱动程序的事件回调函数的顺序，从图底部的“设备插入”状态开始：
宽横线标记启动设备所涉及的步骤。 图左侧的列描述了步骤，右侧的列列出了完成该步骤的事件回调。
在图的底部，系统不存在该设备。 当用户插入设备时，框架首先调用驱动程序的 EvtDriverDeviceAdd 回调，以便驱动程序可以创建设备对象来表示设备。 框架继续调用驱动程序的回调例程，方法是继续执行序列，直到设备正常运行。 请记住，框架按自下而上的顺序调用事件回调，如图所示，因此 在 EvtDeviceFilterAddResourceRequirements 等之前调用 EvtDeviceFilterRemoveResourceRequirements 。 如果设备已停止以重新平衡资源或实际存在但处于低功耗状态，则并非所有步骤都是必需的，如图所示。
总线驱动程序的启动顺序
下图显示了从图底部的“设备插入”状态开始，使设备进入完全运行状态时，框架调用 KMDF 总线驱动程序的事件回调函数的顺序：
在从系统中物理删除相应的设备之前，框架不会以物理方式删除 PDO。 例如，如果用户在 设备管理器 中禁用了设备，但没有实际删除该设备，则框架会保留其设备对象。 因此，图底部的三个步骤仅在即插即用枚举期间发生，即在初始启动期间或用户插入新设备时。 如果设备以前已禁用但未实际删除，框架会通过调用 EvtDevicePrepareHardware 回调启动。
功能或Filter驱动程序的电源关闭和删除顺序
下图显示了关闭和删除设备时框架调用 KMDF 功能或Filter驱动程序的事件回调函数的顺序。 序列从图的顶部开始，设备处于工作电源状态 (D0) ：
如图所示，KMDF 关机和删除序列涉及按框架调用使设备正常运行所涉及的函数的相反顺序调用相应的“撤消”回调。 框架在删除设备对象上下文区域后删除设备对象。
总线驱动程序的电源关闭和删除顺序
下图显示了在关闭并删除连接到总线的设备时框架调用 KMDF 总线驱动程序的事件回调函数的顺序。 序列从图的顶部开始，设备处于工作电源状态 (D0) ：
在从系统物理删除设备之前，框架不会删除 PDO。 例如，如果用户在 设备管理器 中禁用设备或在“安全删除硬件”实用工具中将其停止，但未以物理方式删除设备，则框架将保留 PDO。 如果设备稍后重新启用，框架将使用相同的 PDO，并通过调用 EvtDevicePrepareHardware 回调来开始启动序列，如 物理设备对象的电源启动序列中所示。
注意：通常，框架在为驱动程序枚举的所有子设备调用 EvtDeviceReleaseHardware 函数后，会调用总线驱动程序的 EvtDeviceReleaseHardware 回调函数。 如果父级遇到设备开机或关机故障，框架可能会在调用所有子设备的 EvtDeviceReleaseHardware 函数之前调用驱动程序的 EvtDeviceReleaseHardware 。 请考虑调用 WdfDeviceInitSetReleaseHardwareOrderOnFailure ，以确保框架仅在删除所有子设备后调用总线驱动程序的 EvtDeviceReleaseHardware 回调。
意外删除顺序
如果用户在不发出警告的情况下移除设备，只需在不使用 设备管理器 或安全删除硬件实用工具的情况下拔下设备，则设备被视为“意外删除”。发生这种情况时，框架遵循略有不同的删除顺序。 如果另一个驱动程序在设备上调用 IoInvalidateDeviceState ，则也会遵循意外删除序列，即使设备在物理上仍然存在。 在意外删除序列中，框架先调用 EvtDeviceSurpriseRemoval 回调，然后再调用删除序列中的其他任何回调。 序列完成后，框架将销毁设备对象。 所有可移动设备的驱动程序必须确保关闭和启动路径中的回调可以处理故障，尤其是硬件删除导致的故障。 访问硬件的任何尝试都不应无限期等待，但应受到超时或监视程序计时器的约束。
下图显示了意外删除中涉及的回调：
如果设备在删除时未处于工作状态，框架会在 EvtDeviceSurpriseRemoval 之后立即调用 EvtDeviceReleaseHardware 事件回调。 它省略了在设备退出工作状态时已执行的干预步骤。
处理停止设备的请求
在两种情况下，在要求设备的驱动程序停止设备之前，PnP 管理器会询问驱动程序是否是一个好主意：
- 用户已插入新设备，PnP 管理器必须 重新分发系统的硬件资源 以适应新设备；
- 用户已指示他/她要 删除该设备；
驱动程序可以通过多种方式处理这些情况：
- 如果驱动程序由于设备支持特殊文件而调用了 WdfDeviceSetSpecialFileSupport ，并且如果设备上打开了特殊文件，则框架将不允许设备停止；
- 若要在相对较短的时间内暂时阻止所有停止，驱动程序可以调用 WdfDeviceSetStaticStopRemove；
- 若要单独评估和处理每个停止尝试，驱动程序可以提供 EvtDeviceQueryStop 和 EvtDeviceQueryRemove 回调函数；
如果设备不支持特殊文件，并且停止或删除设备绝不是驱动程序或设备的问题，则驱动程序不提供 EvtDeviceQueryStop 和 EvtDeviceQueryRemove 回调函数，并且从不调用 WdfDeviceSetStaticStopRemove。 在这种情况下，PnP 管理器始终停止设备，而无需先检查驱动程序是否允许它。
重新分发资源
有时，PnP 管理器必须重新分发系统的硬件资源。 通常，发生此重新分发是因为总线驱动程序已报告已插入新设备，并且新设备需要已分配的资源。 在重新分配资源之前，必须停止设备。
如果驱动程序有时需要阻止 PnP 管理器停止繁忙的设备，驱动程序可以提供 EvtDeviceQueryStop 回调函数。 如果驱动程序的 EvtDeviceQueryStop 回调函数返回错误状态值，则 PnP 管理器不会停止设备。
如果驱动程序确定停止设备是安全的，则回调函数将返回STATUS_SUCCESS。 如果设备的其他驱动程序都无法阻止停止，PnP 管理器将暂时停止设备。
用户删除或禁用设备
用户可以删除或禁用某些设备。 例如：
- 如果驱动程序已设置可移动成员 (而不是设备WDF_DEVICE_PNP_CAPABILITIES结构的 SurpriseRemovalOK 成员) ，则用户可以运行拔出或弹出硬件程序，然后拔出或弹出设备；
- 如果驱动程序尚未设置设备的WDF_DEVICE_STATE结构的 NotDisable 成员，则用户可以使用 设备管理器 禁用设备；
在这种情况下，PnP 管理器会尝试在用户删除设备之前将其停止。
如果驱动程序有时需要阻止删除繁忙设备，驱动程序可以提供 EvtDeviceQueryRemove 回调函数。 如果任何驱动程序的 EvtDeviceQueryRemove 回调函数返回错误状态值，则 PnP 管理器不会停止设备。
如果驱动程序确定用户删除设备是安全的，则回调函数将返回STATUS_SUCCESS。 如果设备的其他驱动程序都无法阻止删除，PnP 管理器将停止设备。
这篇关于WDF驱动开发-PNP和电源管理(三)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
