阅读:1774回复:5
sfilter蓝屏了,蓝屏了
各位牛人,小弟我是个菜鸟,我最近对sfilter代码作了一点修改,不知道为什么蓝屏了。具体的修改是在SfPassThrough得IoCallDriver 之前用KeWaitForSingleObject等待了若干秒(最高5分钟),程序运行到某个时候突然蓝屏,下面是我用windbg察看的dump文件的输出,请各位牛人看看阿,看看是什么问题
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: 0000000c, memory referenced Arg2: 000000ff, IRQL Arg3: 00000000, value 0 = read operation, 1 = write operation Arg4: 804f56b0, address which referenced memory Debugging Details: ------------------ READ_ADDRESS: 0000000c CURRENT_IRQL: 0 FAULTING_IP: nt!ExAcquireSharedWaitForExclusive+13 804f56b0 66395e0c cmp [esi+0xc],bx DEFAULT_BUCKET_ID: DRIVER_FAULT BUGCHECK_STR: 0xA TRAP_FRAME: f88ee7d0 -- (.trap fffffffff88ee7d0) ErrCode = 00000000 eax=e1b3f978 ebx=00000000 ecx=00000000 edx=ffffffff esi=00000000 edi=832dcb20 eip=804f56b0 esp=f88ee844 ebp=f88ee850 iopl=0 nv up di pl zr na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010046 nt!ExAcquireSharedWaitForExclusive+0x13: 804f56b0 66395e0c cmp [esi+0xc],bx ds:0023:0000000c=???? Resetting default scope LAST_CONTROL_TRANSFER: from f82b0dac to 804f56b0 STACK_TEXT: f88ee850 f82b0dac 00000000 00000001 f82b3b1a nt!ExAcquireSharedWaitForExclusive+0x13 f88ee85c f82b3b1a 82ad0be8 e1b3f978 00000001 Ntfs!NtfsAcquirePagingResourceSharedWaitForExclusive+0x1d f88ee938 f82b4040 82ad0be8 828da280 00000001 Ntfs!NtfsCommonRead+0x427 f88ee9d8 804e2e0d 832e4470 828da280 832323d0 Ntfs!NtfsFsdRead+0x20f f88ee9e8 f850858f 828da280 832323d0 8307c020 nt!IofCallDriver+0x3f f88eea00 804e2e0d 8307c020 828da280 828da280 odyffilter!SfPassThrough+0x143 [f:\winddk\3790\src\filesys\filter\sfilter_create\sfilter.c @ 2029] f88eea10 805779ea 828da410 828da280 82b18cf0 nt!IofCallDriver+0x3f f88eea24 8057fb04 8307c020 828da280 82b18cf0 nt!IopSynchronousServiceTail+0x6c f88eeabc 804e9a8c 80000aec 00000000 00000000 nt!NtReadFile+0x566 f88eeabc 804e878d 80000aec 00000000 00000000 nt!KiSystemService+0xcb f88eeb58 f84cc499 80000aec 00000000 00000000 nt!ZwReadFile+0x11 f88eeba4 f84d0308 80000aec 00000000 8304be10 MountMgr!GetRemoteDatabaseEntry+0x31 f88eed24 f84c8101 0004be24 832dcb20 83287a30 MountMgr!ReconcileThisDatabaseWithMasterWorker+0x32c f88eed70 80577579 83287a30 83287ae8 8057231c MountMgr!WorkerThread+0x101 f88eed80 804ee5c8 832039d0 00000000 832dcb20 nt!IopProcessWorkItem+0xf f88eedac 805f3828 832039d0 00000000 00000000 nt!ExpWorkerThread+0xe9 f88eeddc 8050258e 804ee50d 00000001 00000000 nt!PspSystemThreadStartup+0x2e 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16 |
|
沙发#
发布于:2008-03-26 17:46
不是瞎高啊,我需要这样的。我猜是不是等待时间过长,底层驱动有什么超时机制造成两者之间的不一致了
|
|
板凳#
发布于:2008-03-27 11:42
Check_And_Wait(DeviceObject, irpStack);
// Call the appropriate file system driver with the request. IoSkipCurrentIrpStackLocation( Irp ); status = IoCallDriver( ((PSFILTER_DEVICE_EXTENSION) DeviceObject->DeviceExtension)->AttachedToDeviceObject, Irp ); return status; 2029的代码是status = IoCallDriver(....; 之前的Check_And_Wait宏的核心就是一个KeWaitForSingleObject,就是在IoCallDriver之前等待某一事件,最大超时5分钟 |
|
地板#
发布于:2008-03-27 11:47
我看在崩溃之前有个mountmgr的操作,不知道这个操作干吗的?有没有影响啊?
|
|