概述
Windows 操作系统通过动态链接库（Dynamic Link Library, DLL）机制将常用逻辑抽离为模块，以实现代码复用、功能扩展和内存占用优化。当应用程序或系统组件需要加载 DLL 时，可以显式提供绝对路径，也可以只提供文件名。若未指定路径，系统将按照一套复杂而明确的搜索顺序在多个目录中寻找目标 DLL。
DLL 搜索机制由 Windows 加载器（Loader）负责，其行为受到应用程序类型（打包应用或传统桌面应用）、系统版本、安全配置、应用程序清单（manifest）、加载函数参数以及注册表配置等因素影响。因此理解 DLL 搜索路径对于软件开发、部署安全、故障排查均至关重要。
影响搜索的关键因素
在正式开始搜索 DLL 之前，Windows 会根据内部规则对 DLL 名称进行解释和重定向。以下因素按顺序影响加载过程。
第一，DLL 重定向（Side-by-Side / .local 文件）。
如果应用程序目录中存在一个与主程序同名的 .exe.local 文件，或者存在一个与 DLL 文件同名的 .local 文件，系统将优先从应用程序目录加载该 DLL，而不从系统目录或其他位置加载。这是早期解决 DLL Hell 问题的兼容机制，但现代 Windows 不再推荐使用，主要用于兼容旧程序。
第二，API 集合解析。
Windows 自 Windows 7 起引入 API Set Schema，将 Win32 API 按逻辑功能划分为 “API 集合”（如 api-ms-win-core-synch-l1-2-0.dll）。这些 DLL 是虚拟的，实际会映射到系统核心 DLL（如 kernel32.dll 或 ntdll.dll）。因此，API Set 名称不会按照常规路径搜索，而是由系统重定向。
第三，SxS Manifest 重定向。
应用程序可通过 manifest 清单明确声明依赖 DLL 的特定版本。加载器会根据清单信息定位这些版本，通常用于支持多个版本的通用控件（如 comctl32.dll v5 与 v6）共存。
第四，已加载模块列表。
Windows 会先检查当前进程地址空间。如果 DLL 已经加载，则返回现有模块句柄，这减少了重复加载，提高性能，并防止多个版本的 DLL 同时存在导致冲突。
第五，KnownDLLs。
系统注册表中 KnownDLLs 项列出了部分核心 DLL，这些 DLL 总是从系统目录加载，并通过内存映射共享到所有进程中。这样提高了安全性与性能，并避免 DLL 覆盖攻击问题。
打包应用的 DLL 搜索顺序
所谓打包应用通常指 UWP 应用、MSIX 打包应用、Windows App SDK 程序等。这类应用的运行环境受到操作系统沙盒机制保护，应用的文件系统视图受到限制。
打包应用的 DLL 搜索顺序比桌面应用更严格，主要来源只有：
- 应用包本身
- 声明的依赖包（如 Framework 包）
- 与应用同层级安装的包
- 系统目录中的已知 DLL
扩展的标准搜索顺序如下：
- DLL 重定向
- API 集合解析
- Manifest 并行清单解析（桌面桥应用可能触发）
- 已加载模块检查
- 已知 DLL
- 应用包依赖图（Package Dependency Graph）
- 按照依赖顺序，从 Framework 包、Resource 包、可选包中查找。
- 每个包内部的
System32Redirected目录和VFS虚拟文件系统在此阶段参与。
- 可执行文件所在目录（仅桌面桥应用适用）
- 系统目录（%SystemRoot%\system32）
未打包应用的 DLL 搜索顺序
传统 Win32 桌面应用可以访问更广泛的文件系统目录，因此 DLL 搜索机制更复杂，历史兼容性也要求保留许多老旧路径。
启用安全 DLL 搜索模式是默认行为，此模式改善了早期系统容易被 DLL 劫持的弱点（例如将恶意 DLL 放在当前目录）。搜索顺序为：
- DLL 重定向
- API 集合解析
- Manifest 清单解析
- 已加载模块检查
- 已知 DLL
- Windows 11 21H2 起：检查包依赖图（即使程序未打包）
- 应用程序加载目录（exe 所在目录）
- 系统目录（system32）
- 16 位系统目录（system）
- Windows 根目录
- 当前工作目录（CWD）
- PATH 环境变量
如果禁用了安全模式，当前工作目录会提升到第 8 位，紧挨着应用程序目录之后，这可能造成严重的 DLL 劫持风险。
修改搜索顺序的方法
开发者可通过一系列 API 影响加载器行为，常用于插件加载、便携式软件或安全强化。
比如 LoadLibraryEx 函数，它支持多种标志位，LOAD_WITH_ALTERED_SEARCH_PATH 会优先搜索目标 DLL 所在目录（Full Path 指定时），用于加载同目录依赖项；LOAD_LIBRARY_SEARCH_* 系列标志位可精准控制参与搜索的目录集，彻底排除 PATH 或当前目录等不安全路径。
还有 SetDllDirectory 函数，它可以将一个目录插入默认搜索路径中，仅次于应用程序目录，传入空字符串 "" 会移除当前目录从搜索路径中，这是安全加固的推荐做法。
SetDefaultDllDirectories 函数可覆盖进程的默认搜索策略，一旦设置，系统将忽略 PATH 环境变量除非明确允许。常与 AddDllDirectory 组合使用。
典型安全用法：
SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32 | LOAD_LIBRARY_SEARCH_USER_DIRS);
AddDllDirectory(L"C:\\MyApp\\Plugins");
LOAD_LIBRARY_SEARCH 标志的搜索顺序
使用此类标志后，系统将完全忽略传统目录（如 PATH）。
搜索顺序固定：
- LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR
- 若主 DLL 通过绝对路径加载，该标志允许系统在主 DLL 所在目录搜索其依赖项。
- LOAD_LIBRARY_SEARCH_APPLICATION_DIR
- 程序主 exe 的目录。
- LOAD_LIBRARY_SEARCH_USER_DIRS
- 通过 AddDllDirectory 添加的目录，对顺序不做保证。
- LOAD_LIBRARY_SEARCH_SYSTEM32
- 系统目录。
这些标志应尽量使用，以增强 DLL 加载的确定性和安全性。
依赖项加载规则
即使主 DLL 是通过绝对路径加载的，它的依赖项也不会自动从同一目录加载。
除非启用特定标志（如 LOAD_WITH_ALTERED_SEARCH_PATH 或 LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR），依赖项将：
- 按名称解析（名称不能与路径结合）
- 使用当前进程设置的全部搜索路径
- 可能从系统目录加载旧的或不兼容版本
这可能导致所谓的“DLL Hell”或版本冲突，因此插件系统或便携式应用应谨慎处理依赖项路径。
安全考虑
DLL 搜索路径是攻击者常用的入口，典型攻击包括DLL 劫持（DLL Hijacking）、目录遍历注入、未签名模块替换等。
以下是一些降低风险的方法：
- 采用打包应用（MSIX）部署：天然阻断搜索到用户可写目录，DLL 必须来自包依赖图，提高可靠性。
- 保持安全 DLL 搜索模式启用：减少当前目录攻击风险，Windows 默认是开启的，尽量不要关闭。
- 使用 SetDefaultDllDirectories + AddDllDirectory 进行目录白名单机制：明确控制 DLL 可加载的目录，可将搜索限制到仅系统目录与私有插件目录。
- 检查 DLL 数字签名：关键模块应经过签名验证（如 Authenticode），尤其在加载第三方插件时。
- 避免将用户可写目录（如 %TEMP%，当前目录）置于搜索前列，禁止从不可信路径加载 DLL 是必须的安全策略。
除了理解 Windows 本身的 DLL 加载机制，商业软件往往还需要保护自身 DLL 不被逆向分析或替换。在这方面，可借助诸如 Virbox Protector 的专业保护工具实现 DLL 加密、防调试和完整性校验，减少在复杂环境中的攻击面，提高软件安全性。
总结
Windows 的 DLL 搜索机制既复杂又灵活。它需要兼顾：
- 兼容旧应用
- 提供安全沙箱机制（打包应用）
- 提供精确可控的加载路径（LOAD_LIBRARY_SEARCH）
- 支持 Side-by-Side 版本共存
- 提升性能（KnownDLLs）
开发者应理解不同应用模型的搜索路径差异，并采用现代 API（如 SetDefaultDllDirectories、AddDllDirectory）构建稳定、安全、可预测的模块加载机制。
合理利用打包应用模型或使用 MSIX 能显著减少加载器面临的不确定性，进一步提升软件的部署与运行安全性。
