Suppose your thread gets pre-empted immediately after you store the data beyond the red zone. While your thread is waiting for a chance to resume execution, the memory manager pages out the code. Eventually, your thread resumes execution, and the memory manager tries to page it back in. Oh no, there’s an I/O error during the page-in! The operating system pushes an exception frame onto the stack for the STATUS_IN_PAGE_ERROR, clobbering the data you had been hiding beyond the red zone.

What do you understand from this?

Raymond Chen wrote:

Suppose your thread gets pre-empted immediately after you store the data beyond the red zone. While your thread is waiting for a chance to resume execution, the memory manager pages out the code. Eventually, your thread resumes execution, and the memory manager tries to page it back in. Oh no, there’s an I/O error during the page-in! The operating system pushes an exception frame onto the stack for the STATUS_IN_PAGE_ERROR, clobbering the data you had been hiding beyond the red zone.

Maybe he got it wrong but it does seem like paging in can lead to exceptions (there's even a status code for it).

Whether any version of Windows pushes something onto the application thread’s stack on exception occurence is another question. If it does (or did) in any version, one would better avoid arbitrary RSP values for compatibility.

DimonSoft wrote:

Whether any version of Windows pushes something onto the application thread’s stack on exception occurence is another question. If it does (or did) in any version, one would better avoid arbitrary RSP values for compatibility.

Oh dear.

Clearly the explanation I gave is insufficient. There is no need to guess for this. It is 100% characterisable. You only ever get exceptions delivered if you ask for them, they are relevant to an instruction you just executed, and you can do something to fix it.

Windows doesn't deliver informative exceptions that you can only look at but not fix. It won't deliver paged-out exceptions to you. What could you do about it? You can't rewrite the page tables to fix it. Only a ring-0 process can do that.

SUB—Subtract
...
Operation

Code:

DEST := (DEST – SRC);    

Flags Affected
The OF, SF, ZF, AF, PF, and CF flags are set according to the result.

Code:

Instruction Operand Encoding
Op/En|  Operand 1     | Operand 2   |Operand 3|Operand 4
  I  | AL/AX/EAX/RAX  | imm8/16/32  |   NA    |   NA
  MI |ModRM:r/m (r, w)| imm8/16/32  |   NA    |   NA     << sub rsp, 1
  MR |ModRM:r/m (r, w)|ModRM:reg (r)|   NA    |   NA
  RM |ModRM:reg (r, w)|ModRM:r/m (r)|   NA    |   NA    

...
64-Bit Mode Exceptions

Code:

#SS(0) - If a memory address referencing the SS segment is in a non-canonical form.    

No memory reference

Code:

#GP(0) - If the memory address is in a non-canonical form.    

No memory reference

Code:

#PF(fault-code) - If a page fault occurs.    

No memory reference

Code:

#AC(0) - If alignment checking is enabled and an unaligned memory reference is made while the current privilege level is 3.    

No memory reference

Code:

#UD - If the LOCK prefix is used but the destination is not a memory operand.    

No LOCK.

Doesn't it stores context to 'reserved stack space'?

Does Windows use all of that hardware to conrol usermode?

Doesn't it stores context to 'reserved stack space'?

Raymond wrote about exceptions and exception handling, he basically said to forget about exception handling.
If you handle an exception, you are hiding why the exception occurred. Better to have your app crash and fix the bad code, since properly written code should never cause an exception.

Not for unrelated events like mouse move.

 TSS  | ring0    ring3
ss:sp0|          ss:sp3+$38 = ip
ss:sp1|          ss:sp3+$30 = bp
ss:sp2|          ss:sp3+$20 = xword
ss:sp3|          ss:sp3+$00 = $20 bytes for calls
------+         interrupt here (vector/trap handler) ss:sp = TSS.ss:sp0 (TSS.ss:sp3 doesn't change)
        ss:sp0+$20 = ss3
        ss:sp0+$18 = sp3
        ss:sp0+$10 = fl
        ss:sp0+$08 = cs3
        ss:sp0+$00 = ip3
                iret
                 ss:sp3+$00 = $20 bytes for calls    

I disagree there. An app can use reserved un-committed memory to allocate on demand. Then use exceptions to allocate each new piece.

stack <commit>,<reserv>    

Not for unrelated events like mouse move. But it will for exceptions your app causes if you ask for them.

What winapi SetTimer does then? I was thinking that all usermode under programmable interupts exept kernel or something.