上周在XP系统上测试一个驱动的时候，发现驱动加载不上，“net start”命令只是给出一个无意义的错误代码，驱动的DriverEntry()入口程序还没有得到机会运行。
初步怀疑是引入函数的问题，用WDK工具Depends.exe查看了一下驱动文件，果然是由于_chkstk函数无法解析所导致。
_chkstk是个微软C编译器的辅助库函数，MSDN上对其介绍十分简略：
_chkstk Routine is a helper routine for the C compiler. For x86 compilers, _chkstk Routine is called when the local variables exceed 4096 bytes; for x64 compilers it is 8K.
当编译器察觉到局部变量太大超过限值时（X86系统限值是4K，X64t系统上是8K）, 编译器会自动插入_chkstk这个函数以保证栈空间所使用页面在内存中。
问题是发现了，但要查出来究竟在哪个函数中还是要费些心思的。从用户层移植过来不少代码，基本锁定问题出在其中，但如果一个函数一个函数寻找实在是个不讨巧的笨办法，也不符合程序人的一贯风格，便用IDA反编译驱动sys文件，于汇编代码中搜索_chkstk字串，直接锁定出了问题函数。此函数所使用的一个结构体中定义了超大数组，对栈的超常使用在内核中是相当危险的。
解决办法很简单，直接将此结构的定义放在一个从内存分配的结构中即可。问题虽已解决，但对于DDK中有关_chkstk的描述，及其相关的疑问一直让我觉得困扰，比如，为什么X86上是4K，而AMD64架构上可以是8K。
这两天终于有了时间，可以彻底地了结这个疑问了。
要想解决这个问题，还要先从用户栈的分配开始。以ReactOS代码为例，当线程创建时，CreateThread()会调用BasepCreateStack()来创建用户栈，具体可以参见ReactOS源码：
~/ReactOS/lib/kernel32/misc/utils.c。
BasepCreateStack()函数主要做三件事：
- 1，分配栈空间所需的虚拟内存，大小为Stack Reserve Size
- 2，根据Stack Commit Size锁定内存页面，如果Stack Commit Size小于Stack Reserve Size的话，需要增加一个Page，这个额外申请的Page用作Guard Page之用。
- 3，将栈底部的Page设定为Guard Page。
当用户栈被用尽时，会访问到栈底部的Guard Page。而对Guard Page的任何访问都会导致Page Fault的发生。Page Fault处理函数MmAccessFault()可以分析出此次Page Fault是由Guard Page导致，便会默认由用户栈处理程序MiCheckForUserStackOverflow()来处理。如果用户栈并没有溢出的话，即Stack Commit Size小于Stack Reserve Size的情况，MiCheckForUserStackOverflow()会自动向下扩展栈空间，扩展大小为GUARD_PAGE_SIZE。 GUARD_PAGE_SIZE针对不同的CPU架构有不同的定义：
X64: #define GUARD_PAGE_SIZE (PAGE_SIZE * 2)
X86: #define GUARD_PAGE_SIZE PAGE_SIZE
这里便解释了为什么X86系统上的限制是4K(即PAGE_SIZE)，而X64上却为8K的原因。
说到此处，该是解答_chkstk()倒底是干什么的时候了。Visual Studio中有_chkstk的源码，以x86为例：
输入参数eax是所需堆栈大小（字节）
labelP _chkstk, PUBLIC
push ecx ; save ecx
cmp eax,_PAGESIZE_ ; more than one page requested?
lea ecx,[esp] + 8 ; compute new stack pointer in ecx
; correct for return address and
; saved ecx
jb short lastpage ; no
;------------
probepages:
sub ecx,_PAGESIZE_ ; yes, move down a page
sub eax,_PAGESIZE_ ; adjust request and...
test dword ptr [ecx],eax ; ...probe it (如果是guard page，刚会导致page fault，最终用户栈
; 将向下扩展一个页面)
cmp eax,_PAGESIZE_ ; more than one page requested?
jae short probepages ; no
lastpage:
sub ecx,eax ; move stack down by eax
mov eax,esp ; save current tos and do a...
test dword ptr [ecx],eax ; ...probe in case a page was crossed
; 调用函数将要访问的堆栈底部 ，如果此页面为guard page，同
; 样会导致用户栈的向下延伸
mov esp,ecx ; set the new stack pointer
; 向下更改栈指针，其上直到原ESP的栈空间为调用函数局部变量
mov ecx,dword ptr [eax] ; recover ecx
mov eax,dword ptr [eax + 4] ; recover return address
; 将返回地址(调用函数中)放入eax
push eax ; prepare return address
; 将返回地址(调用函数中)放入当前栈中，准备返回
; ...probe in case a page was crossed
ret
end
_chkstk()的主要作用是保证栈向下连续的生长。如果没有_chkstk()，当局部变量太多并超过guard page下沿时，若再有压栈操作，将会导致Access violation错误。因为此时堆栈内存页面无效，压栈直接将导致page fault的发生，而page fault处理程序因不能识别此fault的发生原因从而不能做出正确判断和有效处理。
相对用户层，内核程序的处理则相当简单，就如Win7内核中_chkstk实际上就是个空函数。其原因就是内核线程的栈空间是固定的。其取值针对X86及X64架构亦有所不同：
X64： #define KERNEL_STACK_SIZE 0x6000 /* 6个内存页面 */
X86： #define KERNEL_STACK_SIZE 12288 /* 3个内存页面 */
内核中栈资源非常紧缺，并驱动程序的编写有较高的要求，特别是有递归的情况下，一定要注意嵌套的层数，否则很容易收到M$发来的蓝屏。
Windows内核中其实还有一种大堆栈机制，以确保一些对堆栈较高消耗的特殊情况能够得到满足，但这部分完全是黑箱，对用户不可见，不是常见情况，此处不再多述。
参考资料：
1, http://support.microsoft.com/kb/100775/en
2, http://msdn.microsoft.com/en-us/library/ms648426(v=vs.85).aspx
3, http://www.reactos.org ReactOS源码
