首页
社区
课程
招聘
未解决 [求助]文件驱动与2345安全卫士驱动的冲突问题的驱动定位(已解决)
发表于: 2020-10-28 11:07 3168

未解决 [求助]文件驱动与2345安全卫士驱动的冲突问题的驱动定位(已解决)

2020-10-28 11:07
3168

在产品安装过程中发现蓝屏。经初步排查(进安全模式一个个改驱动扩展名测出来的):驱动FileMonitor.sys与2345的2345Base.sys不能一起加载运行(各自分别加载运行都没问题的)!

Symbol search path is: srv*C:\symbols*http://msdl.microsoft.com/download/symbols

Executable search path is: 

Windows 7 Kernel Version 7600 MP (2 procs) Free x64

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 7600.16385.amd64fre.win7_rtm.090713-1255

Machine Name:

Kernel base = 0xfffff800`03e1e000 PsLoadedModuleList = 0xfffff800`0405be50

Debug session time: Wed Oct 28 10:00:22.651 2020 (UTC + 8:00)

System Uptime: 0 days 0:32:27.760

Loading Kernel Symbols

...............................................................

................................................................

..................................

Loading User Symbols

Loading unloaded module list

............

*******************************************************************************

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

*******************************************************************************


Use !analyze -v to get detailed debugging information.


BugCheck A, {0, 2, 0, fffff80003eafa83}


Probably caused by : ntkrnlmp.exe ( nt!KiPageFault+260 )


Followup: MachineOwner

---------


0: kd> !analyze -v -f

*******************************************************************************

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

*******************************************************************************


IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pageable (or completely invalid) address at an

interrupt request level (IRQL) that is too high.  This is usually

caused by drivers using improper addresses.

If a kernel debugger is available get the stack backtrace.

Arguments:

Arg1: 0000000000000000, memory referenced  //访问了NULL内存地址

Arg2: 0000000000000002, IRQL

Arg3: 0000000000000000, bitfield :

bit 0 : value 0 = read operation, 1 = write operation

bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)

Arg4: fffff80003eafa83, address which referenced memory


Debugging Details:

------------------



OVERLAPPED_MODULE: Address regions for 'RefreshList' and 'crashdmp.sys' overlap


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800040c60e0

 0000000000000000 


CURRENT_IRQL:  2


FAULTING_IP: 

nt!IopCompleteRequest+ae3

fffff800`03eafa83 488b09          mov     rcx,qword ptr [rcx]  //执行这条指令就崩了


CUSTOMER_CRASH_COUNT:  1


DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT


BUGCHECK_STR:  0xA


PROCESS_NAME:  dllhost.exe    //进程


IRP_ADDRESS:  ffffffffffffff89


TRAP_FRAME:  fffff880065986a0 -- (.trap 0xfffff880065986a0)

NOTE: The trap frame does not contain all registers.

Some register values may be zeroed or incorrect.

rax=fffff88006597b78 rbx=0000000000000000 rcx=0000000000000000

rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000

rip=fffff80003eafa83 rsp=fffff88006598830 rbp=0000000000000000

 r8=fffff88006598938  r9=fffff88006598930 r10=0000000000000002

r11=fffff80003eaefa0 r12=0000000000000000 r13=0000000000000000

r14=0000000000000000 r15=0000000000000000

iopl=0         nv up ei pl nz ac po cy

nt!IopCompleteRequest+0xae3:

fffff800`03eafa83 488b09          mov     rcx,qword ptr [rcx] ds:00000000`00000000=???????????????? //访问了NULL内存地址

Resetting default scope


LAST_CONTROL_TRANSFER:  from fffff80003e8f469 to fffff80003e8ff00


//函数调用栈,看不到是那个驱动引发的

STACK_TEXT:  

fffff880`06598558 fffff800`03e8f469 : 00000000`0000000a 00000000`00000000 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx

fffff880`06598560 fffff800`03e8e0e0 : fffffa80`1a97d180 fffffa80`18d69810 fffff8a0`02055e20 fffff880`03f05584 : nt!KiBugCheckDispatch+0x69

fffff880`065986a0 fffff800`03eafa83 : fffffa80`1b9ac060 00000000`00000000 fffffa80`1a7ad610 00000000`00000000 : nt!KiPageFault+0x260

fffff880`06598830 fffff800`03e6c92f : 00000000`00000001 00000000`0011f000 fffff800`00000000 00000000`00000000 : nt!IopCompleteRequest+0xae3

fffff880`06598900 fffff800`03e41ba9 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDeliverApc+0x1d7

fffff880`06598980 fffff800`041d22da : fffffa80`1a7ad610 fffffa80`1ba53b30 fffff880`06598b10 fffff880`06598b08 : nt!KiCheckForKernelApcDelivery+0x25

fffff880`065989b0 fffff800`041a6ebf : fffffa80`00000004 fffffa80`1ba53b30 fffff880`06598b10 00000000`00000000 : nt! ?? ::NNGAKEGL::`string'+0x2a83e

fffff880`06598aa0 fffff800`03e8f3e5 : 00000000`0000000c fffffa80`1b9ac060 00000000`0027ec78 fffff800`03f80d01 : nt!NtMapViewOfSection+0x2be

fffff880`06598b70 00000000`76f3013a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceExit+0x28a

00000000`0027ec58 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76f3013a



STACK_COMMAND:  kb


FOLLOWUP_IP: 

nt!KiPageFault+260

fffff800`03e8e0e0 440f20c0        mov     rax,cr8


SYMBOL_STACK_INDEX:  2


SYMBOL_NAME:  nt!KiPageFault+260


FOLLOWUP_NAME:  MachineOwner


MODULE_NAME: nt


IMAGE_NAME:  ntkrnlmp.exe   //内核模块


DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bc600


FAILURE_BUCKET_ID:  X64_0xA_nt!KiPageFault+260


BUCKET_ID:  X64_0xA_nt!KiPageFault+260


Followup: MachineOwner

---------


//函数调用栈

0: kd> kP

Child-SP          RetAddr           Call Site

fffff880`06598558 fffff800`03e8f469 nt!KeBugCheckEx

fffff880`06598560 fffff800`03e8e0e0 nt!KiBugCheckDispatch+0x69

fffff880`065986a0 fffff800`03eafa83 nt!KiPageFault+0x260

fffff880`06598830 fffff800`03e6c92f nt!IopCompleteRequest+0xae3

fffff880`06598900 fffff800`03e41ba9 nt!KiDeliverApc+0x1d7

fffff880`06598980 fffff800`041d22da nt!KiCheckForKernelApcDelivery+0x25

fffff880`065989b0 fffff800`041a6ebf nt! ?? ::NNGAKEGL::`string'+0x2a83e

fffff880`06598aa0 fffff800`03e8f3e5 nt!NtMapViewOfSection+0x2be

fffff880`06598b70 00000000`76f3013a nt!KiSystemServiceExit+0x28a

00000000`0027ec58 00000000`00000000 0x76f3013a

0: kd> kv

Child-SP          RetAddr           : Args to Child                                                           : Call Site

fffff880`06598558 fffff800`03e8f469 : 00000000`0000000a 00000000`00000000 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx

fffff880`06598560 fffff800`03e8e0e0 : fffffa80`1a97d180 fffffa80`18d69810 fffff8a0`02055e20 fffff880`03f05584 : nt!KiBugCheckDispatch+0x69

fffff880`065986a0 fffff800`03eafa83 : fffffa80`1b9ac060 00000000`00000000 fffffa80`1a7ad610 00000000`00000000 : nt!KiPageFault+0x260 (TrapFrame @ fffff880`065986a0)

fffff880`06598830 fffff800`03e6c92f : 00000000`00000001 00000000`0011f000 fffff800`00000000 00000000`00000000 : nt!IopCompleteRequest+0xae3

fffff880`06598900 fffff800`03e41ba9 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDeliverApc+0x1d7

fffff880`06598980 fffff800`041d22da : fffffa80`1a7ad610 fffffa80`1ba53b30 fffff880`06598b10 fffff880`06598b08 : nt!KiCheckForKernelApcDelivery+0x25

fffff880`065989b0 fffff800`041a6ebf : fffffa80`00000004 fffffa80`1ba53b30 fffff880`06598b10 00000000`00000000 : nt! ?? ::NNGAKEGL::`string'+0x2a83e

fffff880`06598aa0 fffff800`03e8f3e5 : 00000000`0000000c fffffa80`1b9ac060 00000000`0027ec78 fffff800`03f80d01 : nt!NtMapViewOfSection+0x2be

fffff880`06598b70 00000000`76f3013a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceExit+0x28a (TrapFrame @ fffff880`06598be0)

00000000`0027ec58 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76f3013a


//加载的内核模块

0: kd> lm f

start             end                 module name

fffff800`00b9c000 fffff800`00ba6000   kdcom    kdcom.dll   

fffff800`03e1e000 fffff800`043fb000   nt       ntkrnlmp.exe

fffff800`043fb000 fffff800`04444000   hal      hal.dll     

fffff880`00c00000 fffff880`00cc0000   CI       \SystemRoot\system32\CI.dll

...

fffff880`03271000 fffff880`032a1000   2345Base \SystemRoot\system32\drivers\2345Base.sys    //和FileMonitor.sys有冲突

...

fffff880`033c9000 fffff880`033df000   FileMonitor \??\C:\Program Files\DAMon(X64)\drivers\FileMonitor.sys  //和2345Base.sys有冲突

...



由于函数调用栈太深了,看不出就是那个驱动最终触的nt!KeBugCheckEx!有谁能帮忙找出来?谢谢!(dmp日志见附件)





[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入!

最后于 2020-10-28 20:24 被低调putchar编辑 ,原因:
上传的附件:
收藏
免费 0
支持
分享
最新回复 (8)
雪    币: 5484
活跃值: (3297)
能力值: ( LV5,RANK:60 )
在线值:
发帖
回帖
粉丝
2
常见做法不是禁止对方加载 卸载对方嘛
2020-10-28 14:06
0
雪    币: 2674
活跃值: (2304)
能力值: ( LV5,RANK:60 )
在线值:
发帖
回帖
粉丝
3

也是!这种情况要定位具体驱动比较麻烦。只有先让他们和客户那边沟通,看能否把2345安全卫士卸了或换用其它的!

如果客户实在要坚持,那就只有研发这边改了。谢谢解答!

2020-10-28 14:18
0
雪    币: 12364
活跃值: (5889)
能力值: ( LV5,RANK:60 )
在线值:
发帖
回帖
粉丝
4
rcx不一定是0哦,你看dump的寄存器信息都提示你了,某些寄存器的值可能已被清零或不准确
2020-10-28 15:12
0
雪    币: 2674
活跃值: (2304)
能力值: ( LV5,RANK:60 )
在线值:
发帖
回帖
粉丝
5

这也就是说:dmp中给出的IRQL_NOT_LESS_OR_EQUAL中的第一个参数可能不是准确的访问地址,可能是DISPATCH_LEVEL下访问了段换页内存造成的?

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pageable (or completely invalid) address at an

interrupt request level (IRQL) that is too high.  This is usually

caused by drivers using improper addresses.

If a kernel debugger is available get the stack backtrace.

Arguments:

Arg1: 0000000000000000, memory referenced

Arg2: 0000000000000002, IRQL DISPATCH_LEVEL

Arg3: 0000000000000000, bitfield :

bit 0 : value 0 = read operation, 1 = write operation

bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)

Arg4: fffff80003eafa83, address which referenced memory

Debugging Details:

------------------



OVERLAPPED_MODULE: Address regions for 'RefreshList' and 'crashdmp.sys' overlap


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800040c60e0

 0000000000000000 


CURRENT_IRQL:  2


FAULTING_IP: 

nt!IopCompleteRequest+ae3

fffff800`03eafa83 488b09          mov     rcx,qword ptr [rcx]


哎!蛋疼!关键是不能直接看到引起崩溃的驱动!各自装没问题,和2345一起安装就不行了,是兼容性问题。


2020-10-28 16:44
0
雪    币: 0
能力值: ( LV1,RANK:0 )
在线值:
发帖
回帖
粉丝
6

xxx

最后于 2020-10-28 17:29 被敌法师编辑 ,原因:
2020-10-28 17:04
0
雪    币: 12364
活跃值: (5889)
能力值: ( LV5,RANK:60 )
在线值:
发帖
回帖
粉丝
7
你往虚拟机里装个同版本的2345卫士调试一下不就知道了,如果2345的驱动和你那个驱动都是minifilter,可能是其中某个驱动的文件IRP过滤处理的不好,传递到下一个驱动进行处理就gg了
2020-10-28 17:59
0
雪    币: 2674
活跃值: (2304)
能力值: ( LV5,RANK:60 )
在线值:
发帖
回帖
粉丝
8
hhkqqs 你往虚拟机里装个同版本的2345卫士调试一下不就知道了,如果2345的驱动和你那个驱动都是minifilter,可能是其中某个驱动的文件IRP过滤处理的不好,传递到下一个驱动进行处理就gg了

好方法!这样就可以把有冲突的IRP找到了。我还是不想损失功能,麻烦点都要得!

2020-10-28 19:22
0
雪    币: 2674
活跃值: (2304)
能力值: ( LV5,RANK:60 )
在线值:
发帖
回帖
粉丝
9

找到原因了,FileMonitor.sys是基于sfilter框架自己绑定卷设备来过滤的,在IRP_MJ_CREATE的过滤中,文件打开前和文件打开后获得路径的方式都有,

在文件打开后对FileObject进行ObQueryNameString获得路径就和2345安全卫士不兼容了,

在文件打开前通过FileObject->FileName,FileObject->RelatedFileObject及StorageStackDeviceObject获得路径就没问题。

又试了下QQ电脑管家也有这个问题,如果要兼容2345安全卫士,QQ电脑管家,只有全部改为:文件打开前获取路径了!只是工作量有点大!

感谢大神提醒!


最后于 2020-11-7 16:44 被低调putchar编辑 ,原因:
2020-10-28 20:23
0
游客
登录 | 注册 方可回帖
返回
//