{"id":106215,"date":"2022-02-03T07:00:00","date_gmt":"2022-02-03T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=106215"},"modified":"2023-08-30T10:58:42","modified_gmt":"2023-08-30T17:58:42","slug":"20220203-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20220203-00\/?p=106215","title":{"rendered":"A closer look at the stack guard page"},"content":{"rendered":"

In a discussion of why Is\u00adBad\u00adXxx\u00adPtr<\/code> should really be called Crash\u00adProgram\u00adRandomly<\/code><\/a>, I gave a brief description of the stack guard page:<\/p>\n

The dynamic growth of the stack is performed via guard pages: Just past the last valid page on the stack is a guard page. When the stack grows into the guard page, a guard page exception is raised, which the default exception handler handles by committing a new stack page and setting the next<\/i> page to be a guard page.<\/p><\/blockquote>\n

Let’s break this down a bit more.<\/p>\n

Here’s a thread’s stack after the thread has been running for a little while. As is customary in memory diagrams, higher addresses are at the top, which means that the stack grows downward (toward lower addresses).<\/p>\n

\u00a0<\/div>\n\n\n\n\n\n\n\n\n\n\n
valid stack<\/span><\/td>\n\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n\u2190 Stack pointer<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nguard page<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The regular committed pages encompass all of the stack memory that the program has used so far. It may not be using all of it right now: Any memory beyond the red zone<\/a> is off limits to the application. When the stack pointer recedes from its high water mark, the pages left behind are not decommitted.<\/p>\n

The page just past the stack pointer’s high water mark is a special type of committed page known as a guard page. A guard page is a page which raises a STATUS_GUARD_PAGE_VIOLATION<\/code> exception the first time it is accessed.<\/p>\n

Suppose that the stack pointer moves into the guard page, indicating that the thread has increased its stack requirements by one additional page.<\/p>\n\n\n\n\n\n\n\n\n\n\n
valid stack<\/span><\/td>\n\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nguard page<\/td>\n\u2190 Stack pointer<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The moment the thread accesses memory from the guard page, the system converts it to a regular committed page (removing the PAGE_GUARD<\/code> flag) and raises a STATUS_GUARD_PAGE_VIOLATION<\/code> exception. The default exception handler deals with the exception by looking to see if the address lies in the current stack’s guard page region. If so, then it upgrades the next reserved page to a guard page, and then resumes execution:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
 <\/td>\n <\/td>\nBefore<\/td>\n <\/td>\nDuring<\/td>\n <\/td>\nAfter<\/td>\n<\/tr>\n
valid stack<\/span><\/td>\n\u00a0<\/td>\ncommitted<\/td>\n <\/td>\ncommitted<\/td>\n <\/td>\ncommitted<\/td>\n\u00a0<\/td>\nvalid stack<\/span><\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n <\/td>\ncommitted<\/td>\n <\/td>\ncommitted<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n <\/td>\ncommitted<\/td>\n <\/td>\ncommitted<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n <\/td>\ncommitted<\/td>\n <\/td>\ncommitted<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nguard page<\/td>\n\u2190 Stack pointer \u2192<\/td>\ncommitted<\/td>\n\u2190 Stack pointer \u2192<\/td>\ncommitted<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n <\/td>\nreserved<\/td>\n <\/td>\nguard page<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n <\/td>\nreserved<\/td>\n <\/td>\nreserved<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n <\/td>\nreserved<\/td>\n <\/td>\nreserved<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Clearing the PAGE_GUARD<\/code> flag on an access to a guard page means that once you access it, it stops being a guard page. This means that guard pages raise the guard page exception only on first access. If you fail to take action on a guard page exception, the system ignores it, and you lost your one chance to do something.<\/p>\n

This is why our code to detect stack overflows<\/a> makes sure to call _resetstkoflw()<\/code> if it decides to recover. Resetting the stack overflow state consists of turning the PAGE_GUARD<\/code> flag back on for the guard page, restoring the page to its former glory as a guard page so it can do its job of detecting stack growth.<\/p>\n

This is how things go when everything is working right. But things don’t always work right.<\/p>\n

If one thread accesses another thread’s guard page, perhaps due to a buffer overflow, or just an uninitialized pointer variable that happens to point there, that too will trigger the guard page exception. That exception is raised by the thread that did the accessing, which is not the thread that owns the stack. The default exception handler sees that the guard page exception is not for the current thread’s stack, so it ignores it.\u00b9<\/p>\n

Congratulations, your stack is now corrupted, because the guard page is gone:<\/p>\n\n\n\n\n\n\n\n\n\n\n
valid stack<\/span><\/td>\n\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n\u2190 Stack pointer<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\ncommitted<\/td>\n(oops)<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Things proceed normally for a while, until the thread’s stack needs to grow into what used to be the guard page.<\/p>\n\n\n\n\n\n\n\n\n\n\n
valid stack<\/span><\/td>\n\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\ncommitted<\/td>\n\u2190 Stack pointer (oops)<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Normally, this would trigger a guard page exception, and the system would do the usual thing of upgrading the next reserved page to a new guard page. However, that page is no longer a guard page, so execution just continues normally with no action taken.<\/p>\n

Things still proceed as if everything were perfectly normal, but the consequences of your misdeeds finally catch up to you when the stack pointer crosses into a second<\/i> new page, the first reserved<\/i> page.<\/p>\n\n\n\n\n\n\n\n\n\n\n
valid stack<\/span><\/td>\n\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
\u00a0<\/td>\ncommitted<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\ncommitted<\/td>\n(oops)<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n\u2190 Stack pointer (double oops)<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nreserved<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

This is also not a guard page, so no special stack expansion kicks in. You just get a stack overflow exception and die.<\/p>\n

Such is the sad life of invalid memory access. You can corrupt your own process in a subtle way that doesn’t show up until much, much later.<\/p>\n

Next time, we’ll investigate a stack overflow problem and learn how to detect whether this guard page corruption has occurred.<\/p>\n

\u00b9 In theory, the default exception handler could search through all the threads in the process and see if the address resides in a guard page of any<\/i> thread, but it doesn’t. One reason is that this would require cross-thread coordination with the thread whose guard page you accidentally accessed, as well as any other thread that also might be accessing that guard page at the same time. But the bigger reason is probably that the entire situation is a bug in the program anyway, and there’s no point going out of your way to slow down the system in order to deal with things that programs shouldn’t be doing anyway.<\/p>\n

\n