汇编编写Windows Service调用StartServiceCtrlDispatcher遇访问违例错误排查

你遇到的C0000005（访问违例）确实棘手，尤其是空表测试正常、指针也验证过的情况下。结合你提到的stdcall调用约定疑问，咱们可以从几个关键方向排查：

• 先纠正一个可能的核心误解：StartServiceCtrlDispatcher的参数数量
  你说这个调用有2个参数，但实际上Win32 API中StartServiceCtrlDispatcher（不管ANSI还是Unicode版）只有1个参数——指向SERVICE_TABLE_ENTRY数组的指针。如果你的汇编代码错误地压入了2个参数（总计16字节），那栈平衡会完全被破坏，必然触发访问违例。这大概率是问题的源头，先核对API原型：

  // ANSI版
  BOOL StartServiceCtrlDispatcherA(const SERVICE_TABLE_ENTRYA *lpServiceTable);
  // Unicode版
  BOOL StartServiceCtrlDispatcherW(const SERVICE_TABLE_ENTRYW *lpServiceTable);
  

• 检查服务控制表的内存合法性
  即使指针本身有效，也要确认：

  • 数组所在的内存段是可读写的——如果把表放在只读的.text段，函数内部尝试访问时会触发访问违例；
  • 数组的最后一个表项必须是全零（两个NULL指针），这是API的硬性要求；
  • 表项中的服务主函数地址必须是正确的，且符合当前架构（32位/64位）的指针长度。

• 严格遵循stdcall调用约定的栈规则
  stdcall的核心是被调用函数负责清理参数栈，调用者只需要按从右到左的顺序压入参数，然后调用函数即可。如果你在调用后手动用ret 16（或类似指令）清理栈，反而会导致栈溢出/访问错误。举个x86汇编的正确示例：

  ; 假设pServiceTable是服务表指针
  push pServiceTable
  call StartServiceCtrlDispatcherA
  ; 这里不需要手动清理栈，函数会自己ret 4（因为只有1个4字节参数）
  

• 验证寄存器的调用约定兼容性

  • x86架构下，stdcall要求调用者保留EBX、ESI、EDI、EBP寄存器的值，如果你的代码在调用前修改了这些寄存器却没有保存，函数内部可能因寄存器状态异常导致内存访问错误；
  • x64架构下，微软的调用约定要求前4个参数用RCX、RDX、R8、R9传递，其余参数压栈，同时要保留RBX、RBP、RSI、RDI、R12-R15寄存器，别遗漏这些细节。

• 用调试器精准定位错误点
  建议用WinDbg或x64dbg附加到服务进程，在触发访问违例时查看栈回溯和寄存器状态：

  • 确认错误发生在函数内部的哪个步骤？是访问参数指针指向的内存，还是函数内部的栈操作？
  • 检查参数指针的值是否正确，指向的内存内容是否符合SERVICE_TABLE_ENTRY的结构要求。

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