📜 ⬆️ ⬇️

Small but very insidious ambush with programming in kernelspace in MS Windows

The other day debugged the driver, during the use of which, chaotic and, at first glance, some magical BSoDs appeared. All function calls were correct, no errors with null pointers and other common hemorrhoids were observed. I did not understand what could happen to this driver, I asked a more experienced colleague to see what was wrong. A few hours later he said that he understood the reason for the bug. The result discouraged both of us.

It turned out that the cause of the drops is trivial: in the driver's logic, the stack was actively used, often the function used 10-20 kB of memory on the stack for various kinds of buffers and arrays. MSDN says that the kernel stack is limited to three pages of memory (which is about 12kb for a 32-bit architecture), and therefore it is better to refrain from multiple function calls and the use of recursion.
A kernel stack overflow error causes a so-called Double Fault, i.e. the processor tries to report a stack overflow and put a structure containing information about this error on an already full stack, thus another error occurs and the kernel has no choice but to “die in torment” (information about this is taken from here ).
Also, using the IoGetRemainingStackSize function, we realized that only 5 - 6 kb of memory on the stack reach our filter driver, and therefore, if more than one filter driver is loaded into the system, but several, then the probability of failures and BSoDs will greatly increase .
So, if there are any strange BSoDs in your driver, check if it may be due to a lack of memory on the stack, and do not repeat my mistakes.

')

Source: https://habr.com/ru/post/43991/


All Articles