64位Windows系统下AppInit DLL注入失效问题排查

• DLL与进程架构不匹配
  64位系统里，32位DLL只会被32位进程加载，64位DLL只会被64位进程加载：

  • 若编译的是x86（32位）DLL，只有打开32位GUI应用才会触发弹窗，64位应用不会读取Wow6432Node下的配置；
  • 若编译的是x64（64位）DLL，只有打开64位GUI应用才会生效，32位应用不会读取非Wow6432Node的注册表项。
    去Visual Studio项目属性里确认平台工具集的目标架构是否和测试进程一致。

• 注册表路径或配置错误

  • AppInit_DLLs必须填绝对路径，比如C:\Tools\myInject.dll，不能用相对路径或省略盘符；路径有空格的话要加引号，不过建议直接用无空格路径避免兼容问题。
  • 确认LoadAppInit_DLLs是DWORD类型，值设为1，不是字符串类型；AppInit_DLLs里的路径没有拼写错误，DLL文件确实在对应位置，且当前用户有读取权限（别放Program Files这类需要管理员权限的目录，除非测试进程以管理员身份运行）。
  • 注册表修改后要重启测试进程，部分系统需要重启才能让配置生效。

• Windows安全限制拦截
  从Win7开始，系统默认限制未签名的AppInit DLL：

  • 找到对应注册表路径下的RequireSignedAppInit_DLLs项，若没给DLL做数字签名，必须把这个DWORD值设为0；如果是1，只有微软签名的DLL能被加载，自定义DLL会被直接拒绝。
  • 高权限进程（比如UAC弹窗、系统核心进程）或者沙箱进程（UWP应用）不会加载AppInit DLL，别拿这类进程测试。

• DllMain内的代码问题
  DLL_PROCESS_ATTACH是进程初始化的早期阶段，此时进程的UI环境可能还没准备好，调用MessageBoxA可能失败或者被静默处理。换个方式测试，比如写日志文件：

  if (ul_reason_for_call == DLL_PROCESS_ATTACH) {
      FILE* logFile = fopen("C:\\dll_load_log.txt", "a");
      if (logFile) {
          fprintf(logFile, "DLL loaded into PID: %d\n", GetCurrentProcessId());
          fclose(logFile);
      }
  }
  

  另外，DllMain里尽量别调用复杂UI函数，容易引发死锁或初始化异常。

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