Since there is no red zone on x86, the memory at negative offsets relative to the stack pointer may be overwritten at any time. Therefore, the above sequence is permitted to jump to panic.

The memory at negative offsets relative to the stack pointer may be overwritten at any time.

mov r12,rax
.... call another API
mov rax,r12             ; or just use R12 directly if you need it somewhere
    

The sub rsp,8 is needed ...

entry $
  and spl, -16
...    

entry $
  pop rax
...    

00000000004022B0 | 48:83EC 08                 | SUB     RSP, 0x8                                       |
00000000004022B4 | 50                         | PUSH    RAX                                            |    

push rax
call something
...

...
something:
   ...
   invoke...
   ...
   ret 8
    

> But sub rsp,1 never generates an exception.

I don't think this is the point. The app can be interrupted at any point in time for keyboard, mouse, and spy cam interaction.

What is your reasoning for your choice of rax?

But "sub rsp,1" never generates and exception. So that article does not apply.

A debugger may use the memory beyond the red zone as a convenient place to store some data. For example, if you use the .call command, the debugger will perform the nested call on the same stack, and likely use some of that stack space to preserve registers so that they can be restored after the .called function returns. Any data stored beyond the red zone will therefore be destroyed.

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.

The operating system then dispatches the exception. It goes to a vectored exception handler, which some other part of your program had installed specifically to handle this possibility, because your program might be run directly off a CD-ROM or unreliable network. The program displays a prompt to ask the user to reinsert the CD-ROM and offers an opportunity to retry. If the user says to retry, then the vectored exception handler returns EXCEPTION_CONTINUE_EXECUTION, and the operating system will restart the failed instruction.

This time, the restart succeeds because the CD-ROM is present and the code can be paged back in. The next instruction runs, the one that loads the beyond-the-red-zone value into the ecx register, but it doesn’t load the value stored by the previous instruction because the STATUS_IN_PAGE_ERROR exception overwrote it. The comparison fails, and we jump to the label panic.

I guarantee you the stack won't ever be written

A debugger may use the memory beyond the red zone [...]