1 得到崩溃代码行

用windbg分析后，得出如下崩溃代码行，关于如何分析Crash见：Dump调试

崩溃代码行

2 显示最近的一条异常记录

输入：exr -1

显示最近的一条异常记录

3 分析崩溃原因

通过“Attempt to write to address 0000001c”得知，崩溃是由于访问了某个空指针对象成员变量导致的异常

4 切换到异常线程

输入：ecxr

切换到异常线程

5 查看调用堆栈

点击菜单：View->Call Stack，打开堆栈对话框

Call Stack

6 查看Locals

点击菜单：View->Locals，打开Locals对话框，也就是VS里的局部变量对话框

Locals

7 找到空指针位置

在双击堆栈信息时，Locals中的值自动刷新成当前堆栈的值。
此时，我们查看的是最后一条堆栈的值，可以发现此时this指针不为空（如果当前this指针为空，则可以回溯上一层堆栈继续查找），则空指针基本可以断定是此处的函数调用返回的：getHeader(sData)->setColumn(nColumn);

8 印证空指针位置

8.1 getHeader有可能返回

getHeader

8.2 成员变量位置与崩溃地址对应上

8.2.1 找到崩溃时，访问的成员变量

访问的成员变量为：m_nColumn

setColumn

8.2.2 查看成员变量在类中的位置

m_nColumn位置

8.2.3 成员变量在类中的偏移

前提：工程以4字节对齐，在VS2010下vector默认占用16字节（VS2013下占用12字节），QString占用4字节，bool占用1字节（3个紧挨的bool变量，总共占用4字节，Debug下一个bool变量占用4字节），枚举占用4字节。
根据前提，m_nColumn相对于持有者来说，地址偏移应该是：16+4+4+4=28，即0000001c，也就是崩溃时，访问的内存地址。

8.3 验证地址偏移

创建一个测试工程，将截图m_nColumn位置中的变量作为测试类的成员变量，创建一个该类的空指针，查看地址偏移，通过下图中可以看出，我们在8.2.3中的计算式正确的

地址偏移

注：
a 不要在Debug下查看地址偏移，因为偏移可能不一样，如：Debug下bool变量占用4字节
b 验证时，需要使用同样的编译器，因为不同编译器同一类型变量占用空间可能不一样，如：定一个vector变量在VS2010下占用16字节，而在VS2013下占用12字节

9 结束

到此为止，我们已经能够确认该崩溃是由getHeader(sData)返回空指针引起的。