Si. "The stack will always be maintained 16-byte aligned, except within the prolog (for example, after the return address is pushed), and except where indicated in Function Types for a certain class of frame functions."

https://docs.microsoft.com/en-us/cpp/build/stack-usage?view=msvc-170

Y es basicamente lo mismo para AMD64 System V ABI (https://coderedirect.com/questions/51914/why-does-the-x86-64-amd64-system-v-abi-mandate-a-16-byte-stack-alignment).

Por cierto asi provoque el mismo error, en cuanto hace un syscall se detecta el problema:

entry:
push dx ;;;;;;;;;;;;;
mov qword ptr [rsp + 030h], 0
mov dword ptr [rsp + 028h], 80
mov dword ptr [rsp + 020h], 2  
mov r9d, 0
mov r8d, 0
mov edx, 040000000h
lea rcx, offset msg
call CreateFileA
int 3

(299c.368c): Break instruction exception - code 80000003 (first chance)
cfe!entry+0x43:
00007ff7`74391043 cc              int     3
0:000> r eax
eax=ffffffff
0:000> !gle
LastErrorValue: (Win32) 0x3e6 (998) - Invalid access to memory location.
LastStatusValue: (NTSTATUS) 0x80000002 - {EXCEPTION}  Alignment Fault  A datatype misalignment was detected in a load or store instruction.

En teoria no deberia ser un problema del primer parametro pasado a CreateFileA, esto funciona por ejemplo:

extrn CreateFileA:   PROC
 
PUBLIC entry
.data
msg db "hello.txt", 0
 
.code
entry:
mov qword ptr [rsp + 030h], 0 
mov dword ptr [rsp + 028h], 80
mov dword ptr [rsp + 020h], 2  
mov r9d, 0
mov r8d, 0
mov edx, 040000000h
lea rcx, offset msg
inc rcx
call CreateFileA

Adivinando (jugar con un depurador e intentar hacer una llamada es algo ambiguo, podes estar escribiendo codigo a mano dentro de la memoria del proceso por ejemplo) te diria que la pila en si misma, RSP, puede estar desalineada.

¿Que parte no entendes de que es un array de punteros a cadena? ¿Ves el *? Tal vez asi lo entiendas mejor:
char *s[20];

---

Un puntero a cadena:
char *s;
20 punteros a cadena:
char *s[20];

Una cadena de 20 caracteres (incluyendo el cero terminador o caracter nulo, si, obviamente):
char s[20];

---

Y si, alguna idea al respecto tengo:


https://foro.elhacker.net/buscador2-t259688.0.html;msg1262234#msg1262234

Son 20 punteros a cadena, si tu respuesta fuera correcta esto imprimiria 20 en pantalla:

char *s[20]= {"hola", "chau" };
printf("%d\r\n", sizeof(s));

¿No lo hace verdad? Lo que imprime es 20 * tamaño de puntero, 160 en x64 por ejemplo.

De nada.

1) mayor es una variable global y su valor inicial es 0 por defecto. ¿Que crees que deberia ser? Es eso o un valor indefinido ya que no inicializaste la variable ... por suerte no hace falta al ser una variable global.



2) No pero NO estas respetando los valores que tienen la pila segun a tu codigo.

Este es el orden de los valores que top va a devolver en cada iteracion:
10
3
20
40
35

En ningun momento top es 20 y mayor 40, no tiene logica alguna, cuando top es 20 mayor es 10, y despues cuando top es 40 mayor es 20 ... no es muy complicado de seguir esto realmente pone un cout con los valores si se te complica tanto.

Justo despues del while:

	cout << "top es " << pila.top() << " mayor es " << mayor << endl;

top es 10 mayor es 0
top es 3 mayor es 10
top es 20 mayor es 10
top es 40 mayor es 20
top es 35 mayor es 40

Iteracion 0:
top() devuelve 10 y mayor es 0, mayor pasa a ser 10
Iteracion 1:
top() devuelve 3 y mayor es 10, la condicion no se cumple
Iteracion 2:
top() devuelve 20 y mayor es 10, mayor pasa a ser 20
Iteracion 3:
top() devuelve 40 y mayor es 20, mayor pasa a ser 40
Iteracion 4:
top() devuelve 35 y mayor es 40, la condicion no se cumple

De nadas 

Si rax es -1 quiere decir que fallo y entonces hay que llamar a GetLastError.

LastErrorValue: (WinSock) 0x273f (10047) - An address incompatible with the requested protocol was used.


ws2_32!connect:
mov     rax,rsp
mov     qword ptr [rax+8],rbx
mov     qword ptr [rax+10h],rbp
mov     qword ptr [rax+18h],rsi

Antes de poder usar la memoria del segundo parametro, RDX, esta ya fue modificada por el prologo de connect para preservar registros.

"In the Microsoft x64 calling convention, it is the caller's responsibility to allocate 32 bytes of "shadow space" on the stack right before calling the function (regardless of the actual number of parameters used), and to pop the stack after the call.

For example, a function taking 5 integer arguments will take the first to fourth in registers, and the fifth will be pushed on top of the shadow space. So when the called function is entered, the stack will be composed of (in ascending order) the return address, followed by the shadow space (32 bytes) followed by the fifth parameter."

https://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention

En definitiva tu programa no cumple con la convencion de llamada, justo despues de la direccion de retorno esta ubicado el segundo parametro de connect.