求大牛帮我看看这个服务crash的具体原因，谢谢

[zemelaoshi]

我写了一个监控服务程序在客户那边跑，这一阶段不停地出现crash，于是我就拿crash产生的dump文件进行分析，但是发现crash的位置并没有在我的服务程序里面，到网上查是未捕获的异常，请问这个该如何分析具体原因。PS：因为以前我拿dump文件分析，crash的位置都会出现在我的代码里面，这次很奇怪居然没有。

[赵4老师]

崩溃的时候在弹出的对话框按相应按钮进入调试，按Alt+7键查看Call Stack里面从上到下列出的对应从里层到外层的函数调用历史。双击某一行可将光标定位到此次调用的源代码或汇编指令处。

[zemelaoshi]

引用 14 楼 zhao4zhong1 的回复:

崩溃的时候在弹出的对话框按相应按钮进入调试，按Alt+7键查看Call Stack里面从上到下列出的对应从里层到外层的函数调用历史。双击某一行可将光标定位到此次调用的源代码或汇编指令处。

谢谢您上面给出写日志的一些好的习惯，很感激。 我后来自己又下载了一些系统符号文件(.pdb)，终于看到更具体的call stack的执行过程，发现出错在我exe调用的dll里面。但是我dll当时编译的符号文件又没有保存，dll倒是有，后来通过源码重新产生新的符号文件，然后通过工具ChkMatch.exe修改了pdb的时间戳使其匹配，然后进行调试，终于定位到问题出错的位置，调用的boost库的方法： boost::filesystem::remove_all( path_ ); // remove entire directory; 很奇怪里面的path_ 是一个乱码"婱靸罷铏"，所以造成了异常，但是至于为啥乱码就不清楚了。 还是很感激大神的帮助啊，很感谢！！

[shiguojie19892]

引用 15 楼 zemelaoshi 的回复:

[quote=引用 14 楼 zhao4zhong1 的回复:] 崩溃的时候在弹出的对话框按相应按钮进入调试，按Alt+7键查看Call Stack里面从上到下列出的对应从里层到外层的函数调用历史。双击某一行可将光标定位到此次调用的源代码或汇编指令处。

谢谢您上面给出写日志的一些好的习惯，很感激。 我后来自己又下载了一些系统符号文件(.pdb)，终于看到更具体的call stack的执行过程，发现出错在我exe调用的dll里面。但是我dll当时编译的符号文件又没有保存，dll倒是有，后来通过源码重新产生新的符号文件，然后通过工具ChkMatch.exe修改了pdb的时间戳使其匹配，然后进行调试，终于定位到问题出错的位置，调用的boost库的方法： boost::filesystem::remove_all( path_ ); // remove entire directory; 很奇怪里面的path_ 是一个乱码"婱靸罷铏"，所以造成了异常，但是至于为啥乱码就不清楚了。 还是很感激大神的帮助啊，很感谢！！[/quote] 赵老师有赚到了

[zemelaoshi]

大神们今天都外出不在？

[Cnwanglin]

指针跑飞了?

[Cnwanglin]

dump也不一定都能定位到错误发生的地方 实在不行做个debug版本放服务器上

[zemelaoshi]

debug版本可以定位错误发生的位置吗？可以讲解的详细一点吗？

[zemelaoshi]

引用

dump也不一定都能定位到错误发生的地方 实在不行做个debug版本放服务器上

debug版本可以定位错误发生的位置吗？可以讲解的详细一点吗？

[zemelaoshi]

引用 3 楼 Cnwanglin 的回复:

dump也不一定都能定位到错误发生的地方 实在不行做个debug版本放服务器上

debug版本可以定位错误发生的位置吗？可以讲解的详细一点吗？

[勤奋的小游侠]

引用 18 楼 zhao4zhong1 的回复:

我看是楼主赚到了吧。

你也赚了不少。

[赵4老师]

引用 15 楼 zemelaoshi 的回复:

[quote=引用 14 楼 zhao4zhong1 的回复:] 崩溃的时候在弹出的对话框按相应按钮进入调试，按Alt+7键查看Call Stack里面从上到下列出的对应从里层到外层的函数调用历史。双击某一行可将光标定位到此次调用的源代码或汇编指令处。

谢谢您上面给出写日志的一些好的习惯，很感激。 我后来自己又下载了一些系统符号文件(.pdb)，终于看到更具体的call stack的执行过程，发现出错在我exe调用的dll里面。但是我dll当时编译的符号文件又没有保存，dll倒是有，后来通过源码重新产生新的符号文件，然后通过工具ChkMatch.exe修改了pdb的时间戳使其匹配，然后进行调试，终于定位到问题出错的位置，调用的boost库的方法： boost::filesystem::remove_all( path_ ); // remove entire directory; 很奇怪里面的path_ 是一个乱码"婱靸罷铏"，所以造成了异常，但是至于为啥乱码就不清楚了。 还是很感激大神的帮助啊，很感谢！！[/quote] 会在path_变量上设置内容改变数据断点吗？ 参考下面：

#include <time.h>
#include <stdlib.h>
#include <windows.h>
int main() {
    int a,b[11];//本来是b[10]，为判断哪句越界，故意声明为b[11]

    srand((unsigned int)time(NULL));//按两次F11，等黄色右箭头指向本行时，调试、新建断点、新建数据断点，地址：&b[10]，字节计数：4，确定。
    while (1) {//按F5，会停在下面某句，此时a的值为10，b[10]已经被修改为对应0..4之一。
        b[(a=rand()%11)]=0;
        Sleep(100);
        b[(a=rand()%11)]=1;
        Sleep(100);
        b[(a=rand()%11)]=2;
        Sleep(100);
        b[(a=rand()%11)]=3;
        Sleep(100);
        b[(a=rand()%11)]=4;
        Sleep(100);
    }
    return 0;
}

[赵4老师]

我看是楼主赚到了吧。

[abcerikkk123456]

[我看你有戏]

版本是否一直，pdb 各个库是否一致啊 数组越界有可能捕获不到地方，估计把函数栈都搞乱了所以就看不到了

[wu4357815]

引用 4 楼 zemelaoshi 的回复:

debug版本可以定位错误发生的位置吗？可以讲解的详细一点吗？

可以看看我的博客 如何通过map文件轻松找到崩溃的代码行（注意要是debug版本） http://blog.csdn.net/wu4357815/article/details/25690577

[zemelaoshi]

引用 17 楼 zhao4zhong1 的回复:

[quote=引用 15 楼 zemelaoshi 的回复:] [quote=引用 14 楼 zhao4zhong1 的回复:] 崩溃的时候在弹出的对话框按相应按钮进入调试，按Alt+7键查看Call Stack里面从上到下列出的对应从里层到外层的函数调用历史。双击某一行可将光标定位到此次调用的源代码或汇编指令处。

谢谢您上面给出写日志的一些好的习惯，很感激。 我后来自己又下载了一些系统符号文件(.pdb)，终于看到更具体的call stack的执行过程，发现出错在我exe调用的dll里面。但是我dll当时编译的符号文件又没有保存，dll倒是有，后来通过源码重新产生新的符号文件，然后通过工具ChkMatch.exe修改了pdb的时间戳使其匹配，然后进行调试，终于定位到问题出错的位置，调用的boost库的方法： boost::filesystem::remove_all( path_ ); // remove entire directory; 很奇怪里面的path_ 是一个乱码"婱靸罷铏"，所以造成了异常，但是至于为啥乱码就不清楚了。 还是很感激大神的帮助啊，很感谢！！[/quote] 会在path_变量上设置内容改变数据断点吗？ 参考下面：

#include <time.h>
#include <stdlib.h>
#include <windows.h>
int main() {
    int a,b[11];//本来是b[10]，为判断哪句越界，故意声明为b[11]

    srand((unsigned int)time(NULL));//按两次F11，等黄色右箭头指向本行时，调试、新建断点、新建数据断点，地址：&b[10]，字节计数：4，确定。
    while (1) {//按F5，会停在下面某句，此时a的值为10，b[10]已经被修改为对应0..4之一。
        b[(a=rand()%11)]=0;
        Sleep(100);
        b[(a=rand()%11)]=1;
        Sleep(100);
        b[(a=rand()%11)]=2;
        Sleep(100);
        b[(a=rand()%11)]=3;
        Sleep(100);
        b[(a=rand()%11)]=4;
        Sleep(100);
    }
    return 0;
}

[/quote] dump文件不好再进行数据断点调试了吧？现在正在分析原因，感觉这个变量被释放了一样。

[zemelaoshi]

引用 22 楼 wu4357815 的回复:

[quote=引用 4 楼 zemelaoshi 的回复:] debug版本可以定位错误发生的位置吗？可以讲解的详细一点吗？

可以看看我的博客 如何通过map文件轻松找到崩溃的代码行（注意要是debug版本） http://blog.csdn.net/wu4357815/article/details/25690577[/quote] 有时间学习一下，谢谢

[zemelaoshi]

引用 21 楼 henry3695 的回复:

版本是否一直，pdb 各个库是否一致啊
数组越界有可能捕获不到地方，估计把函数栈都搞乱了所以就看不到了

都已经一致了，call stack都完整显示了。
给你看下。

[赵4老师]

不要忘了，“完整正确显示Call Stack的符号”不是目的。 参考《你的灯还亮着吗？》

[赵4老师]

引用 22 楼 wu4357815 的回复:

[quote=引用 4 楼 zemelaoshi 的回复:] debug版本可以定位错误发生的位置吗？可以讲解的详细一点吗？

可以看看我的博客 如何通过map文件轻松找到崩溃的代码行（注意要是debug版本） http://blog.csdn.net/wu4357815/article/details/25690577[/quote] 远不如通过查找错误位置附近的几个字节在dll或ocx或exe中的位置。