关于STATUS_INVALID_DEVICE_OBJECT_PARAMETER和STATUS_MOUNT_POINT_NOT_RESOLVED


2012-05-20

很久之前,我写了篇关于STATUS_INVALID_DEVICE_OBJECT_PARAMETER的blog,里面提到使用STATUS_REPARSE的FsFilter(后简称为R-FsFilter)对上层FsFilter造成的恶劣干扰。

  这两天看Alex Carp的文章,发现事情貌似有转机。具体参考他的Reparsing to a Different Volume in Win7 and Win8(需要爬墙)。

  我总结一下:   目前的win8提供了一种新的ECP和相应的数据结构,保证在返回STATUS_MOUNT_POINT_NOT_RESOLVED的时候开发者可以获得目标FO的FLT_FILE_NAME_INFORMATION和FLT_INSTANCE。   用我那篇blog的原型就是,当驱动A调用FltCreateFile失败后(Alex的文章里只提到了STATUS_MOUNT_POINT_NOT_RESOLVED,但我猜测对STATUS_INVALID_DEVICE_OBJECT_PARAMETER应该也是适用的,我还没有动手测试,只是看IopCheckTopDeviceHint的实现做出的猜测),可以从ECP中获取到本次打开操作的目标FO的FLT_FILE_NAME_INFORMATION和FLT_INSTANCE,然后再次FltCreateFile就可以了。

  说来简单,但实际上影响挺大的,这相当于要求所有的FsFilter开发者在调用FltCreateFile时都处理这种错误。仅仅是因为目标系统里可能会存在一个R-FsFilter。

  相信不会有太多的开发者会多写这些代码。   而且这个错误对上层FsFilter的开发者来说根本就不是问题。如果在客户机上出现这种问题,完全可以如此解释:“你看,卸载您安装的这个产品(姑且称为T)的驱动后,我公司的产品就能正常工作了。但是只要一安装它,我公司的产品就出问题了,你看你看,另一个公司的产品也不能工作了。这明显是T的问题,跟我公司的产品没有半毛钱关系。”

  悲催的是R-FsFilter开发者,知道问题有解决方案,但是却不能在自己的代码里解决……。

  或者,R-FsFilter开发者在开发完之后,再多写一个紧贴着它的上层驱动,专门处理STATUS_MOUNT_POINT_NOT_RESOLVED/STATUS_INVALID_DEVICE_OBJECT_PARAMETER?这要求必须使用支持固定加载层次的minifilter框架,并且MS要足够给面子提供两个相邻的Altitude,不过以我之前申请Altitude的经验,貌似有些难度。

  另外推荐Alex-Cap的几篇关于reparse技术的博文。其实他blog的每篇技术文章都推荐仔细阅读,我几乎备份了他所有的博文……

  注:由于本人能力有限,行文难免有错,请不吝赐教,感谢。