调试实战 —— dll 加载失败之 Debug Release 争锋篇

原调试debugwindbgvsdllcrash崩溃全局变量

缘起

最近，项目里遇到一个 dll 加载不上的问题。实际项目比较复杂，但是解决后，又是这么的简单，合情合理。本文是我使用示例工程模拟的，实际项目中另有玄机，但问题的本质是一样的。本文从行文上与《调试实战 —— dll 加载失败之全局变量初始化篇》非常相似，示例代码也非常相似（原谅我比较懒），感兴趣的小伙伴儿可以对比来读。

背景介绍

示例代码中一共有四个工程，一个 exe，三个 dll。其中，Base.vcxproj 是封装了公共接口的工程，会生成 Base.dll。Extension1.vcxproj 和 Extension2.vcxproj 非常相似，会分别生成 Extension1.dll 和 Extension2.dll。MixConfiguration.vcxproj 会生成 MixConfiguration.exe ，该 exe 会加载 Extension1.dll 和 Extension2.dll ，并调用它们的导出函数（象征性的调用）。程序运行起来后，发现只有一个 dll 的功能正常，另外一个 dll 的功能执行不正常。如下图：

run-result

已经通过 dumpbin 确认两个 dll 都有名为 GetCallCount 的函数。但是只有一个调用成功了，另外一个却调用失败。

exports-info

使用 process explorer 观察 dll 加载情况，发现只加载了一个 dll，没发现另外一个 dll。

dll-load-info

与上一个问题一样，如果用 procmon 观察整个加载过程，看到的都是 Success。这里不截图了。直接上调试器。

上调试器

直接在 vs 中按 F5 启动，果然中断到 vs 中了。

callstack-and-exception-info

从上图右侧部分，可以看到完整的调用栈。

简单介绍下相关代码。在 MixConfiguration\Entry.cpp 的第 15 行调用了auto hDll2 = LoadLibraryA("Extension2.dll"); 加载对应的模块。在 Extension2\Extension2.cpp 的第 22 行定义了全局变量 CTest2 g_t2，问题就出在这个全局变量的初始化代码中。

从上图左侧部分可知，错误代码是 0xc0000005，内存访问异常。访问的地址是 0x0000000D，对应的指令地址是 008B7F34。

exception-address

从上图可以看出，确实是挂在了 008B7F34 movsx ecx,byte ptr [eax]。因为 eax 的值是 0xD，我们需要查明 eax 的值为什么是 0xD。相信很多小伙伴都知道，eax 用来保存函数调用的返回值。我们可以把注意力集中到 0x008B7F2c 处的 Call 指令了，调用的是 _Isnil() 成员函数。

查看 vs 提供的源码，如下：

static char& _Isnil(_Nodeptr _Pnode)
{// return reference to nil flag in node
	return ((char&)_Pnode->_Isnil);
}

发现 _Isnil 内部简单的返回了 _Pnode 的 _Isnil 成员。

务必注意： 这里返回的是 char&，返回的是引用！相当于返回的是 _Pnode->_Isnil 的地址！

可以在 Watch 窗口查看传递给 _Isnil() 的参数 _Pnode ，如下：

watch-pnode

可以看到 _Pnode 的值是 0，类型是 std::_Tree_node<...>。

std::_Tree_node 的定义如下：

template<class _Value_type,	class _Voidptr>
struct _Tree_node
{
	_Voidptr _Left;     // offset: 0x0
	_Voidptr _Parent;   // offset: 0x4
	_Voidptr _Right;    // offset: 0x8
	char _Color;        // offset: 0xC
	char _Isnil;        // offset: 0xD
	_Value_type _Myval; // offset: 0x10

private:
	_Tree_node& operator=(const _Tree_node&);
};

从 _Tree_node 的定义可知， _Isnil 的偏移是 0xD （一般，32 位的程序指针占 4 字节，如果是 64 位，那么占 8 字节）。

综上，地址 008B7F2C 处的 call 指令反回 0xD 合情合理。008B7F34 处的指令 movsx ecx,byte ptr [eax] 把返回值保存到 ecx 处，但是因为 eax 的值是 0xD，正常情况下访问 0x0000000D 处的值当然会挂掉了。

至此，我们知道了崩溃的直接原因——访问非法地址。但是根本原因是什么呢？为什么 _Pnode 是 0 呢？

_Pnode 的值来自 _Nodeptr _Pnode = _Root();。根据《调试实战 —— dll 加载失败之全局变量初始化篇》分析的结果， _Root() 函数相当于 &(this->_Myhead->_Parent)。赋值给 _Pnode 后，_Pnode 的值等于 this->_Myhead->_Parent 的值。我们需要观察下 this 的值。

watch-this-content

我们发现 _Parent 的值确实是 0。难道也像上次一样，是没初始化导致的？但是其它成员明明有值，跟上次的情况有些不同。我们需要进一步分析 this 值的来源。

继续深入

查看调用栈，我们发现，this 来自 CTest2 的构造函数里调用的 CObjectManager::GetMap()，这个函数是 Base.dll 的导出函数，返回了一个 GetMap() 中定义的静态变量 s_manager，应该不是初始化顺序的问题了，因为当我们第一次调用 GetMap() 的时候，其内部定义的静态变量会被初始化。那还会是什么问题呢？

想在 vs 中观察下 s_manager 的值，试了几种方式，都不行。

watch-s_manager_type_in_vs

无奈，继续请 windbg 出场。

windbg 出场

打开 windbg，附加到进程，注意一定要勾选 Noninvasive 选项，因为目标进程正在被 vs 调试。

attach-noninvasive

如果没勾选 Noninvasive 选项，会报下图中的错误。

attach-already-being-debugged-process-failed-tip

成功附加后，我们先通过 x Base!*GetMap* 查找到 GetMap 的地址，然后使用 u 004B5830 L20 查看对应的反汇编并查找 s_manager 的地址，发现对应的地址是 004c431c。

find_s_manager_address_by_windbg

我们不能直接 dt s_manager，但是可以 dt 004c431c。

watch-s_manager_in_windbg

观察出问题的 map 对象。对比看下两者有什么不同，如下图：

compare-two-map

注意看上图红色高亮部分，在 Base.dll 中的定义是带 _Myproxy 的，_Myhead 的偏移是 4，而在 Extension2.dll 中，并没有 _Myproxy，自然而然的，_Myhead 的偏移是 0。这是两个不同的 map 类型！

至此，问题已经明确了，s_manager 在两个模块眼中不一样，注意观察上图中地址（黄色高亮部分）都是 0x004c431c。接下来的工作就是找出为什么 s_manager 在 Base.dll 和 Extension2.dll 中不一样。

追本溯源

在 vs 中观察继承关系，如下图：

watch-inherit

从上图可知：_Tree 继承自 _Tree_comp，Tree_comp 继承自 _Tree_buy， _Tree_buy 继承自 _Tree_alloc，_Tree_alloc 又继承自 _Tree_val， _Tree_val 又继承自 _Container_base。而 map 继承自 _Tree。

这里我们只需要关注 _Tree_val 和 _Container_base。

_Tree_val 定义如下（删除了无关信息）：

template<class _Val_types>
class _Tree_val : public _Container_base
{
public:
	typedef typename _Val_types::_Nodeptr _Nodeptr;

    // remove unrelated typedefs and member functions

	_Nodeptr _Myhead;	// pointer to head node
	size_type _Mysize;	// number of elements
};

_Container_base 的定义如下（删除了无关信息）：

#if _ITERATOR_DEBUG_LEVEL == 0
typedef _Container_base0 _Container_base;
#else
typedef _Container_base12 _Container_base;
#endif

可以发现，如果 _ITERATOR_DEBUG_LEVEL 是 0，_Container_base 就等价于 _Container_base0。否则 _Container_base 等价于 _Container_base12。

继续观察_Container_base0 和 _Container_base12 的定义。

_Container_base0 的定义如下：

struct _CRTIMP2_PURE _Container_base0
{
	void _Orphan_all() {}
	void _Swap_all(_Container_base0&) {}
};

_Container_base12 的定义如下（删除了无关的成员函数）：

struct _CRTIMP2_PURE _Container_base12
{
public:
	// remove unrelated member functions
	_Container_proxy *_Myproxy;
};

也就是说，_ITERATOR_DEBUG_LEVEL 不同的时候，map 占用的内存是不一样的。我在项目中遇到的正是这个问题。

水落石出

知道 _ITERATOR_DEBUG_LEVEL 会导致 map 的内存结构不一样，我们还需要进一步查找是哪里导致了 _ITERATOR_DEBUG_LEVEL 的值不一样。在整个解决方案搜索 _ITERATOR_DEBUG_LEVEL。

find-the-culprit

发现，Extension2.vcxproj 中的 stdafx.h 中定义了 #define _ITERATOR_DEBUG_LEVEL 0。如果没有显式定义，该宏的值受 _HAS_ITERATOR_DEBUGGING 影响。一般在 Debug 下，_ITERATOR_DEBUG_LEVEL 的值是 2。可以参考yvals.h 中的定义，截图如下：

iterator_debug_level

至此，我们搞清了整个事情的来龙去脉。总结一下：

由于两个工程的 _ITERATOR_DEBUG_LEVEL 不一样，导致 map 的根基类（ _Container_base ）不一样，从而导致了两个工程眼中的 map 不一样，尤其是 _Myhead 的偏移不一样。间接导致了全局变量 g_t2 在初始化时崩溃，进而导致了对应的 dll 加载失败。