Finally, avoid architectures with lots of deeply-nested functions. I know your search only goes log(n) levels deep, but don’t make me stress about whether or not it’s ever going to exhaust the available stack. Most recursive algorithms can be expressed in iterative implementations without sacrificing too much.
In addition, you shouldn’t ever use recursion in your driver, unless You Know What You Are Doing.
Be aware of the fact that you probably exist within a driver stack, and the drivers above and below you would be greatful for some stack space that they could use for themselves, thank you very much. No more 64K arrays on the stack, for one thing. This means a few things: first, you need to be conservative with local variables. Because the OS has to just pick an amount of memory for the stack at runtime, and because stack memory is a scarce resource, 12k was the compromise the kernel team landed on. That means that the traditional way of automatically growing the stack cannot be implemented in the kernel.
Additionally, because kernel code can execute at raised IRQL, kernel stacks cannot take page faults on access. With the hundreds of threads in systems today, that memory starts to add up fast. You have to keep that stack sitting around forever, even if the thread is in user mode, until it exits.
That means that you’re gobbling up 12K of physical memory for each thread running in the system. First off, kernel stacks are generally not pageable. Why is the stack so small? Well, this was an early design decision made by the kernel team. It’s worth noting that almost every time I’ve had a duoble-fault bluescreen, it’s been a stack fault. The only thing the kernel can do at that point is die a painful death. The reason that this is a double-fault is that the CPU tries to build an exception record on the stack for transfer to the exception handler, and when it tries to push the record on to the overflowed stack, it faults again. If you use more than 12K of stack, you’ll hit a guard page, which probably means an instant double-fault bluescreen. My guess is that Microsoft increased the kernel stack size on Windows 2000 because of the deeper layering of drivers brought about by WDM (more on that in a sec). Believe it or not, this is bigger than it used to be – it was 8K in NT4 and previous.
It is usually 3 pages or so, which means 12k on X86. There are a few intersting issues in play here for kernel-mode developers. Today I think I’ll talk a bit about the kernel-mode stack. The good news is that I’m having fun writing it! If this post seems, well, a little druk - that’s why. Somehow, I managed to catch a cold this weekend, and can already feel the NyQuil starting to kick in.