传入全局对象成员指针到WinHttpQueryHeaders未修改其值的原因是什么

问题原因排查 #

不存在任何禁止将全局对象成员指针传入Win32 API（包括WinHttpQueryHeaders）的规则，这类API仅校验传入的指针是否为可写的有效内存地址，不关心内存属于全局区、栈区还是堆区。你遇到的现象可从以下几个方向排查：

1. 调试打印逻辑错误

你当前的调试打印语句本身存在逻辑缺陷，不能作为st.dwSize未被修改的判断依据：

DEBUG_PRINT(("size of buffer: ", &st.dwSize));

括号内的参数是逗号表达式，最终传入DEBUG_PRINT的只有&st.dwSize这一个参数，且格式字符串中没有对应数值的占位符，完全无法正确输出dwSize的实际值。建议直接在调试器中查看st.dwSize对应内存地址的数值变化，不要依赖错误的打印语句判断结果。

2. 结构体成员类型/对齐问题

这是最可能的核心诱因：

• 首先确认st的dwSize成员类型是否确实为DWORD，如果你错误定义为WORD、int（32位下和DWORD兼容但64位下不兼容）等其他类型，又强制将指针转换为LPDWORD传入API，会出现写入异常。
• 其次检查st对应的结构体是否开启了强制非对齐编译（比如使用了#pragma pack(1)这类指令），如果dwSize成员的内存地址不是4字节对齐，Win32 API对传入的DWORD类型指针有严格的对齐要求，非对齐地址的写入会静默失败，导致数值未更新。而栈上分配的局部DWORD变量编译器会自动保证4字节对齐，所以写入正常。

3. 多线程竞争问题

如果st是全局对象，确认是否有其他线程同时在修改dwSize成员，可能出现WinHttpQueryHeaders写入成功后，立刻被其他线程重置为初始值的情况。

快速验证方案 #

你可以通过以下测试快速定位问题：

• 调用WinHttpQueryHeaders前，手动将st.dwSize赋值为0xFFFF这类非0初始值，调用结束后直接在调试器中查看对应内存的数值变化。
• 打印&st.dwSize的地址，确认是否为4的倍数（十六进制地址最后一位为0、4、8、C即为符合要求的4字节对齐）。
• 直接在全局区单独定义一个DWORD g_dwSize变量传入API，看是否能正常写入，如果可以即可确认是st结构体本身的对齐或类型定义问题。

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