format pe console
include 'win32ax.inc'

call test_dump
call exit

test_dump:
        push    ebp
        mov     ebp,esp
        sub     esp,512
        lea     edi,[ebp-512]
        fxsave  [edi]           ;???
        ;...
        lea     edi,[ebp-512]
        fxrstor [edi]
        mov     esp,ebp
        pop     ebp
        ret    

Quote:

Why this one cries Access Violation?

Intel Manual wrote:

The first byte of the data should be located on a 16-byte boundary.

Quote:

why would the putchar (from msvcrt.dll) mess up with the SSE registers?

I do not know. But this may explain: https://msdn.microsoft.com/en-us/library/9z1stfyw.aspx

Regardless of whether it does or doesn't, you shouldn't depend on it not messing with it unless it is guaranteed by the calling convention.

Then don't store your data in the XMM registers. There is no sense in saving and restoring it 100 times when instead you can put it in memory once and read it when required.

Your argument could be extended to RAX, or any other register. There comes a point where a trade-off has to be made. If you saved everything across all system calls then things get saved far more often. But the saving is hidden behind the inscrutable OS call routine so people don't realise about all the extra work that is being done. Whether your code saves it, or the OS code saves it, makes no difference to the performance. But if you can have the OS save less things and the user code only save things when needed then you get a performance boost.

movdqa xmm0, dqword [byebye]
cinvoke putchar     ;----> bye bye XMM0    

XMM is used for more than just floating point. They can also be used for integer arithmetic/boolean operations and for general data movement. I assume putChar places a character on the screen for viewing? If so then naturally that involves copying the character's bitmap data to the display memory so why not use XMM and do it efficiently?

why would the putchar (from msvcrt.dll) mess up with the SSE registers? This is insanely annoying because everytime I use it, it clears xmm0 to xmm5 for no reason.
...
I tested the code on Windows 8 (64-bit)

pxor xmm0,xmm0
pxor xmm1,xmm1
pxor xmm2,xmm2
pxor xmm3,xmm3
pxor xmm4,xmm4
pxor xmm5,xmm5
mov rcx,[rbp+CONTEXT.RIP] ; get RIP pointing after the syscall instruction
mov r11,[rbp+CONTEXT.RFLAGS] ; RFLAGS
mov rbp,r9
mov rsp,r8
swapgs
sysretq
    

system error wrote:

why would the putchar (from msvcrt.dll) mess up with the SSE registers? This is insanely annoying because everytime I use it, it clears xmm0 to xmm5 for no reason.
...
I tested the code on Windows 8 (64-bit)

On x64 ms windows kernel, ring3 switches into ring0 using syscall instruction which transfers execution to KiSystemCall64 no matter 64 bit app or 32 bit app running in compatibility submode of long mode.
On return back from ring0 to ring3, the procedure name is KiSystemServiceExit which at the end executes something like this:

Code:

pxor xmm0,xmm0
pxor xmm1,xmm1
pxor xmm2,xmm2
pxor xmm3,xmm3
pxor xmm4,xmm4
pxor xmm5,xmm5
mov rcx,[rbp+CONTEXT.RIP] ; get RIP pointing after the syscall instruction
mov r11,[rbp+CONTEXT.RFLAGS] ; RFLAGS
mov rbp,r9
mov rsp,r8
swapgs
sysretq
    

Under ms windows x64, nonvolatile xmm registers are xmm6...xmm15. To access xmm8...15 your executable must not be 32 bit, you have to update it to x64.

The ROM fonts would only be active in full screen text mode in older versions of Windows OS (note that newer versions don't support this mode). But Windows can also display the console in graphics mode. Perhaps it makes a graphical copy also in case the user turns off full screen text? Anyhow, I don't know the details of what Windows does exactly but it does still follow the calling convention as stated above so there is no error or bug. And we can't go around having some functions follow one set of rules and others follow different sets of rules, it would all get to confusing and disorderly. If you really need to know exactly what Windows uses the lower XMM registers for then you can use a debugger to discover what it is doing.

So I guess that the pxor instructions are a security precaution to ensure no out-of-process information leakage in case those registers were used for something sensitive.