1 得到崩溃代码行
用windbg分析后，得出如下崩溃代码行，关于如何分析Crash见：Dump调试
2 显示最近的一条异常记录
输入：.exr -1
3 分析崩溃原因
通过“Attempt to write to address 0000001c”得知，崩溃是由于访问了某个空指针对象成员变量导致的异常
4 切换到异常线程
输入：.ecxr
5 查看调用堆栈
点击菜单：View->Call Stack，打开堆栈对话框
6 查看Locals
点击菜单：View->Locals，打开Locals对话框，也就是VS里的局部变量对话框
7 找到空指针位置
在双击堆栈信息时，Locals中的值自动刷新成当前堆栈的值。
此时，我们查看的是最后一条堆栈的值，可以发现此时this指针不为空（如果当前this指针为空，则可以回溯上一层堆栈继续查找），则空指针基本可以断定是此处的函数调用返回的：getHeader(sData)->setColumn(nColumn);
8 印证空指针位置
8.1 getHeader有可能返回
8.2 成员变量位置与崩溃地址对应上
8.2.1 找到崩溃时，访问的成员变量
访问的成员变量为：m_nColumn
8.2.2 查看成员变量在类中的位置
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)返回空指针引起的。
