为何WinDbg中32位WriteFile断点用esp+0x0C而非esp+0x08？

你遗漏的核心细节是函数入口处esp指向的是返回地址而非第一个参数，再加上同步写入场景的特殊情况，导致这个命令看起来能正常工作：

1. _stdcall调用下的栈布局核心误区 #

32位_stdcall调用约定的关键规则：

• 调用者按右到左的顺序压入函数参数
• 执行call指令时，会将当前指令指针（返回地址）压入栈，进入函数后esp指向这个返回地址，而非第一个参数。

以WriteFile为例，调用流程的栈变化：

• 调用者依次压入：lpOverlapped（第5个参数）→ lpNumberOfBytesWritten（第4个参数）→ nNumberOfBytesToWrite（第3个参数）→ lpBuffer（第2个参数）→ hFile（第1个参数）
• call kernel32!WriteFile执行后压入返回地址，此时函数入口的栈布局为：
  • esp+0x00：返回地址
  • esp+0x04：第1参数hFile
  • esp+0x08：第2参数lpBuffer
  • esp+0x0C：第3参数nNumberOfBytesToWrite（期望写入的字节数）
  • esp+0x10：第4参数lpNumberOfBytesWritten（指向存储实际写入字节数的指针）

2. 命令“正常工作”的实际原因 #

你提到的命令中，poi(esp+0x0C)取到的本质是期望写入的字节数nNumberOfBytesToWrite，而非实际写入的字节数。但在同步写入且操作完全成功的场景下，Windows会将实际写入的字节数设置为与nNumberOfBytesToWrite相等，因此这个命令看起来能正确显示写入的字节数。

如果是异步写入，或者写入操作仅完成部分数据，这个命令就会输出错误值——此时需要通过poi(poi(esp+0x10))来获取lpNumberOfBytesWritten指针指向的实际写入字节数。

内容的提问来源于stack exchange，提问作者learn99