Delphi 11 64位程序加载32位语言DLL引发访问冲突问题

核心原因：跨架构资源格式不兼容 #

64位EXE加载32位语言DLL是触发访问冲突的根本原因。Delphi的资源系统（String Table、RCDATA等）在32位和64位平台下的内存布局、资源头结构存在本质差异：

• 32位DLL的资源段使用32位指针和偏移量，64位EXE解析这些地址时会错误地将其当作64位内存地址访问，直接导致无效内存引用，触发0xC0000005错误。
• 你提到此前64位版本正常运行，大概率是当时使用的是64位版本的语言DLL，而非当前的32位版本。

具体修复步骤 #

• 编译对应架构的语言DLL：为64位EXE单独编译x64版本的语言DLL，确保资源结构与主EXE架构完全匹配。
• 验证DLL架构：用Windows自带的dumpbin工具检查语言DLL的目标架构，确认64位EXE加载的是x64版本：

  dumpbin /headers YourLangDll.dll
  

  查看输出中machine字段，x64对应x64 (AMD64)，x86对应x86。
• 优化加载逻辑：启动时根据主EXE架构自动选择对应版本的DLL，示例代码：

  var
    FileName: string;
  begin
    LoadResStringFunc := nil; // 禁用字符串缓存
    if Win64 then
      FileName := 'LangDll_x64.dll'
    else
      FileName := 'LangDll_x86.dll';
    NewInstance := LoadLibraryEx(FileName, 0, LOAD_LIBRARY_AS_DATAFILE);
    if NewInstance <> 0 then
      LibModuleList.ResInstance := NewInstance;
  end;
  

• 检查项目配置：在翻译DLL的Delphi项目中，确认目标平台设置为对应架构（Project > Options > Building > Target Platforms），避免强制编译为32位。

额外注意事项 #

• LOAD_LIBRARY_AS_DATAFILE标记仅将DLL作为数据文件加载，不执行代码，但资源解析仍依赖架构匹配，该标记无法解决跨架构资源访问问题。
• 若需跨架构共享翻译内容，可改用纯文本格式（如JSON、INI）存储翻译信息，绕过平台相关的资源系统限制。

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