YAML管道运行exe时System.Data.SQLite.DLL加载失败引发DllNotFoundException

报错核心特征：流水线环境下程序运行触发 System.DllNotFoundException，对应HRESULT错误码 0x8007045A 为DLL初始化例程执行失败，并非单纯的目标DLL文件缺失——即便已将DLL放置到exe同目录，只要满足触发条件就会复现报错。

核心故障成因与对应修复 #

• 架构位不匹配
  System.Data.SQLite是无托管包装的原生非托管DLL，不存在跨架构兼容能力。若流水线执行进程为32位（例如老版本Windows部署代理默认以32位模式运行），但放置的DLL为64位版本，会直接触发初始化失败。
  修复操作：核对流水线节点的执行进程架构，放置与架构完全匹配的System.Data.SQLite.DLL，保证和托管exe的目标平台编译配置对齐；如果exe配置为AnyCPU编译，需要明确指定流水线节点的运行位数，避免自动架构选择错配。
• 流水线环境缺失VC运行时依赖
  流水线的干净构建镜像通常不会预装完整的VC可再发行运行库，而System.Data.SQLite原生DLL强依赖对应版本的VC运行库文件才能完成初始化。当依赖的vcruntime140.dll、msvcp140.dll等文件无法在进程空间加载时，就会抛出初始化失败错误。
  修复操作：在流水线执行程序的前置步骤中，静默安装和System.Data.SQLite编译版本匹配的VC可再发行包，对应执行命令参考：

  vc_redist.x64.exe /install /quiet /norestart
  

  （如果是32位程序，替换命令中的x64为x86即可；不要尝试将VC运行库文件直接拷贝到exe目录绕开安装，部分Windows版本会对非系统目录的原生DLL加载做安全拦截）
• 执行目录权限不足
  YAML流水线的执行代理通常以低权限服务账号运行，如果exe所在的临时工作目录未给服务账号授予读取、执行权限，即便DLL文件实际存在，系统也无法完成内存映射加载，触发初始化失败。
  修复操作：核对流水线工作目录的权限配置，给执行代理账号授予对应路径的读取&执行权限；不要将程序放置在需要管理员提权才能访问的系统保护路径下，可先将程序移动到流水线默认的工作根目录（如D:\a\1\s\）下执行，快速排除权限拦截的影响。
• 加载路径被环境变量污染
  YAML流水线默认会将大量临时工具路径追加到系统PATH环境变量中，可能存在路径靠前的位置存在同名的损坏/架构不匹配的System.Data.SQLite.DLL，被优先加载后触发初始化失败，导致真正放置在exe目录下的目标DLL完全没有被调用。
  修复操作：在流水线启动exe的步骤中，显式将exe所在目录插入到PATH环境变量的最前端，保证目标DLL的加载优先级最高，PowerShell实现参考：

  $env:PATH = "$(Get-Location);$env:PATH"
  # 再执行启动exe的命令
  

  排查时可通过Process Monitor工具过滤System.Data.SQLite.DLL的加载事件，确认实际被加载的文件路径是否为提前放置的目标文件，快速定位路径抢占问题。

快速排查校验步骤 #

• 手动核对exe目录下System.Data.SQLite.DLL的文件哈希、架构版本，确认流水线的文件拷贝步骤没有被其他来源的同名损坏文件覆盖
• 可以在本地用和流水线相同权限的低权限账号，在全新的Windows Server虚拟机环境下运行程序，复现报错后按上述顺序逐点排查，快速定位根因

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