请教sfilter和杀毒软件冲突的原因

  tooflat的sfilter在我的机器上终于成功运行了，
以前出的问题和缓存有关，已经解决。
但如果打开symantec antivirus，还是会蓝屏，
而且并不用等到加密或解密就出问题，
具体原因是什么？有没有解决的方案？
请高手指教.

参照filemon的代码，自己解决了进程名的问题。

haha,没有回音了，看来lsxredrain的代码还是保密的，
不过我正在自己调试，有问题还要向高手们请教。
另外，我在驱动中如何获得打开文件的进程名？

lsxredrain,能不能把你的代码也共享一部分，让我们这种新手学习学习。
对于这种蓝屏的问题，应该如何跟踪和调试？

所谓的持久是相对于文件关闭而言的,不是相对于重启

感谢lsxredrain，我也自己做一个保存filecontext的链表试试，
准备先弄一个简单的链表，如果没问题再作hash表。

不过用Zw****系列函数似乎不可避免，tooflat这种保存加密标记
的方法可能只用来做例子吧，lsxredrain说用hash表保存加密
标记以保证持久性，不太明白，hash表在内存里，重起不就丢了吗？

市面上能见到过的杀毒软件都测试过了

恩,是的,
我觉得问提还是在于同步方法不对,
我现在自己构建hash链表来保存filecontex,一点都不卡.

2.tooflat的sfilter与杀毒软件冲突的几个地方:
  a.使用Zw****系列函数读取规则和加密标记;
  b.使用RtlInsertElementGenericTable相关的函数来存储文件上下文,具体是哪里引起的没有详细分析,我现在是自己构造hash来存储.存文件上下文指针和加密标记,保证了文件加密标记的持久性.
使用 KeAcquireSpinLock( &gHashLockTable[hashIndex], &oldIrql );
KeReleaseSpinLock( &gHashLockTable[hashIndex], oldIrql );
SfForwardIrpSyncronously,来同步文件上下文表,不要用

KeInitializeEvent(&Event, NotificationEvent, FALSE);
KeWaitForSingleObject(&Event, Executive, KernelMode, FALSE, NULL);
来同步

但是不可能不用 filecontex

filectx ? 啥杀软?你都测试过几种杀软?

我测试过FileCtx不用就不和杀毒软件冲突了.

这处可能性应该比较少
 

其实杀软一般比较简单,现在国内的基本上是在驱动中截获到文件打开请求,然后pending后让应用层的服务进行扫描...

引用第14楼tooflat于2007-05-24 17:46发表的  :
文件过滤驱动和杀软冲突，和使用的框架没有关系吧，我们看出sfilter和filespy在框架上的区别。

和杀软冲突可能的一个原因是过滤驱动中维护文件上下文采用的方法和杀软用stream fileobject去scan有冲突，这个也是很好解决的，总之和sfilter,filespy的框架无关。

应该是和sfilter框架无关，因为sfilter的例子在我的机器上运行的很好，不过维护文件上下文采用的方法
我也没有看出什么问题，FileCtx都是在本层驱动中使用的，杀软应该不会访问到，除非杀软在scan中
重新创建了fileobject，或FsContent,我想才可能会有冲突，能否请tooflat说说详细的解决方法。
万分感谢！

引用第14楼tooflat于2007-05-24 17:46发表的  :
文件过滤驱动和杀软冲突，和使用的框架没有关系吧，我们看出sfilter和filespy在框架上的区别。

和杀软冲突可能的一个原因是过滤驱动中维护文件上下文采用的方法和杀软用stream fileobject去scan有冲突，这个也是很好解决的，总之和sfilter,filespy的框架无关。

 请问大侠有什么好的解决办法?

文件过滤驱动和杀软冲突，和使用的框架没有关系吧，我们看出sfilter和filespy在框架上的区别。

和杀软冲突可能的一个原因是过滤驱动中维护文件上下文采用的方法和杀软用stream fileobject去scan有冲突，这个也是很好解决的，总之和sfilter,filespy的框架无关。

通常是栈溢出了。

貌似这样不知道windbg分析对否,bugcheck code 怪大的。

kd> !analyze -show 1000007F
UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
        use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
        use .trap on that value
Else
        .trap on the appropriate frame will show where the trap was taken
        (on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000000, EXCEPTION_DIVIDED_BY_ZERO
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

     

太有才了，那只鸟我也有了。
直捣不怕太出血嘛,最起码那本书看还蛮不错....

想我这样的菜鸟，直捣简直太恐怖了。

引用第8楼znsoft于2007-05-19 21:34发表的  :
你的头顶上,有一只鸟站着的:)

就是那个 NT文件内幕  的书(那是个好大的鸟)，不是说人，znsoft 还没有那么无聊吧

devia的总结在哪篇文章里,是不是我找错了.
znsoft,那只鸟就是我吧:)