验证同一EXE中不同DLL各自使用对应路径FIPS.dll的方法咨询

嘿，这个场景我之前排查过类似的DLL加载依赖问题，给你分享几个实用的验证方法，帮你确认A.dll和B.dll各自调用的是对应路径下的fips.dll：

• 使用Process Explorer工具（Windows平台）

  1. 启动Process Explorer，找到运行中的App.exe进程，右键点击它选择「Properties」（属性）
  2. 切换到「Modules」（模块）标签页，这里会列出所有被App加载的模块，你能看到两个同名的fips.dll
  3. 分别右键每个fips.dll条目，选择「Properties」查看「Image Path」，确认它们分别来自c:/App/A/和c:/App/B/路径
  4. 要关联到调用它们的DLL：点击Process Explorer顶部菜单栏的「Find > Find Handle or DLL」，输入fips.dll进行搜索，搜索结果里会明确显示是哪个模块（A.dll或B.dll）持有该DLL的句柄，这样就能精准对应上调用关系了

• 借助WinDbg调试器分析

  1. 用WinDbg附加到正在运行的App.exe进程
  2. 输入调试命令 lm，这个命令会列出所有已加载的模块，找到两个fips.dll的加载基址（比如来自A路径的基址是0x00007FF612340000，来自B路径的是0x00007FF656780000）
  3. 你可以输入命令 !dlls 查看模块的加载上下文，或者找到fips.dll的某个导出函数（比如常见的FIPS_Validate），用 x fips!FIPS_Validate 得到函数的内存地址
  4. 给这个函数设置断点（比如 bp 0x00007FF612341234，地址是函数的实际内存位置），当断点触发时，用 k 命令查看调用栈，调用栈的上层就能看到是A.dll还是B.dll发起的调用，从而确认对应关系

• 文件名替换快速验证（测试环境专用）
  这个方法简单粗暴但有效，适合快速验证，务必仅在测试环境操作：

  1. 关闭运行中的App.exe，将c:/App/A/fips.dll重命名为fips_A.dll
  2. 启动App.exe，如果A.dll出现FIPS相关功能初始化失败的报错（比如日志里提示无法加载fips.dll），说明A.dll确实依赖c:/App/A/路径下的fips.dll
  3. 恢复A路径下的文件名后，再将c:/App/B/fips.dll重命名为fips_B.dll，重复上述步骤，通过B.dll的报错情况确认它的依赖路径

内容来源于stack exchange