atceedsun的专栏

有关Windows异常处理与MiniDump的系列文章:异常处理与MiniDump详解(1) C++异常异常处理与MiniDump详解(2) 智能指针与C++异常异常处理与MiniDump详解(3) SEH（Structured Exception Handling） 异常处理与MiniDump详解(4) MiniDump

原文地址：http://blog.sina.com.cn/s/blog_48f93b530100fxvm.html根据前面两篇博文，我们要定位崩溃行代码，必须要自己根据相关信息文件进行计算。如果需要处理的量比较大，恐怕会很费力气。有没有更简单快速的办法呢？最直接的想法就是写一个小工具，根据规则和信息进行自动定位，不过开发起来也是要费一番功夫的。令人开心的是，我们可以找到类似的工具，

原文地址：http://blog.sina.com.cn/s/blog_48f93b530100fzwt.html前面几个方案都是直接定位crash的代码位置，但是在比较大型的程序中，只知道这个信息还是远远不够的，我们希望知道更多关于调用函数顺序及变量值等信息，也就是crash时调用堆栈信息。方案四：SetUnhandledExceptionFilter + StackWalk

1、在现场设置程序崩溃时的自动内存转储，得到dump文件       在windows 注册表如下项：     //HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/AeDebug     中提供了调试器的相关设置。      Debugger  设置具体的调试器和启动参数

原文地址：http://blog.sina.com.cn/s/blog_48f93b530100fv7y.html上篇给出的方案一还要补充几句。通过“crash地址 + MAP文件”来定位出错代码位置虽然需要经过比较复杂的地址计算，但却是最简单实现的方式。如果仅仅想通过崩溃地址定位出错的函数，就更加方便了。我在网上找到一个解析MAP文件的小工具，可以非常清晰的列出每个函数的地址，并且可

原文地址：http://blog.sina.com.cn/s/blog_48f93b530100g282.html当我们把自己的release版本程序发布出去以后，一般都是在用户的机器上运行。这种情况下，对于第四种方案，因为需要pdb文件才能够正确生成堆栈调用的函数行号及代码行号，因此方案四只适用于本地release版的调试，否则只能生成不完整的堆栈信息。对于前三种方案，其实只需要用户

原文地址：http://blog.sina.com.cn/s/blog_48f93b530100g52i.html上一篇我们已经给出了方案，能够非常方便的通过dump文件对crash错误进行调试和定位；从整个流程上看还差最后一步，即怎样拿到crash时产生的dump文件。如果可以让用户把文件发送过来自然不错，但对于类似免费共享软件等在互联网上发布的程序呢？我们的用户是不确定的，而且用户