如何解决 kernel stack overflow!

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7F, {8, f771fd70, 0, 0}

*** ERROR: Module load completed but symbols could not be loaded for klif.sys
*** ERROR: Module load completed but symbols could not be loaded for d346bus.sys
Probably caused by : Sfilter.sys ( Sfilter!SfWrite+3bf )

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

UNEXPECTED_KERNEL_MODE_TRAP (7f)
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: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: f771fd70
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------


BUGCHECK_STR:  0x7f_8

TSS:  00000028 -- (.tss 0x28)
eax=0000018c ebx=8552e878 ecx=00000000 edx=861ca178 esi=aaa4d47c edi=86217100
eip=f71cd33a esp=aaa4ceec ebp=aaa4d088 iopl=0         nv up ei ng nz ac po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010292
Ntfs!_SEH_prolog+0x1a:
f71cd33a 53              push    ebx
Resetting default scope

DEFAULT_BUCKET_ID:  DRIVER_FAULT

PROCESS_NAME:  svchost.exe

LAST_CONTROL_TRANSFER:  from f71cdc76 to f71cd33a

STACK_TEXT:  
aaa4d088 f71cdc76 aaa4d47c 8552e878 861ca178 Ntfs!_SEH_prolog+0x1a
aaa4d270 f71cefc8 aaa4d47c 8552e878 861ca178 Ntfs!NtfsNonCachedIo+0x20e
aaa4d46c f71cec24 aaa4d47c 8552e878 0110070a Ntfs!NtfsCommonWrite+0x1824
aaa4d5e0 804f0095 86217020 8552e878 861b6030 Ntfs!NtfsFsdWrite+0xf3
aaa4d5f0 f728efbb 861b6030 8552eab4 8552eab4 nt!IopfCallDriver+0x31
aaa4d618 804f0095 861ac5d0 8552e878 862166e8 fltMgr!FltpDispatch+0x6f
aaa4d628 f7274def 8552eab4 862166e8 00000000 nt!IopfCallDriver+0x31
aaa4d88c 804f0095 861ac708 8552e878 8552ead8 Sfilter!SfWrite+0x3bf [我们的模块]
aaa4d89c aacd9cf1 861bf888 85c66978 85c41688 nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may be wrong.
aaa4d944 aacdc443 00c41688 8552e878 804f0095 klif+0x12cf1
aaa4d974 f71eef3c 861bf80e 861b0f88 aaa4da18 klif+0x15443
aaa4da40 f71eee89 e14a69c0 e148ee40 e14a69c0 Ntfs!LfsFlushLfcb+0x429
aaa4da64 f71f91d9 e14a69c0 e148ee40 e1015a90 Ntfs!LfsFlushLbcb+0x81
aaa4da8c f71eda60 e14a69c0 101c3390 00000000 Ntfs!LfsFlushToLsnPriv+0xf3
aaa4dacc f71d975f e1015a90 101c3390 00000000 Ntfs!LfsFlushToLsn+0x8e
aaa4dcb8 f71cec24 aaa4dcc8 85110878 0110070a Ntfs!NtfsCommonWrite+0x18f7
aaa4de2c 804f0095 86217020 85110878 861b6030 Ntfs!NtfsFsdWrite+0xf3
aaa4de3c f728efbb 861b6030 85110ab4 85110ab4 nt!IopfCallDriver+0x31
aaa4de64 804f0095 861ac5d0 85110878 862166e8 fltMgr!FltpDispatch+0x6f
aaa4de74 f7274def 85110ab4 862166e8 aaa4e0fc nt!IopfCallDriver+0x31
aaa4e0d8 804f0095 861ac708 85110878 85110ad8 Sfilter!SfWrite+0x3bf [我们的模块]
aaa4e0e8 aacd9cf1 85541a70 85c66978 85c41688 nt!IopfCallDriver+0x31
aaa4e190 aacdc443 00c41688 85110878 804f0095 klif+0x12cf1
aaa4e1c0 80569edf 85541a0e 85577ee0 aaa4e264 klif+0x15443
aaa4e28c f7207239 85541a70 aaa4e2d0 aaa4e2c8 nt!CcZeroData+0x4a7
aaa4e30c f71cf0be aaa4e51c e39b7d90 85541a70 Ntfs!NtfsZeroData+0x29e
aaa4e50c f71cec24 aaa4e51c 85145d98 0110070a Ntfs!NtfsCommonWrite+0x16ab
aaa4e680 804f0095 86217020 85145d98 861b6030 Ntfs!NtfsFsdWrite+0xf3
aaa4e690 f728efbb 861b6030 85145fd4 85145fd4 nt!IopfCallDriver+0x31
aaa4e6b8 804f0095 861ac5d0 85145d98 862166e8 fltMgr!FltpDispatch+0x6f
aaa4e6c8 f7274def 85145fd4 862166e8 aaa4e950 nt!IopfCallDriver+0x31
aaa4e92c 804f0095 861ac708 85145d98 85145ff8 Sfilter!SfWrite+0x3bf [我们的模块]
aaa4e93c aacd9cf1 85541a70 85c66978 85c41688 nt!IopfCallDriver+0x31
aaa4e9e4 aacdc443 00c41688 85145d98 804f0095 klif+0x12cf1
aaa4ea14 8050f3b8 85541a0e aaa4ea3c aaa4eadc klif+0x15443
aaa4eafc 8050fdda e38f7010 e38f7018 e38f7018 nt!MiFlushSectionInternal+0x3f8
aaa4eb38 804e5341 859b42a8 00000000 00000200 nt!MmFlushSection+0x1f2
aaa4ebc0 f71d4d33 8554cbe4 aaa4ec6c 00000200 nt!CcFlushCache+0x1d3
aaa4ec94 f71d0016 85777890 860a3e00 00000001 Ntfs!NtfsCommonRead+0x3d5
aaa4ed34 f7361f47 86217020 860a3e00 861b7328 Ntfs!NtfsFsdRead+0x22d
aaa4ed48 804f0095 86217020 860a3e00 861b6030 d346bus+0x2f47
aaa4ed90 8057f70a 860a3fd8 860a3e00 860acf80 nt!IopfCallDriver+0x31
aaa4ed80 804f0095 861ac5d0 860a3e00 806e5410 nt!IopSynchronousServiceTail+0x60
aaa4eda4 8057c7eb 861ac5d0 860a3e00 860acf80 nt!IopfCallDriver+0x31
aaa4eda4 8057c7eb 861ac5d0 860a3e00 860acf80 nt!NtReadFile+0x55d
aaa4ee3c 8054186c 80001400 00000000 00000000 nt!NtReadFile+0x55d
aaa4ee3c 805010b1 80001400 00000000 00000000 nt!KiFastCallEntry+0xfc
aaa4eed8 f727b28c 80001400 00000000 00000000 nt!ZwReadFile+0x11
aaa4f37c f727b724 854d6040 aaa4f6f0 00000200 Sfilter!sfMyCreateFile+0x1fc [我们的模块]
aaa4f440 f727f9f5 854d6040 861ac5d0 000019cc Sfilter!sfTest+0x34 [我们的模块]
aaa4f998 804f0095 861ac708 85327a10 85327c70 Sfilter!SfCreate+0xed5 [我们的模块]
aaa4f9a8 aacd9cf1 85327a20 85c66978 86083b50 nt!IopfCallDriver+0x31
aaa4fa50 aacdc443 00c41688 85327a10 804f0095 klif+0x12cf1
aaa4fb4c 805bedc0 861ade30 00000000 8557bda0 klif+0x15443
aaa4fbc4 805bb448 00000000 aaa4fc04 00000040 nt!ObpLookupObjectName+0x53c
aaa4fc18 80575ec1 00000000 00000000 00000001 nt!ObOpenObjectByName+0xea
aaa4fc94 80576838 0155fb74 00020088 0155fb3c nt!IopCreateFile+0x407
aaa4fcf0 80578f02 0155fb74 00020088 0155fb3c nt!IoCreateFile+0x8e
aaa4fd30 8054186c 0155fb74 00020088 0155fb3c nt!NtCreateFile+0x30
aaa4fd30 7c92eb94 0155fb74 00020088 0155fb3c nt!KiFastCallEntry+0xfc
0155fafc 7c92d68e 76b44690 0155fb74 00020088 ntdll!KiFastSystemCallRet
0155fb00 76b44690 0155fb74 00020088 0155fb3c ntdll!NtCreateFile+0xc
0155fb6c 76b4900e 00000000 02fcfd28 00000000 schedsvc!PfSvGetFileIndexNumber+0x56
0155fbc0 76b49afc 00000001 00000001 02380000 schedsvc!PfSvApplyPrefetchPolicy+0x273
0155ff18 76b4a6b1 02380008 00000000 00000000 schedsvc!PfSvProcessTrace+0x15c
0155ffb4 7c80b683 00000000 00000000 00000000 schedsvc!PfSvProcessTraceThread+0x11a
0155ffec 00000000 76b4a597 00000000 00000000 kernel32!BaseThreadStart+0x37

我们Hook了create操作,并且在sfMyCreateFile模块中调用了IoCreateFileSpecifyDeviceObjectHint函数.
            其中的函数参数是这样的:
            (&FileHandle,
            GENERIC_READ,
            &ObjectAttributes,
            &IoStatus,
            NULL,
            FILE_ATTRIBUTE_NORMAL,
            FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE,
            FILE_OPEN,
            FILE_NON_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT | FILE_NO_INTERMEDIATE_BUFFERING,
            NULL,
            0,
            CreateFileTypeNone,
            NULL,
            IO_IGNORE_SHARE_ACCESS_CHECK,
            AttachedToDeviceObject
            );
我们测试环境如下:
1.xp sp2操作系统
2.系统盘符是NTFS的情况下(Fat32文件系统下是不会出现这个问题)
3.在装有咔吧斯基7.0
4.一运行迅雷马上蓝屏

调用上面函数打开文件,再用ZwReadFile函数会出现以上蓝屏信息.发现如果把 FILE_NO_INTERMEDIATE_BUFFERING 这个参数屏蔽掉后,
就不会发生堆栈益处的错误.


想问的问题有一下几个:
1.为什么会造成多次调用write,而导致了kernal stack overflow!
2.有什么方法避免kernal stack的益处

扩大堆栈？

You'd better construct your own READ IRP and pass it down instead of using ZwReadFile in SfCreate()

我自己发送过IRP包的,但是还是没有用的!

我这边的程序，在内核要读写文件是使用IoCreateFileSpecifyDeviceObjectHint获得HANDLE，然后获得FO最后发自己IRP去读写，一直没遇到什么问题。
楼主在CREATE里面使用ZwReadFile函数会通过IO管理器发下来，再次被自己的READ拦截到，不知道楼主的READ和WRITE指派中有什么动作，有可能引起问题吧。

通过IoCreateFileSpecifyDeviceObjectHint生成的HANDLE,进行读写的时候是不会发生重入的,所以,应该不是自己发IRP就能解决的.FILE_NO_INTERMEDIATE_BUFFERING去掉就没问题了,为什么呢??
If the preceding call to ZwCreateFile set the FILE_NO_INTERMEDIATE_BUFFERING flag in the CreateOptions parameter to ZwCreateFile, the Length and ByteOffset parameters to ZwReadFile must be multiples of the sector size.
你确保都正确了吗??

多谢楼上几位的指出
我在根据你说的那个 must be multiples of the sector size 去试试.
因为我这里不是经常性的会发生这个BSOD,我在去试试吧!
如果有碰到过相同问题的朋友,多给点意见,谢谢!

通过IoCreateFileSpecifyDeviceObjectHint生成的HANDLE,进行读写的时候是不会发生重入的

To my understanding, IoCreateFileSpecifyDeviceObjectHint() can only avoid re-entrancy in MJ_CREATE, not in READ or WRITE. ZwRead() or ZwWrite() enters IO sub-system and send IRPs from the top of driver stack.

To my experience, usually invalid length or byteoffset only fails READ IRPs not BSOD. NTFS seems have very good parameter check for FILE_NO_INTERMEDIATE_BUFFERING.

我自己发送过IRP包的,但是还是没有用的!

You'd better show your new crash dump here again.

我根据你栈的提示，推测如下。
文件本来是CACHE的，你再以非CACHE去打开（FILE_NO_INTERMEDIATE_BUFFERING），那么就会触发，系统去FLUSH CACHE，系统在把已经写到缓存的文件内容刷到辅助存储的时候，就会发送PAGE的WRITE，IRP，然后这个IRP被你的WRITE拦截到，然后就递归了，所以可能是你WRITE处理PAGE IRP的时候可能或许。。。也可能。。。

就是重入了.

你用 ioCreate..byhint去create后面用这个HANDLE就不会重入了。