32位编译下按特定顺序加载DLL时单元测试失败

这个问题挺典型的——结合你提到的32位专属问题、延迟加载（/DELAYLOAD）、测试加载顺序差异这些点，我建议从以下几个方向逐步排查：

1. 深挖32位下延迟加载的依赖解析逻辑 #

你用到了/DELAYLOAD，而32位和64位的延迟加载处理在底层细节上有不少差异：

• 先用dumpbin /imports dll1.dll dll2.dll导出两个32位DLL的导入表，对比它们的延迟加载依赖有没有重叠项。如果有某个依赖被两个DLL同时延迟加载，加载顺序的不同可能导致依赖模块的初始化状态不一致。
• 检查项目中有没有自定义的延迟加载错误处理钩子（比如重载__delayLoadHelper2）。这类钩子如果依赖全局状态，在不同加载顺序下可能因为状态未初始化而失效，进而导致DLL无法正确加载。

2. 排查32位地址空间的冲突或初始化问题 #

32位进程的地址空间只有4GB，比64位紧张得多，加载顺序的变化很容易触发地址冲突：

• 用**Process Monitor（ProcMon）**跟踪vstest进程在两种加载顺序下的DLL加载流程，重点看dll1加载时有没有出现“无法找到模块”“内存分配失败”或者“重定位失败”的记录。
• 如果dll1有DllMain函数，在里面加简单的日志输出（比如用OutputDebugString），记录加载时机和返回的错误码——注意DllMain里不能做复杂操作，但足够帮你判断初始化阶段是否出了问题。

3. 检查测试框架的执行上下文初始化差异 #

vstest.console加载DLL的顺序不同，测试框架（比如MSTest、xUnit）的上下文初始化流程也会变化，32位下更容易触发冲突：

• 暂时注释掉dll1和dll2测试项目中的AssemblyInitialize/ClassInitialize这类全局初始化方法，再测试两种加载顺序，排查是不是这些初始化代码修改了全局状态，导致dll1的测试上下文无法建立。
• 给vstest.console加/diag:test_diag.log参数生成诊断日志，对比两种加载顺序下的日志差异——日志里会详细记录测试DLL的加载、上下文初始化的每一步，能帮你定位到失败的具体环节。

4. 梳理DLL之间的隐式依赖关系 #

虽然你说测试不应跨DLL边界，但主代码DLL可能存在你没注意到的隐式依赖：

• 用**Dependency Walker（depends.exe）**打开32位的dll1.dll，梳理它的直接和间接依赖，看是否有依赖项和dll2的依赖重叠。
• 检查系统DLL的版本差异：32位下不同加载顺序可能导致加载不同版本的系统DLL（比如msvcrt.dll、kernel32.dll），进而引发兼容性问题。

5. 对比VS IDE和vstest.console的加载机制 #

VS IDE运行测试时的加载策略和vstest.console不一样，比如它可能提前加载所有依赖，或者用了不同的隔离逻辑：

• 用VS的诊断工具跟踪测试进程，记录DLL的加载顺序，和vstest.console的情况做对比，看有没有关键的差异点。
• 确认/inIsolation参数在两种加载顺序下都正常生效——这个参数会启动一个隔离的子进程运行测试，有时候加载顺序的差异可能导致隔离机制出现异常。

优先从诊断日志和ProcMon的加载跟踪入手，这些工具能帮你快速定位到底是加载阶段的错误，还是测试初始化阶段的问题。

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