那么,IRP 发往 A->B->0 ,0 完成了IRP后再'回卷': 0->B->A ,就是说,当一个IRP被完成后在返回的途中,B 是可以修改这个IRP的,那么,A 就要受到 B 的限制,有可能 B 在IRP完成后返回的途中修改了IRP中携带的信息,致使 A 无法正确获得相关信息;
逻辑思维上很简单,把这两个过滤驱动的位置调换一下,变成 IRP(开始发送) -> B -> A ->0(完成IRP)-> A -> B ;
只要确保 驱动A 刚刚好处于 Device\0 的上一层;
我想了个笨办法:驱动A 先去查找 0 的上一层驱动(AttachedDevice),如果存在,记录这个设备的指针,再摘除掉(IoDetachDevice),然后才开始挂载 A ,接着,再挂载刚才记录下的设备 - 这样,保证了 A 刚刚好处于 0 的上一层;变成:
Device\0
ATT: Device\A
ATT: Device\B
-----> 看似问题已经解决了,但是没有: (再看看IRP的发送过程)
IRP(开始发送) -> B -> .... 发送到哪里了呢?会是 A 吗? 不是!!! 而会是这样:
IRP(开始发送) -> B -> 0 没有发送到 A , 而是直接发送到了 0 ;
因为在驱动A加载之前,B 就获得了下一层驱动( Device\0 )的指针,B 进行了 IoCallDriver( "Device\0的指针", Irp );
所以,当 B 接收到IRP后,把IRP直接传递到了 Device\0 , 没有传递给 A ;
看来要使 A 获得IRP,要么修改 B 原来就已经储存好了的 "Device\0的指针" 为 A 的指针,以使 B 能把IRP传递给 A ;
要么,把 Device\0 '移走', 让 A 去占据'位置', 以使 B中的 "Device\0的指针" 指向 A , 那 Device\0 本身又往哪里去呢?