Go编写的32位Windows DLL写入char*参数时触发访问违例

核心问题 #

32位Windows环境中，用Go编写的替代DLL被无源码C/C应用运行时加载时，接收的char*指针地址异常，写入内存触发访问违例；同款功能的C DLL可正常运行，且C测试程序编译期链接Go DLL也能正常工作。报错信息：

Access violation at address 755EF448 in module 'msvcrt.dll'. Write of address 0051B3B1

核心原因 #

1. 调用约定不匹配：Windows下多数应用的DLL函数采用__stdcall调用约定，Go默认导出的函数为__cdecl，调用约定不匹配会导致栈失衡，传入的指针地址被篡改。
2. 函数名导出不一致：C++ DLL若通过extern "C"导出函数会避免名字混淆，Go导出的函数名需与原DLL完全一致（包括大小写），否则运行时GetProcAddress获取的函数地址无效或调用逻辑错误。
3. 32位编译参数缺失：若未指定GOARCH=386，Go会默认编译为当前系统架构的DLL，64位DLL在32位系统中加载后会出现指针地址解析错误。

解决方案 #

1. 强制使用__stdcall调用约定导出函数 #

在Go代码中通过cgo指令和编译参数确保调用约定匹配，示例代码：

package main

/*
#include <stdlib.h>
#include <string.h>
*/
import "C"
import "unsafe"

//export TargetFuncName
//go:noescape
func TargetFuncName(buf *C.char) {
    // 将C指针转为unsafe.Pointer，直接操作内存
    dst := unsafe.Pointer(buf)
    // 示例：写入字符串，确保buf有足够空间
    srcStr := C.CString("Go DLL output")
    defer C.free(unsafe.Pointer(srcStr))
    // 用C标准库函数完成内存拷贝，避免Go内存模型干扰
    C.memcpy(dst, unsafe.Pointer(srcStr), C.strlen(srcStr)+1)
}

func main() {} // 必须保留空main函数，用于DLL编译

编译时必须指定32位架构：

GOARCH=386 GOOS=windows go build -buildmode=c-shared -o my_replace.dll my_replace.go

注：//go:noescape指令可阻止Go的栈调整逻辑破坏调用约定，32位环境下必须添加。

2. 严格匹配原DLL的导出函数名 #

• 用dumpbin /exports original.dll查看原C++ DLL的导出函数名（注意是否有下划线前缀、大小写等细节）。
• Go代码中//export后的函数名必须与原导出名完全一致，否则GetProcAddress无法正确获取函数地址。

3. 验证内存写入逻辑 #

• 避免直接用Go字符串/切片转换C指针，改用C标准库函数（memcpy/strcpy）操作内存，确保与C++逻辑完全对齐。
• 若原应用传入的char*有长度限制，需在Go函数中检查写入长度，防止越界写入触发内存保护。

4. 排查运行时加载逻辑 #

确保应用加载DLL时：

• 加载的是32位版本的Go DLL。
• GetProcAddress使用的函数名与Go导出的完全一致（区分大小写）。
• 调用函数时的参数传递、调用约定与原DLL完全匹配。

辅助排查手段 #

• 用dumpbin /exports my_replace.dll检查Go DLL的导出函数名和调用约定，确认与原DLL一致。
• 用x32dbg等调试器附加到应用，对比C++ DLL和Go DLL被调用时传入的指针地址，确认是否因调用约定导致地址偏移。

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