@vic4key
To avoid the application crash you need to allocate/align the stack...
Compiled and tested (MSVC 2017 15.7.3)

Hi Insid3Code. Not used any local variables inside. So the allocation is unnecessary I think. Even it can be shorter. Eg.

F1 PROC
PUSHAD
LEA RCX, TXT_F1
CALL puts
POPAD
F1 ENDP

More, your edited code should be:

F1 PROC
PUSH RBP
MOV RBP, RSP
SUB RSP, 40 ; Allocate space on the stack (8 for alignment and 32 for shadow space); Below of MOV RBP, RSP, this instruction already saved RSP to RBP.
LEA RCX, TXT_F1
CALL puts
LEAVE
ADD RSP, 40 ; Cleanup the stack... ; Not needed. The LEAVE instruction did it.
RET
F1 ENDP

Hi Vic,
Are you already tested your snippets ?
Attached, both snippets (allocate/align) and binaries (one crash the other works fine)

I don't know if you can download the attachment from this topic, here external link:
Compiled and tested (MSVC 2017 15.7.3)

leave is short for
mov rsp, rbp
pop rbp
lose "add rsp, ..."

This discussion is majorly lacking a hugely important point:
Calling convention in x64 always uses the RCX, RDX, R8, R9 registers for passing the first 4 arguments (anything up to 64 bit values or pointers), while additionally to those 4 registers, RAX, R10 and R11 are considered volatile. The return value is in the RAX or possibly for a 128-bit return value would be in the RAX:RDX.

This is opposed to x86 where the prior scheme is closest to fastcall which used the ECX and EDX for argument passing before resorting to the stack with additionally the EAX volatile. However in cdecl (caller clean-up stack) calling convention, arguments are all passed on the stack, EAX, ECX and EDX are considered volatile, and the return value in EAX or EAX:EDX. syscall is the same except without the 3 registers being considered volatile. stdcall is also almost the same except the callee cleans up the stack.

If mixing C with external asm, it would be extremely wise to be familiar with all these details.

For more details which are too lengthly to include, refer to:

Microsoft x64 calling convention

Therefore code given here is all non-standards compliant with arbitrary calling convention (compiler will have return address of 8 bytes so an extra 8 indeed is needed but if called from assembler directly, etc assumption may not hold). If not calling back into C code which has been externed for use by the asm code (like puts is for sure), this should obviously not be necessary - neither alignment or shadow space.

That pattern is needed for both F1 and F2 and its straightforward.

Yes, right. In x64 arch, we always need to allocate the space for which called "shadow space". So, the above code should be:

Thank you, guys.

It should be:

You normally don't align stack like that.
You know that the caller has (according to the calling convention) taken care of its stack alignment and therefore the RSP on entry ends by 8 (the stack was 16B aligned before and then the return address has been pushed there by the CALL).
So the initial PUSH RBP has aligned the stack to 16B again, SUB RSP, 32 didn't break the alignment - and the AND instruction is useless, RSP is already aligned there.

I have to say thank you to all of you guys thank you for your solutions I learned a lot of things. :)

If your asm function is designed to be called from C only then yes I suppose that is a fair assumption. But in fact if it is called from asm including your own or I suppose unknown callers, then it is a false assumption. And this code is known.

The extra 8 bytes comes from having called your own function within proper convention asm already or the return address in case of Windows ABI invocation. CALL F1 in an improperly aligned routine of course adds 8 bytes to the stack and then adding 8 again would misalign it (hence the code examples leaked out there and above which show 40 byte assuming misalignment by an internal call already from ASM despite not having this in examples). The safest assumption is to assume any caller, and realign the stack with an AND RSP, -16 or even to just do it on just the lower 32-bit ESP.

Linux has the same issue even with 32-bit code for late GCC versions as seen in this discussion: Calling printf in extended inline ASM
Even better here is a book on the issue for more in depth detail though unfortunately not listing the generic solution and instead letting you make assumptions or track things: