minifilter一个很让人郁闷的缺陷

众所周知，如果传给FltXXX函数的Instance为NULL，则该请求将会发送给整个设备栈。如果instance不为NULL，则该请求将会发给该instance的下一个instance。

FltGetUpperInstance可以返回当前instance的上层的instance，但是当当前驱动已经是在minifilter的最上层的时候，该函数返回NULL。

于是，如果当前驱动是在minifilter的最上层，并且在驱动中想通过FltXXX函数把请求发送给自己的时候，我们会发现没有方便的办法，因为instance是自己的时候，请求是发给下一个instance，而instance为NULL的时候，请求将会发送到栈顶，这就和legacy filter有潜在的冲突。

要解决这个问题，一个方法是不用FltXXX函数，还有一个方法是再安装一个passthru的instance到自己的instance的上面。这两个方法都非常ugly，其实只要在设计的时候，定义一个dummy instance，代表minifilter的最上层instance，该instance在所有实际的instance之上，这样就可以完美地解决这个问题了，M$设计的时候就不能考虑再周全一点，郁闷！！

我觉得FLTxxx的优点就是防重入，要发给自己用ZWxxx就好啦。不知道这么理解对不对。不过tooflat的贴还是要顶！

FltXXX可以直接用FileObject，ZwXXX的不行啊

那的确，不过自己打开一下文件就有句柄啦，也还算方便哈。
而且在minifilter的读写例程中，直接用传参的FileObject作为FLTxxx的参数好像不行。windbg会在FLTxxx这句代码卡住，运行不下去，不知道为什么。

有些例程里面调用FLTXXX的某些函数可能会导致死锁的，要注意用对地方，也不是有了这些个函数就可以随便在哪里用啊

引用第4楼microbe于2008-05-19 10:36发表的  :
有些例程里面调用FLTXXX的某些函数可能会导致死锁的，要注意用对地方，也不是有了这些个函数就可以随便在哪里用啊

可是微软文档中没有给出这方面的说明阿

。。。有办法解决吗。？

顶！！！