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

瞎搞，肯定会蓝。好好搞就不得。

不是瞎高啊，我需要这样的。我猜是不是等待时间过长，底层驱动有什么超时机制造成两者之间的不一致了

2029行写的是啥?把附近的代码帖出来 ,否则没有人知道为啥

        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分钟

我看在崩溃之前有个mountmgr的操作，不知道这个操作干吗的？有没有影响啊？