Golang运行时动态加载自定义DLL的正确方法及调用崩溃排查

• 调用约定不匹配：golang.org/x/sys/windows.Proc.Call()默认遵循Windows系统API的stdcall调用约定（被调用方清理栈），但Go通过-buildmode=c-shared编译出的自定义DLL，导出函数遵循cdecl调用约定（调用方清理栈）。栈清理逻辑不匹配会直接导致栈内存损坏，触发程序崩溃，这也是加载系统DLL正常、加载Go编写的DLL崩溃的核心差异——系统DLL导出函数全为stdcall约定。
• 遗漏必要的资源释放逻辑：原代码加载DLL后没有主动释放句柄，部分场景下会触发DLL卸载时的运行时异常。
• 低概率版本兼容问题：Go 1.18存在数个Windows平台c-shared模式的已知SEH异常处理bug，极端场景下会触发崩溃。

1. 修正主程序调用逻辑 #

核心改动是将默认的Call()替换为专门适配cdecl约定的CallCdecl()方法，同时补充必要的错误处理和资源释放逻辑，修正后的代码如下：

package main

import (
	"log"

	"golang.org/x/sys/windows"
)

func main() {
	// 确保testdll.dll与编译出的exe在同一目录，或已加入系统PATH环境变量
	mod, err := windows.LoadDLL("testdll.dll")
	if err != nil {
		log.Fatalf("加载DLL失败: %v", err)
	}
	defer mod.Release() // 程序退出前释放DLL句柄，避免资源泄漏

	// Go编译的amd64架构c-shared DLL导出符号无额外名字修饰，直接查"FI"即可
	proc, err := mod.FindProc("FI")
	if err != nil {
		log.Fatalf("查找导出函数失败: %v", err)
	}

	// 关键：使用CallCdecl调用cdecl约定的导出函数，禁止用默认的Call(stdcall)
	ret, _, callErr := proc.CallCdecl()
	// Windows API返回的错误码非ERROR_SUCCESS时才视为真错误
	if callErr != nil && callErr != windows.ERROR_SUCCESS {
		log.Fatalf("调用导出函数失败: %v", callErr)
	}
	log.Printf("导出函数执行成功，返回值: %d", ret)
}

主程序编译命令无需改动，保持原参数即可：

GOOS=windows GOARCH=amd64 go build -o myLoader.exe myLoader.go

2. DLL代码注意事项 #

提供的DLL代码逻辑本身没有问题，编译时注意两点即可：

• 必须保证CGO_ENABLED=1，且使用的C编译器（MinGW-w64）架构与目标架构完全匹配（amd64对应x86_64-w64-mingw32-gcc，386对应i686-w64-mingw32-gcc），禁止架构混用。
• 原编译命令可正常使用，Windows本地编译时无需手动指定CC变量，只要正确安装MinGW-w64并加入PATH即可：

CC=x86_64-w64-mingw32-gcc CGO_ENABLED=1 GOOS=windows GOARCH=amd64 go build -buildmode=c-shared -o testdll.dll testdll.go

• EXE和DLL的编译架构必须完全一致，禁止32位程序加载64位DLL，反之亦然，否则会直接加载失败。
• Go编译的c-shared DLL自带独立的Go运行时，和主程序的Go运行时完全隔离，禁止跨DLL边界传递Go原生类型（slice、map、channel、Go指针等），跨边界传参只能使用C兼容的基础类型（整数、浮点数、C字符串、C风格结构体），否则会触发Go运行时内存检查直接崩溃。
• 若编译32位（GOARCH=386）版本，Go编译的DLL导出函数会增加下划线前缀，需要用mod.FindProc("_FI")查找符号，amd64架构无此问题。
• 如果替换CallCdecl()后仍然出现崩溃，可将Go版本升级至1.19及以上，修复1.18版本存在的c-shared模式SEH处理异常问题。

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