2、把优化disable，否则容易产生代码地址偏移；

3、用program database产生PDB文件；

4、将dll, exe, pdb，加上版本号，防止下次开发编译时把老的PDB冲掉。

5、发布的版本，输出到一个固定目录，防止人为删除Debug， Relase导致丢失

6、对于已经稳定的版本dll, exe，编译时，可将优化开启。（虽然偶然有代码地址偏移，但是还可以接受）

7、生成MiniDump时，用MiniDumpWithDataSegs方式，这样，全局变量的值也可查看

    这个方案需要自己动手往工程里添加代码了。要实现上面的想法，需要做两件事情：1、需要在crash时有机会对程序堆栈进行处理；2、对堆栈信息进行收集。

    1、SetUnhandleExceptionFilter函数

    Windows平台下的C++程序异常通常可分为两种：结构化异常（Structured Exception，可以理解为与操作系统相关的异常）和C++异常。对于结构化异常处理（SEH），可以找到很多资料，在此不细说。对于crash错误，一般由未被正常捕获的异常引起，Windows操作系统提供了一个API函数可以在程序crash之前有机会处理这些异常，就是SetUnhandleExceptionFilter函数。（C++也有一个类似函数set_terminate可以处理未被捕获的C++异常。）

    SetUnhandleExceptionFilter函数声明如下：

    LPTOP_LEVEL_EXCEPTION_FILTER WINAPI SetUnhandledExceptionFilter(

      __in          LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter

    );

    其中 LPTOP_LEVEL_EXCEPTION_FILTER 定义如下：

    typedef LONG (WINAPI *PTOP_LEVEL_EXCEPTION_FILTER)(

        __in struct _EXCEPTION_POINTERS *ExceptionInfo

    );

    typedef PTOP_LEVEL_EXCEPTION_FILTER LPTOP_LEVEL_EXCEPTION_FILTER;

    简单来说，SetUnhandleExceptionFilter允许我们设置一个自己的函数作为全局SEH过滤函数，当程序crash前会调用我们的函数进行处理。我们可以利用的是 _EXCEPTION_POINTERS 结构类型的变量ExceptionInfo，它包含了对异常的描述以及发生异常的线程状态，过滤函数可以通过返回不同的值来让系统继续运行或退出应用程序。

    关于 SetUnhandleExceptionFilter 函数的具体用法和示例请参考MSDN。

    2、StackWalker

    现在我们已经有机会可以在crash之前对程序状态信息进行处理了，只需要生成并保存堆栈信息就大功告成了。Windows的dbghelp.dll库提供了一个函数可以得到当前堆栈信息：StackWalk64（在Win2K以前版本中为StackWalk）。该函数声明如下：

    BOOL WINAPI StackWalk64(

      __in          DWORD MachineType,

      __in          HANDLE hProcess,

      __in          HANDLE hThread,

      __in_out      LPSTACKFRAME64 StackFrame,

      __in_out      PVOID ContextRecord,

      __in          PREAD_PROCESS_MEMORY_ROUTINE64 ReadMemoryRoutine,

      __in          PFUNCTION_TABLE_ACCESS_ROUTINE64 FunctionTableAccessRoutine,

      __in          PGET_MODULE_BASE_ROUTINE64 GetModuleBaseRoutine,

      __in          PTRANSLATE_ADDRESS_ROUTINE64 TranslateAddress

    );

    该函数的具体用法可以参考MSDN。在这里推荐一个牛人写好的StackWalker，可以直接拿来用，开源的。StackWalker提供了一个基类，给出了几个简单的接口，可以方便地生成堆栈信息，并且支持一系列VC版本，非常好用。我们可以自己写一个子类，并重载虚函数OnOutput，就可以将堆栈信息输出为特定格式了。StackWalker的地址为：http://www.codeproject.com/KB/threads/StackWalker.aspx。

    不过对于Release版本来说，StackWalk64函数获得的堆栈信息有可能不完整。如果异常是由MFC的模块抛出，那么获得的堆栈可能缺少前面调用模块信息。另外，StackWalk64需要最新的dbghelp.dll文件支持才能工作；要正确输出crash的函数名和行号，需要要pdb文件支持。以上不足有可能影响输出信息的完整性和效果，而对于发布在外的程序，要带上pdb文件几乎不可能，因此这个方案还是有缺憾的，比较适用于本地的release版本调试。

当我们把自己的release版本程序发布出去以后，一般都是在用户的机器上运行。这种情况下，对于第四种方案，因为需要pdb文件才能够正确生成堆栈调用的函数行号及代码行号，因此方案四只适用于本地release版的调试，否则只能生成不完整的堆栈信息。对于前三种方案，其实只需要用户告知崩溃地址，然后在本地查找crash地址就可以了，但是定位crash的过程非常不方便，如果crash的情况比较多，前三种方案都不合适。而且，前三种方案均不能生成堆栈调用信息，对于debug的作用有限。

    下面我们就来看一个更加完善的解决方案。

    方案五：SetUnhandledExceptionFilter + Minidump

    SetUnhandleExceptionFilter函数我们已经介绍过了，本方案的思路还是要利用我们自己的异常处理函数，来生成minidump文件。

    1、Minidump概念

    minidump（小存储器转储）可以理解为一个dump文件，里面记录了能够帮助调试crash的最小有用信息。实际上，如果你在 系统属性 -> 高级 -> 启动和故障恢复 -> 设置 -> 写入调试信息 中选择“小内存转储(64 KB)”的话，当系统意外停止时都会在C:\Windows\Minidump\路径下生成一个.dmp后缀的文件，这个文件就是minidump文件，只不过这个是内核态的minidump。

   我们要生成的是用户态的minidump，文件中包含了程序运行的模块信息、线程信息、堆栈调用信息等。而且为了符合其mini的特性，dump文件是压缩过的。

    2、生成minidump文件

    生成minidump文件的API函数是MiniDumpWriteDump，该函数需要dbghelp.lib支持，其原型如下:

    BOOL WINAPI MiniDumpWriteDump(

      __in          HANDLE hProcess,

      __in          DWORD ProcessId,

      __in          HANDLE hFile,

      __in          MINIDUMP_TYPE DumpType,

      __in          PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,

      __in          PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,

      __in          PMINIDUMP_CALLBACK_INFORMATION CallbackParam

    );

    在我们的异常处理函数中加入以下代码：

    HANDLE hFile = ::CreateFile( _T("E:\\dumpfile.dmp"), GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

     if( hFile != INVALID_HANDLE_VALUE)

     {

         MINIDUMP_EXCEPTION_INFORMATION einfo;

         einfo.ThreadId = ::GetCurrentThreadId();

         einfo.ExceptionPointers = pExInfo;

         einfo.ClientPointers = FALSE;

        ::MiniDumpWriteDump(::GetCurrentProcess(), ::GetCurrentProcessId(), hFile, MiniDumpNormal, &einfo, NULL, NULL);

        ::CloseHandle(hFile);

     }

    其中，pExInfo变量为异常处理函数PEXCEPTION_POINTERS类型的参数。具体请参考MSDN。

    3、调试minidump

    调试dump文件首先需要pdb文件，因此我们build程序时需要设置 Debug Infomation Format 为 “Program Database（/Zi）”。其次，我们还要确保所用的dump文件与源代码、exe、pdb文件版本是一致的，这要求我们必须维护好程序版本信息。

    调试minidump最方便的环境就是VS了，我们只要将.dmp、.exe、.pdb文件放在一个路径下，保证源代码文件的路径与编译时的路径一致就可以了，剩下的就是VS帮我们完成。双击.dmp文件或者在文件打开工程中选择“dump files”，加载dump文件，然后按F5运行就能直接恢复crash时的现场了，你可以定位crash的代码，可以查看调用堆栈，可以查看线程和模块信息...一切都跟你设置断点调试一样，太强大了！看个截图吧。

    需要注意的是，对于release版的程序来说，很多代码是经过编译器优化过的，因此定位的时候可能会有所偏差，大家可以考虑设置选项去掉代码优化。

    其他可以调试minidump的工具还有WinDbg等，大家可以查阅相关资料。

为了测试这个API, 参考网上一些资料, 写了一个简单的C++ 程序. 目的是当有异常发生的时候, 自动生成Dump文件供之后的分析. 有了Dump文件, 我们就可以使用WinDBG等调试器来分析异常发生时的情况. 其实这个功能很多软件都有, 比如QQ, 魔兽世界, 等等. 它们在出现了异常的时候会弹出一个对话框, 让用户输入异常发生时的情况, 然后把异常的dump文件用email发回, 供开发者们分析修改bug.

不过有一点, 这里需要程序的调试符号文件(pdb文件). 对于Debug版来说, 是生成的, 但是Release版来说默认是不生成的. 可以设置VC的编译器, 让它在Release版的时候也生成调试信息. 这带来一个新的问题, 因为.pdb里面是保存了源文件的信息的, 为了避免泄密, 可以采用VS中的CVPack工具, 从中去除敏感的信息.

程序需要使用Dbghelp.h 和 Dbghelp.lib . 它们可以从MSDN找到.

//最主要的函数, 生成Dump
static void DumpMiniDump(HANDLE hFile, PEXCEPTION_POINTERS excpInfo)
{
if (excpInfo == NULL) //如果没有传入异常, 比如是在程序里面调用的, 生成一个异常
{
// Generate exception to get proper context in dump
__try
{
OutputDebugString(_T("raising exception\r\n"));
RaiseException(EXCEPTION_BREAKPOINT, 0, 0, NULL);
}
__except(DumpMiniDump(hFile, GetExceptionInformation()),
EXCEPTION_CONTINUE_EXECUTION)
{
}
}
else
{
OutputDebugString(_T("writing minidump\r\n"));
MINIDUMP_EXCEPTION_INFORMATION eInfo;
eInfo.ThreadId = GetCurrentThreadId(); //把需要的信息添进去
eInfo.ExceptionPointers = excpInfo;
eInfo.ClientPointers = FALSE;

    // 调用, 生成Dump. 98不支持
// Dump的类型是小型的, 节省空间. 可以参考MSDN生成更详细的Dump.
MiniDumpWriteDump(
GetCurrentProcess(),
GetCurrentProcessId(),
hFile,
MiniDumpNormal,
excpInfo ? &eInfo : NULL,
NULL,
NULL);
}
}

下面的是程序部分:

int _tmain(int argc, _TCHAR* argv[])
{
// 创建一个Dump文件
HANDLE hFile = CreateFile( _T("MiniDump.dmp"), GENERIC_READ | GENERIC_WRITE,
0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL );
int code;
__try
{  
// 把自己实现的main函数包装一下, 放在try .. except 块中. 这样出现了异常可以自动生成dump
main_wrapper(argc, argv);
}
__except( code=GetExceptionCode(), DumpMiniDump(hFile, GetExceptionInformation() ),       EXCEPTION_EXECUTE_HANDLER ) //出现了异常, 记录异常的code, 生成dump!!
{
printf("%x\n", code);
wchar_t msg[512];
wsprintf(msg, L"Exception happened. Exception code is %x", code);
MessageBox(NULL, msg, L"Exception", MB_OK); //显示消息给用户
}
CloseHandle( hFile ); //关闭Dump文件
getchar();
return 0;
}

最下面是两个测试的函数, main_wrapper函数将调用test1, test1将会生成一个异常(非法内存写)

void test1() {
int *p;
p = (int*)0x100;
*p = 0; //写0x100地址, 这个是非法的
}

void main_wrapper(int argc, _TCHAR* argv[]) {
test1();
}

运行, 异常被捕获了:

同时, dump文件也生成了:

用WinDBG打开Dump文件, 可以清楚的看出异常出现的情况:




从中可以比较清楚的看到异常发生的情况(Exception code), 异常出现的地址(test1函数, 偏移0x28). 因为这次测试的是Debug版, 有保存了源代码的.pdb文件, 所以WinDbg把源代码也列出来了. 这样可以非常容易的发现问题.

============================================

参考:
DbgHelp中的DumpAPI例子: http://www.debuginfo.com/examples/src/effminidumps/MiniDump.cpp
CrashReport: 程序出现异常的时候显示发送错误的对话框, 并把Dump文件发送到指定的地址. http://code.google.com/p/crashrpt/
XCrashReport: 与上面的类似的一个开源项目. http://www.codeproject.com/KB/debug/XCrashReportPt1.aspx

　　符号文件（Symbol Files）是一个数据信息文件，它包含了应用程序二进制文件（比如：EXE、DLL等）调试信息，专门用来作调试之用，最终生成的可执行文件在运行时并不需要这个符号文件，但你的程序中所有的变量信息都记录在这个文件中。所以调试应用程序时，这个文件是非常重要的。用 Visual C++ 和 WinDbg 调试程序时都要用到这个文件。
　　在 Windows 系统中，符号文件以 .pdb 为扩展名，比如：每个 Windows 操作系统下有一个 GDI32.dll 文件，编译器在编译该 DLL 的时候会产生一个 GDI32.pdb 文件，一旦你拥有了这个 PDB 文件，那么便可以用它来调试并跟踪到 GDI32.dll 内部。该文件和二进制文件的编译版本密切相关，比如修改了 DLL 的输出函数，再编译该 DLL，那么原先的 PDB 文件就过时了，不能再用老的 PDB 文件来做调试工作,而必须使用最新的 PDB 文件版本。
　　Visual C++ 编译代码后会在 Debug 或者 Release 目录下生成一个 PDB 文件。一般情况下，符号文件包括以下的数据信息：

1. 全局变量（Global variables）；
2. 局部变量（Local variables）；
3. 函数名和它们的入口地址（Function names and the addresses of their entry points）；
4. FPO 数据（Frame Pointer Omission)：Frame Pointer 是一种用来在调用堆栈（Call stack）中找到下一个将要被调用的函数的数据结构源代码的行序号（Source-line numbers）；

二、如何得到和安装符号文件?

1. 先确定你的操作系统（OS）版本；
2. 到微软网站下载相应的符号文件；
3. 安装符号文件，对于符号文件的安装位置没有特贝要求，可以安装在任何目录中；
4. 设置环境变量，使得调试工具（比如：Visual C++、WinDbg、Ntsd、DrWatson 等）能找到符号文件；

安装符号文件的注意事项：

　　如果是手动安装符号文件，有一点很重要，那就是宿主机（Hostt Computer）上的符号文件必须与目标机器（Target Computer）上的 Windows 版本相匹配。
　　这里所谓的宿主机指的是运行调试会话的机器，在典型的双系统调试会话环境中，宿主机可以是连接到目标机器的任何机器。目标机器指的是发生软件组件、系统服务、应用程序或操作系统运行失败的机器。也即是需要被调试的机器，它是调试会话关注的焦点。目标机器可以近在咫尺，也可以位于完全不同的地方。有时我们也将目标机器称之为——被调试者（debuggee），那么与之对应，宿主机则可以称为调试者（debugger）。

三、在 Visual C++ 使用符号文件的方法

在 Visual C++ 6.0 中的使用方法：

1. 打开 Visual C++ 6.0 的 Workspace 文件（*.dsw）；
2. 进入 Tools 菜单，选择 Options 菜单项 (Tools->Options)；
3. 单击 Directoties 标签；
4. 在 “Show directories for”下拉列表中选择 “Executable files”；
5. 将符号文件的路径添加到 “Directories” 路径列表中；
6. 单击  OK 完成；

在 Visual C++ .NET 2003 中的使用方法：

1. 打开 Visual C++ .NET 的项目文件（*.vcproj）；
2. 在解决方案管理器中选中要使用符号文件的项目；
3. 单击右键进入项目属性对话框；
4. 选择“配置属性”中的“调试”；
5. 在与“调试”对应的“操作”选项中有一个“符号路径”，在此添加符号文件的路径即可；
6. 单击  “确定” 完成；

四、如何产生 Release 版本二进制文件对应的 PDB 文件?

在 Visual C++ 6.0 中的方法：

1. 打开 Visual C++ 6.0 的 Workspace 文件（*.dsw）；
2. 进入 Project 菜单，选择 Settings 菜单项 (Project->Settings)，打开项目设置对话框；
3. 在 “Settings for”列表中选择项目的 Release 配置；
4. 单击“C/C++”标签；
5. 在“Category”下拉列表框中选择“General”选项；
6. 在“Debug info”下拉列表框中选择调试信息格式（具体选项参见图一），在此不必禁用任何优化选项；
7. 单击“Link”标签；
8. 在“Category”下拉列表框中选择“Debug”选项；
9. 选中“Debug info”复选框，然后选择需要的链接调试类型（具体选项参见图一）；
10. 不要选择“Separate types”复选框；
11. 在“Project options”编辑框的最后添加如下指令：/opt:ref,icf；
12. 重新生成（Rebuild）项目；

在 Visual C++ .NET 2003 中的方法：

1. 打开 Visual C++ .NET 的项目文件（*.vcproj）；
2. 进入 Project 菜单，选择 Settings 菜单项 (Project->Settings)，打开项目设置对话框；
3. 在 “配置”下拉列表中选择项目的 “（活动）Release” 配置；
4. 选择“配置属性”树型节点中的“C/C++” ==〉“常规”；
5. 设置右边的“调试信息格式”选项（具体选项参见图一）；
6. 选择“配置属性”树型节点中的“链接器”==〉“调试”；
7. 设置右边的“生成程序数据库文件”（具体选项参见图一）；
8. 选择“配置属性”树型节点中的“链接器”==〉“命令行”；
9. 在“附加选项(D)”编辑框中添加如下指令：/opt:ref,icf；
10. 按“确定”退出；
11. 重新生成（Rebuild）项目；

图一

五、关于 Free Build（也称 Retail Build）和 Checked Build（也称 Debug Build）

每个基于 NT 操作系统有两种不同的程序生成模式，即：

• Free Build (或 Retail Build)
• Checked Build (或 Debug Build)

　　Free Build 生成的是最终用户版本，针对生成的二进制文件进行了彻底的优化，禁用了调试断言，并剥离了调试信息。这样一来使可执行程序文件更小，加载更快，使用的内存也更小。
　　Checked Build 生成的是测试和调试版本。它包含额外的 Free Build 所没有的错误检查，参数验证和调试信息，Checked Build 有助于隔离和跟踪可能导致不可预见的行为的问题，比如内存溢出，不正确的设备配置。虽然 Checked Build 提供了额外的保护，但与 Free Build 比较，它需要更多的内存开销和磁盘空间。由于可执行程序包含符号调试信息；调试时要执行附加的代码、参数检查和输出调试诊断信息，从而导致性能下降。

六、系统符号文件的更新方法

　　系统符号文件指 Windows 操作系统依赖的那几个重要的 DLL/SYS 和可执行文件对应的符号文件，常见的比如：gdi32.dll、Kernel32.dll、Kerberos.dll、psapi.dll、user32.dll等，使用 WinDbg 调试时，你就会发现系统符号文件(PDB)有多重要，这些文件都与本地的 OS 密切相关，比如，Windows 2000 打了SP补丁的话，那么必须更新系统符号文件才能进行相关调试，原来的符号文件与打补丁后的系统就会不匹配，怎么办呢? 可以通过网络来更新！象下面这样在 WinDbg 的 Symbols Path 里面输入路径：

SRV*D:\Symbols\websymbols*http://msdl.microsoft.com/download/symbols

（斜体部分是你在本地保存符号文件的路径）

　　如果你不是通过代理上网，那么在你用 WinDbg 打开一个被调试程序后，输入 symchk 回车，WinDbg 就会自动的连到微软的网站根据你的机器的情况更新的 PDB 文件，并将它保存在上面斜体部分指定的本地路径里，这样你就可以确保你的符号文件版本和你机器上的文件版本一致。

如果你是通过代理上网那么你需要配置 IE 的连接设置。具体方法恕不赘言

void CForDebugDlg::OnOK()

{

       for (int i = 0; i < 1000; i++)    //A

       {

              int k = i * 10 - 2; //B

              SendTo(k);          //C

              int tmp = DoSome(i); //D

              int j = i / tmp;    //E

       }

}     

  执行此函数，程序崩溃于E行，发现此时tmp为0，假设tmp本不应该为0，怎么这个时候为0呢？所以最好能够跟踪此次循环时DoSome函数是如何运行的，但由于是在循环体内，如果在E行设置断点，可能需要按F5（GO）许多次。这样手要不停的按，很痛苦。使用VC6断点修饰条件就可以轻易解决此问题。步骤如下。
  1 Ctrl+B打开断点设置框，如下图：

Figure 1设置高级位置断点
  2 然后选择D行所在的断点，然后点击condition按钮，在弹出对话框的最下面一个编辑框中输入一个很大数目，具体视应用而定，这里1000就够了。
  3 按F5重新运行程序，程序中断。Ctrl+B打开断点框，发现此断点后跟随一串说明：...487 times remaining。意思是还剩下487次没有执行，那就是说执行到513（1000－487）次时候出错的。因此，我们按步骤2所讲，更改此断点的skip次数,将1000改为513。
  4 再次重新运行程序，程序执行了513次循环，然后自动停在断点处。这时，我们就可以仔细查看DoSome是如何返回0的。这样，你就避免了手指的痛苦，节省了时间。
  再看位置断点其他修饰条件。如Figure 1所示，在“Enter the expression to be evaluated:”下面，可以输入一些条件，当这些条件满足时，断点才启动。譬如，刚才的程序，我们需要i为100时程序停下来，我们就可以输入在编辑框中输入“i==100”。
  另外，如果在此编辑框中如果只输入变量名称，则变量发生改变时，断点才会启动。这对检测一个变量何时被修改很方便，特别对一些大程序。
  用好位置断点的修饰条件，可以大大方便解决某些问题。

二 数据断点（Data Breakpoint）
  软件调试过程中，有时会发现一些数据会莫名其妙的被修改掉（如一些数组的越界写导致覆盖了另外的变量），找出何处代码导致这块内存被更改是一件棘手的事情（如果没有调试器的帮助）。恰当运用数据断点可以快速帮你定位何时何处这个数据被修改。譬如下面一段程序：

#include "stdafx.h"

#include

int main(int argc, char* argv[])

{

       char szName1[10];

       char szName2[4];

       strcpy(szName1,"shenzhen");             

       printf("%s\n", szName1);          //A

       strcpy(szName2, "vckbase");              //B

       printf("%s\n", szName1);

       printf("%s\n", szName2);

       return 0;

}

  这段程序的输出是

             szName1: shenzhen

       szName1: ase

       szName2: vckbase

szName1何时被修改呢？因为没有明显的修改szName1代码。我们可以首先在A行设置普通断点，F5运行程序，程序停在A行。然后我们再设置一个数据断点。如下图：

Figure 2 数据断点
  F5继续运行，程序停在B行，说明B处代码修改了szName1。B处明明没有修改szName1呀？但调试器指明是这一行，一般不会错，所以还是静下心来看看程序，哦，你发现了：szName2只有4个字节，而strcpy了7个字节，所以覆写了szName1。
  数据断点不只是对变量改变有效，还可以设置变量是否等于某个值。譬如，你可以将Figure 2中红圈处改为条件”szName2[0]==''''y''''“,那么当szName2第一个字符为y时断点就会启动。
  可以看出，数据断点相对位置断点一个很大的区别是不用明确指明在哪一行代码设置断点。

三 其他
  1 在call stack窗口中设置断点，选择某个函数，按F9设置一个断点。这样可以从深层次的函数调用中迅速返回到需要的函数。
  2 Set Next StateMent命令（debug过程中，右键菜单中的命令）
  此命令的作用是将程序的指令指针（EIP）指向不同的代码行。譬如，你正在调试上面那段代码，运行在A行，但你不愿意运行B行和C行代码，这时，你就可以在D行，右键，然后“Set Next StateMent”。调试器就不会执行B、C行。只要在同一函数内，此指令就可以随意跳前或跳后执行。灵活使用此功能可以大量节省调试时间。
  3 watch窗口
  watch窗口支持丰富的数据格式化功能。如输入0x65,u，则在右栏显示101。
  实时显示windows API调用的错误：在左栏输入@err,hr。
  在watch窗口中调用函数。提醒一下，调用完函数后马上在watch窗口中清除它，否则，单步调试时每一步调试器都会调用此函数。
  4 messages断点不怎么实用。基本上可以用前面讲述的断点代替。
总结
  调试最重要的还是你要思考，要猜测你的程序可能出错的地方，然后运用你的调试器来证实你的猜测。而熟练使用上面这些技巧无疑会加快这个过程。最后，大家如果有关于调试方面的问题，我乐意参与探讨

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

键中的内容来对未处理的异常采取一种统一的行为和方法。

该键中的

Auto: 决定是自动运行调试器，还是让用户决定

Debugger: 是指向调试器可执行文件的路径的字符串

-------------------------------------------------------------------------------------------

据观察，在我装了vs2005之后

"Auto"="1"
"Debugger"="\"C:\\WINDOWS\\system32\\vsjitdebugger.exe\" -p %ld -e %ld"

表示将自动运行调试器

-------------------------------------------------------------------------------------------

而Windows默认的调试器是Dr.Watson

它捕获应用程序应用程序崩溃状态，并记录日志文件（Drwtsn32.log）和进程崩溃转储文件（User.dmp）。

要想查看并配置Dr.Watson，可以在运行中输入Drwtsn32.exe。

要想恢复系统初始状态则可以运行 Drwtsn32 -i

这样注册表的那两个值会变成

"Auto"="1"
"Debugger"="drwtsn32 -p %ld -e %ld -g"

-------------------------------------------------------------------------------------------

3、发生异常的时候为了保留现场堆栈需要冻结进程内其他线程，所使用的操作越少越好。

4、开启另外一个进程对异常进程进行MiniDump。

5、如果要分析崩溃地址是否在某个模块，最好在分析进程里做。或者在模块加载时计算模块区域以便在异常时快速定位。判断崩溃是否和某个模块相关，只能通过分析堆栈里的模块来识别，使用StackWalk函数。StackWalk函数里所使用的context参数要使用异常参数里的ContextRecord，这样能分析在崩溃的时候的堆栈，而不会受后面操作的影响。

6、如果希望自己是第一个被调用，可以在挂链之后用APIHook设置SetUnhandledExceptionFilter返回空。

7、在冻结线程的时候，不要打MessageBox，会导致当前线程因为其他线程挂起而阻死。

8、异常除了SetUnHandledExceptionFliter之外，还有AddVectoredExceptionHandler，相对于前者，后者的优点是能够让异常按照链式触发，不会被中间节点断开。但是AddVectoredExceptionHandler无法在2K下使用。。。

1、  程序编译选项

2、  利用VS2005 分析dump文件

3、  常见问题讨论

一、       程序编译选项

PDB files contains all debug information like type definition and function prototype. When application crashes, we need the PDB files to analyze the root cause, so make sure these PDB files will be created when building it. You must do the following setting:

C/C++\General\Debug Information Format=Program Database (/Zi).

图1.1 调试信息格式

Linker\Debugging\Generate Program Database File=”Name and location of your PDB files”

图1.2 PDB文件输出路径

PDB文件路径最好设置在同一个文件夹中，这样方便dmp文件调试时调用。

调试时，所有的PDB文件和源文件必须严格匹配（the PDB files should be the one generated by build the source code），并存储在一个安全的位置。当客户报告了一个错误时，你需要这些文件来帮忙以便定位错误于源代码中并解决问题。

二、       VS2005 分析dump文件

In this simple application, there is an unhandled Access Violation Reading exception, because GetNameFromDatabase returns a NULL pointer, and this pointer is passed into IsPrefix and then it’s used directly without NULL pointer checking.

图1.3 演示代码

利用Release模式编译该测试程序，在客户机上运行该程序，将根据NTSD设置生成相对应的DMP格式文件。

可以使用Visual Studio.Net、NTSD或是其他的调试工具对DMP格式文件进行分析。

l         Start Visual Studio.Net

Click File\Open Solution and make sure the files of type is *.dmp then click Open.

图1.3 Open Dump File (GUI)

l         Set Symbol Path

Click Tools\Options, Debugging\Symbols，增加PDB文件路径。若调试的程序需要微软基础库的PDB信息，可以增加一个路径为：

http://msdl.microsoft.com/download/symbols

在界面下方Cache Symbol From symbol…选择本地存储这些Symbols的路径。

图1.4 Symbol Path

如果DMP文件没有放入本身PDB文件所在目录，也可以在此处增加一个本地目录。点OK后，VS2005将从网络中下载所需要的Symbols，需要等待一段时间。如果是多次调试同一个程序错误所生成的DMP文件，可以在对话框中选择“Search the above locations only when symbols are loaded manually”。从而可以节省网络带宽。

l         Set Source code path

Open Solution Property Pages and set the source code path.

图1.5 属性菜单

图1.6 Debug Source Files

l         Start to Debug the Dump File

Click the Debug menu, it will ask you to save as a solution, save it. Then it will go to the line which caused the crash of your application.

图1.7 调试窗口，定位到源代码

三、       常见问题讨论

1、  Dump文件放在哪里？

Dump文件不用非要放在你编译出来的位置，你完全可以建立一个新的文件夹来放它。但若不是存放在编译出来的位置，需要将编译生成的PDB文件拷贝到Dump文件目录，或是利用VS2005打开Dump文件后，设置PDB文件路径。参照图1.4。

2、  如何恢复当时的现场？

可能你要问，怎么可能，这个dump文件可是用户发给我的，我不可能去用户家里调试吧？这个恢复现场可不是指的非要到那台机器上去，而是要把产生dump文件对应的二进制文件拿到。

但是恢复现场需要所有的二进制文件都要对应，你一定要有导致用户崩溃的那些Exe和DLL。既然是你发布的程序，Exe文件当然你会有。所以这里只考虑DLL就行了。

Dump文件中记录了所有DLL文件的版本号和时间戳，所以你一定可以同过某种途径拿到它。如果你能从用户那里拿到最好，如果不方便，用户不可能用的是我们平常不常用的操作系统，所以找个有对应系统的机器一般都会有。但是记住不仅是文件名称要一致，还要核对版本和时间戳，如果不同一样没有办法用。

如果客户用了某个特殊的补丁怎么办？

其实这个问题也很好解决，只要它不阻碍阅读堆栈，就不用管它，调试Dump和运行程序不一样，缺少一两个DLL没有任何问题。

3、  如果真的需要怎么办？

符号文件现在主要是指PDB文件。

如果没有符号文件，那么调试的时候可能导致堆栈错误。

如果你丢失了这个发布版本中你编译出来的那些exe和DLL的PDB，那么这个损失是严重的，重新编译出来的版本是不能使用的。

我自己的DLL都有了，可是缺的是系统的DLL的对应PDB文件怎么办？图1.4中已经介绍了方法。微软在它的符号数据库上为我们提供了所有的PDB文件，还有部分非关键DLL。设置好后程序将自动下载需要的PDB及DLL文件。

4、  拿到需要的文件了，这些文件应该放在哪里？

符号数据库中的文件不用动，把其它的exe和DLL、PDB文件放在dump文件目录里就行了。

5、  我用的是VS2005，明明有源代码，为什么显示不了？

这个是dump调试的最头痛问题，代码可能已经改过了，即使你从SVN拿到当时的版本，时间戳也是错的，VS2005就是不让你显示代码。其实只要在

Tools\Options，Debugging\General中去掉

Require source files to exactly match the original version的复选就行了。

前言：之前介绍了利用VS2005进行Dump文件的调试，功能非常强大。但VS2005是一个大程序，本文将讨论利用NTSD的Command Line 实现Dump 文件的调试。

1、  载入DMP格式文件

利用CMD打开命令行窗口，切换到NTSD所在目录。利用命令载入DMP文件：

ntsd –z dumpfileName –y symbolPath –srcpath sourcecodePath

dumpfileName：DMP格式文件路径

symbolPath：PDB文件路径

sourcecodePath：程序的源代码路径

如图1.1，若载入成功，将弹出一个NTSD窗口，如图1.2。

图1.1 载入DMP格式文件

图1.2 NTSD界面

红色的圈中显示了BUG的原因，函数IsPrefix 存在错误。0x36是错误相对于函数的偏移值。这个错误是一个Access Violation的异常，异常地址为00401036。

Note：

l  若路径中存在空格，需要用在路径前后加上引号。

l  若提示错误，根据提示查看是否由于dbghelp.dll不存在导致，安装的调试工具包中存在该动态库。

2、  定位与源代码

利用如下命令可以定位错误到源代码中：

lsp  –a 500

lsa  .

第一行命令用于设置显示的源代码行数，第二行命令将错误定位与错误行。如图：

图1.3 Analysis Result: Line of Source Code Causing Crash

从图中可以看出，第13号是导致程序错误的位置。如果希望看到变量的值，使用命令：

x

若需要详细查看某个变量的值，使用命令：

??  variableName

图1.4 Analysis Result: Value of Variable Causing Crash

Module Address of Your Application(显示程序模块地址)

Command:

x *!

图1.5 Application Module Information

It shows all the module address in your application.

Crash Stack Trace（显示程序调用堆栈）

If you want to trace the stack of application, use this command:

Command:

kb

图1.6 Application Stack Trace

It shows that function main invokes function IsPrefix then application crashes.

For more commands of NTSD, refer to debugger.chm in Microsoft Debugger Tools package.

1、  打开Dump格式文件

打开WinDbg，通过菜单[File] à [Open Crash dump] 选择dump文件打开，也可通过CMD打开Dos命令窗口，切换到WinDbg所在目录，利用命令：

WinDbg –z “D:\Lines2009-7-25-22-20-33-900.dmp”

-z表示路径

图1.1 利用WinDbg打开dump文件

载入dump文件显示如图：

图1.2 WinDbg界面

2、  分析dump文件

若生成的dump文件在本机，dump文件中将包含调试需要的PDB文件及源代码路径，若不在本机，可以通过WinDbg菜单[File] à [Symbol File path] 及 [Source File Path] 分别设置PDB文件路径和源代码路径。如果程序涉及到DLL，需要将EXE、DLL所有涉及的PDB、源代码路径都包括。使用命令：

!analyze –v

将分析dump文件，并显示程序崩溃处于的代码行：

图1.3 分析dump 文件

如果你的程序什么都不干. 那么在程序出错的时候. drwtsn32.exe 会写一个 userdump. 但 drwtsn32 有些缺点. 比如只能写一个 dump 文件. 后面的崩溃写 dump 文件时会覆盖前面的. win2000 下的 drwtsn32 只能写旧式的 dump 文件(往往尺寸比较大). 有一篇文章论述的比较清楚:
 http://www.debuginfo.com/articles/ntsdwatson.html

建议使用 ntsd 代替 drwtsn32. 但 ntsd 的缺点就是需要安装最新的 windbg. 这是一个硬伤. 在看了 debuginfo.com 的另一篇文章:
 http://www.debuginfo.com/articles/effminidumps.html
 
之后, 我选择的是在程序出错的时候调用 api 自己写 minidump. 克服了 drwtsn32, ntsd 的缺点.
将封装好的函数放到了一个头文件中, 包含即可. 使用的方法很简单:

#include <windows.h>
#include "minidump.h"
LONG __stdcall MyUnhandledExceptionFilter(PEXCEPTION_POINTERS pExceptionInfo)
{
CreateMiniDump(pExceptionInfo, "c:\\user.dmp");
return EXCEPTION_EXECUTE_HANDLER;
}

void main()
{
SetUnhandledExceptionFilter(MyUnhandledExceptionFilter);
*(int*)0=0; // AV
}

这样就好了. 注意安装至少 xp 以上的 sdk.
这里用到了一个 api SetUnhandledExceptionFilter(), 如果不明白可以搜一下 msdn.
运行例子程序出错退出之后, 就得到了 c:\\user.dmp. 可以用 windbg 等调试器来分析了. 

代码从这里下载 http://nicoster.googlepages.com/minidump.rar

（1）       调用abort函数，并且设置了_CALL_REPORTFAULT选项（这个选项在Release版本是默认设置的）。

（2）       启用了运行时安全检查选项，并且在软件运行时检查出安全性错误，例如出现缓存溢出。（安全检查选项 /GS 默认也是打开的）

（3）       遇到_invalid_parameter错误，而应用程序又没有主动调用

_set_invalid_parameter_handler设置错误捕获函数。

所以结论是，使用VS2005（VC8）编译的程序，许多错误都不能在SetUnhandledExceptionFilter捕获到。这是CRT相对于前面版本的一个比较大的改变，但是很遗憾，Microsoft却没有在相应的文档明确指出。

解决方法

       之所以应用程序捕获不到那些异常，原因是因为新版本的CRT实现在异常处理中强制删除所有应用程序先前设置的捕获函数，如下所示：

 /* Make sure any filter already in place is deleted. */

 SetUnhandledExceptionFilter(NULL);

 UnhandledExceptionFilter(&ExceptionPointers);

解决方法是拦截CRT调用SetUnhandledExceptionFilter函数，使之无效。在X86平台下，可以使用以下代码。

#ifndef _M_IX86

       #error "The following code only works for x86!"

#endif

void DisableSetUnhandledExceptionFilter()

{

    void *addr = (void*)GetProcAddress(LoadLibrary(_T("kernel32.dll")),

                                                         "SetUnhandledExceptionFilter");

    if (addr)

    {

              unsigned char code[16];

              int size = 0;

              code[size++] = 0x33;

              code[size++] = 0xC0;

              code[size++] = 0xC2;

              code[size++] = 0x04;

              code[size++] = 0x00;

               DWORD dwOldFlag, dwTempFlag;

              VirtualProtect(addr, size, PAGE_READWRITE, &dwOldFlag);

              WriteProcessMemory(GetCurrentProcess(), addr, code, size, NULL);

              VirtualProtect(addr, size, dwOldFlag, &dwTempFlag);

       }

}

在设置自己的异常处理函数后，调用DisableSetUnhandledExceptionFilter禁止CRT设置即可。

其它讨论

       上面通过设置api hook，解决了在VS2005上的异常捕获问题，这种虽然不是那么“干净”的解决方案，确是目前唯一简单有效的方式。

       虽然也可以通过_set_abort_behavior(0, _WRITE_ABORT_MSG | _CALL_REPORTFAULT), signal(SIGABRT, ...), 和_set_invalid_parameter_handler(...) 解决（1）（3），但是对于（2），设置api hook是唯一的方式。