Windbg 调试程序崩溃问题（转）

https://bbs.pediy.com/thread-217260.htm

配置好PDB路径
先!analyze  -v，确定线程是哪个
打开堆栈窗口，这一步配好源文件路径
再.ecxr      恢复堆栈，这时候堆栈窗口应该可以看到崩溃时的正确堆栈
在堆栈窗口选择显示源文件和源文件参数
最好用最新的windbg，5月份出品的，windeb10.0.15063.173版本以后的版本
如果栈没有被破坏，则一般this指针显示的内容比较正常，如果被破坏，显示的是不可访问地址，则一般是栈内溢出导致。
  ExceptionCode:  80000003    一般不是代码自己生成的dmp，而是手工导出dmp的int  3断点之类的。这时候的故障线程是不准的，搜索所有线程，找到KERNELBASE!UnhandledExceptionFilter    这类异常处理，基本上就是这个线程除了问题，然后切换到这个线程，然后再运行.ecxr，恢复堆栈，继续查找问题。
如果是new出来的溢出，则用全堆检查工具即可，这类工具较多，gflags、debug  diag、application  verifier都可以启动堆安全检查，如果是栈内溢出，则前面的工具就不够用了，如果是在自己代码之内，我知道vs开发，在debug模式的工程属性的代码生成页面启用“两者(/RTC1，等同于  /RTCsu)  (/RTC1)”，通过debug调试可以探知到栈内数组越界、字符串越界等更细致的安全检查。另外无论debug还是release版本，都可以用内存操作安全函数操作在，这样一旦越界就可以探知。例如memcpy用memcpy_s等，百度memcpy_s  c++安全函数就可以搜索到20多个安全替换函数，这才是安全之本，否则release对越界的探知能力无法覆盖栈内溢出。

一般对于this或栈被破坏的dmp，一般能力的人分析可能用处不大，因为局部变量和返回栈都被破坏了，看到的很多是虚假的，所以最好的办法就是启用全堆检查，如果有debug版本，最好debug启用最好的栈检查，这样配合前面的堆检查就可以更准确的复现现场位置错误，而不是过了很久才表现出来崩溃的位置。
如果不能很好的复现，则debug  diag是监控机器人，则可以很好的监控，并在程序崩溃的时候导出dmp（最好给debug  diag配上符号文件，这样打印的log就会很准）。如果自己能够添加代码，则最好在代码里带上崩溃自动导出dmp的功能，这样才能及时形成dmp，虽然位置不准，但是在对应的线程输入.ecxr即可恢复对应堆栈。