微软近日公布Windows新功能「Cloud-Initiated Driver Recovery」（CIDR，云端启动驱动程序复原），未来若通过Windows Update发布的驱动程序在推出后被判定存在质量问题，微软将能从云端主动启动复原流程，把受影响计算机上的问题驱动程序回复至先前已知可正常运作的版本。
CIDR 机制不需要用户手动解除安装，也不需要硬件合作伙伴另行介入，目标是缩短设备长时间停留在低品质驱动程序上的空窗期。
过去Windows Update是维持系统与硬件兼容性的重要管道，却曾因驱动程序测试未能拦下问题版本，导致用户在更新后遇到蓝白画面、硬件异常、效能下降，或装置无法正常运作等状况。
这类更新问题往往需要用户自行进入装置管理员回复驱动程序，或等待硬件厂商重新提交修正版，对一般用户而言不够直觉，导致问题可能在电脑上持续存在一段时间。 CIDR 正是为了让微软能在判定驱动程序质量不合格后，直接通过既有 Windows Update 基础架构推送回复指令。
CIDR如何运作：从判定问题到回复旧版
根据微软 5 月 12 日在官方技术社群博客的说明，CIDR 触发点来自 Hardware Dev Center（HDC）的 Driver Shiproom（驱动程序船舱）评估流程：
- 在Shiproom标记问题驱动：先前已通过Windows Update发布的驱动程序，会在Driver Shiproom评估流程中被检查质量状态，若判定存在质量问题，就会被标记为需要处理的对象。
- 启动恢复请求：微软会从 Driver Shiproom 建立恢复请求，锁定出问题的特定驱动程序，以及与该驱动程序相关的 shipping labels，确保后续处理范围只限于受影响的设备与硬件目标。
- 通过 Windows Update 下达回复指令：Windows Update 会把回复指令传送到受影响装置，并先确认是否有已核准的可用驱动程序版本; 确认后，系统才会解除安装遭拒绝的问题驱动，并改回先前可正常运作的版本或 Windows Update 上可取得的合适版本。
微软也强调，如果某些设备找不到经 Driver Shiproom 核准的可用驱动程序，系统就不会尝试执行 CIDR，以避免在没有安全替代方案的情况下贸然回复。
该流程会通过既有Windows Update基础设施完成，不需要额外安装新的用户端代理程序，且不要求硬件合作伙伴修改API自动化流程或门户网站作业，对用户来说，理想情况下这会像一般Windows Update修正一样在背景完成。
微软表示，CIDR是由微软端到端管理的能力，当某个驱动程序在 flighting 或 gradual rollout 过程被拒绝并启动复原时，合作伙伴会通过既有 Shiproom 沟通渠道收到通知。
复原完成后，硬件合作伙伴仍可依照正常Hardware Dev Center提交流程送出修正版驱动程序，只要新版通过Shiproom评估，便能照常通过Windows Update发布。
因此CIDR是补上「问题版本已经送到用户装置，但修正版尚未完成发布」之间的空窗，不是取代硬体厂商修正问题的机制。 微软也要求合作伙伴持续监控 Hardware Dev Center 仪表板的驱动程序质量指标，并针对遭拒提交项目所收到的 Shiproom 回馈尽快回应。
