Minifilter导致磁盘管理与系统还原卡顿问题排查

我之前经手过好几起Minifilter和磁盘管理交互异常的案例，针对你说的diskmgmt.msc长时间无响应甚至启动失败的问题，结合你给出的IRP_MJ_VOLUME_MOUNT相关代码片段，咱们可以从这几个核心方向入手排查：

• IRP处理的阻塞与死锁风险
  你代码里针对IRP_MJ_VOLUME_MOUNT的逻辑，在获取diskDevice->g...这个资源时，有没有可能发生阻塞？比如这个全局资源在其他IRP处理路径也被持有，而且你们没有设计正确的同步机制——比如用了ExAcquireResourceExclusiveLite但没及时释放，或者和其他路径的锁形成了锁顺序反转。磁盘管理启动时会批量触发卷挂载相关IRP，只要有一个IRP被卡住，后续请求都会排队等待，直接导致diskmgmt陷入假死状态。

• IRP未被正确完成的遗漏路径
  仔细检查你的IRP_MJ_VOLUME_MOUNT处理分支，有没有存在代码路径遗漏，导致IRP没有被IoCompleteRequest收尾？如果IRP一直处于未完成状态，磁盘管理的发起线程会一直阻塞等待，最终表现为程序无响应。尤其是错误分支（比如资源获取失败、参数校验不通过），一定要确保IRP被正确完成，哪怕是返回错误状态码。

• 同步耗时操作拖慢处理流程
  如果在处理IRP_MJ_VOLUME_MOUNT时执行了同步的磁盘I/O、注册表查询或者其他耗时操作，会直接拖慢整个请求处理的速度。Minifilter中处理IRP要尽量避免同步阻塞，必要时应该把这类耗时操作放到工作队列（IoQueueWorkItem）中异步处理，然后快速完成当前IRP，不要让发起线程一直等待。

附上你提供的关键代码片段：

if(Data->Iopb->MajorFunction == IRP_MJ_VOLUME_MOUNT) { 
    dev = diskDevice->g...
    // 后续处理逻辑
}

从这段代码来看，重点要盯紧diskDevice->g...这个资源的访问逻辑——它是不是在多线程/多IRP环境下没有做好同步保护？比如这个全局结构有没有被其他线程并发修改，或者获取它时的锁和其他IRP处理路径的锁存在冲突？

内容的提问来源于stack exchange，提问作者Alex