19,503
社区成员
发帖
与我相关
我的任务
分享如何用WinDbg或Waston Dump Viewer分析WinCE机台上抓取的Dump File问题
基于ARM+WinCE 5.0的机台上有概率性的发生Data Abort，直接采用加入Debug信息逐步缩小范围的方法太费时间，所以在Image中加入了ErrorReporting的功能。
机器发生了Data Abort后，将dump file拷贝出来，就是那个后缀名为kdmp的文件。在PC机上使用WinDbg进行分析的时候可以找到发生Data Abort的类型，但是无法在定位出源代码中的位置。
第一次使用WinDbg工具，很多东西不是很清楚，希望大家在这里讨论一下，在线等待大家的回答。
只要参与就有分相送，^_^，如果分数不够还可以再加！
机器发生了Data Abort后，将dump file拷贝出来，就是那个后缀名为kdmp的文件。在PC机上使用WinDbg进行分析的时候可以找到发生Data Abort的类型，但是无法在定位出源代码中的位置。
第一次使用WinDbg工具，很多东西不是很清楚，希望大家在这里讨论一下，在线等待大家的回答。
只要参与就有分相送，^_^，如果分数不够还可以再加！
...全文
请发表友善的回复…
发表回复
Sniper167 2010-02-07
- 打赏
- 举报
MARK 如此好的贴
guopeixin 2008-12-26
- 打赏
- 举报
谢谢大家一个多月来的讨论，通过大家的的讨论，虽然没有找到特别好用特别简单的方法，但是也了解了一下做WinCE同行的一些调试方法，分虽然少了些，但是重在参与嘛，^_^。
总结了一下，大家目前用到的方法主要有：
1. SHE结构化异常处理方法；
2. 利用发生异常的时候CE的异常处理打印的Dbg信息中的PC，到Map文件中去定位，并一步一步寻找到出问题的函数；
3. 纯粹利用Debug信息进行调试的方法；
4. hzdysymbol兄提到,用DumpBin.exe将源程序进行汇编处理，到汇编代码中进行定位，由于小弟愚笨，暂时还没有学会使用，哈哈。
再次感谢大家。
总结了一下，大家目前用到的方法主要有：
1. SHE结构化异常处理方法；
2. 利用发生异常的时候CE的异常处理打印的Dbg信息中的PC，到Map文件中去定位，并一步一步寻找到出问题的函数；
3. 纯粹利用Debug信息进行调试的方法；
4. hzdysymbol兄提到,用DumpBin.exe将源程序进行汇编处理，到汇编代码中进行定位，由于小弟愚笨，暂时还没有学会使用，哈哈。
再次感谢大家。
guopeixin 2008-12-25
- 打赏
- 举报
1. 如果已经安装过VS2005，打开C:\Program Files\Microsoft Visual Studio 8\VC\bin
2. 从Dos下进入该目录并运行vcvars32.bat
3. 此时可以运行dumpbin.exe了，但是接下来传什么参数呢？
2. 从Dos下进入该目录并运行vcvars32.bat
3. 此时可以运行dumpbin.exe了，但是接下来传什么参数呢？
gooogleman 2008-12-25
- 打赏
- 举报
[Quote=引用 32 楼 hzdysymbol 的回复:]
晕，最近好忙，年纪大了，学习新东西感觉特辛苦
我简单在这里介绍一下用法吧：
1。看Data abort的Message，确定是哪个DLL或EXE出错
2。在Release目录下面运行Dumpbin,把相应的文件反汇编，Dumpbin用法可以查帮助，dumpbin -h吧
3.用编辑工具打开反汇编生成的文件，相看Data Abort时出错的地址
这时候就可以看到是在哪一个函数里面了
应该很简单吧
[/Quote]
你的意思是说PB6.0才能用了，PB5.0就不行了，因为5.0和VS是分离的啊。
晕，最近好忙，年纪大了，学习新东西感觉特辛苦
我简单在这里介绍一下用法吧：
1。看Data abort的Message，确定是哪个DLL或EXE出错
2。在Release目录下面运行Dumpbin,把相应的文件反汇编，Dumpbin用法可以查帮助，dumpbin -h吧
3.用编辑工具打开反汇编生成的文件，相看Data Abort时出错的地址
这时候就可以看到是在哪一个函数里面了
应该很简单吧
[/Quote]
你的意思是说PB6.0才能用了，PB5.0就不行了，因为5.0和VS是分离的啊。
hzdysymbol 2008-12-25
- 打赏
- 举报
晕，最近好忙，年纪大了，学习新东西感觉特辛苦
我简单在这里介绍一下用法吧：
1。看Data abort的Message，确定是哪个DLL或EXE出错
2。在Release目录下面运行Dumpbin,把相应的文件反汇编，Dumpbin用法可以查帮助，dumpbin -h吧
3.用编辑工具打开反汇编生成的文件，相看Data Abort时出错的地址
这时候就可以看到是在哪一个函数里面了
应该很简单吧
我简单在这里介绍一下用法吧：
1。看Data abort的Message，确定是哪个DLL或EXE出错
2。在Release目录下面运行Dumpbin,把相应的文件反汇编，Dumpbin用法可以查帮助，dumpbin -h吧
3.用编辑工具打开反汇编生成的文件，相看Data Abort时出错的地址
这时候就可以看到是在哪一个函数里面了
应该很简单吧
gooogleman 2008-12-25
- 打赏
- 举报
[Quote=引用 29 楼 hzdysymbol 的回复:]
VS带的工具
也就是反汇编
直接把DLL反汇编出来,查一下Data Abort的地址,就可以确定出错的函数
[/Quote]
关于Dumpbin有更详细的资料么？
hzdysymbol 老兄，能不能写篇博客给大家分享一下。？
VS带的工具
也就是反汇编
直接把DLL反汇编出来,查一下Data Abort的地址,就可以确定出错的函数
[/Quote]
关于Dumpbin有更详细的资料么？
hzdysymbol 老兄，能不能写篇博客给大家分享一下。？
guopeixin 2008-12-25
- 打赏
- 举报
关于Dumpbin有更详细的资料么？
hzdysymbol 2008-12-23
- 打赏
- 举报
VS带的工具
也就是反汇编
直接把DLL反汇编出来,查一下Data Abort的地址,就可以确定出错的函数
也就是反汇编
直接把DLL反汇编出来,查一下Data Abort的地址,就可以确定出错的函数
gooogleman 2008-12-23
- 打赏
- 举报
[Quote=引用 27 楼 hzdysymbol 的回复:]
出DataAbort后为什么不用简单的Dumpbin反汇编查一下,我一般都是这样定位到哪一个函数,接下来查就相对比较简单了
[/Quote]
呜呜，这个我都不知道怎么用，hzdysymbol 这个Dumpbin是PB自带的工具？怎么弄的？
出DataAbort后为什么不用简单的Dumpbin反汇编查一下,我一般都是这样定位到哪一个函数,接下来查就相对比较简单了
[/Quote]
呜呜，这个我都不知道怎么用，hzdysymbol 这个Dumpbin是PB自带的工具？怎么弄的？
hzdysymbol 2008-12-23
- 打赏
- 举报
出DataAbort后为什么不用简单的Dumpbin反汇编查一下,我一般都是这样定位到哪一个函数,接下来查就相对比较简单了
guopeixin 2008-12-23
- 打赏
- 举报
现在是小有进展，对于Image本很身的Crash File可以通过Windbg来进行分析，如同楼上很多朋友讲的，需要配合pdb文件进行分析，最终可以定位到特定的代码行。
但是对于AP里面的发生异常产生的Crash Dump File，目前还是没有办法进行分析，正在研究中。
但是对于AP里面的发生异常产生的Crash Dump File，目前还是没有办法进行分析，正在研究中。
pilixuanke 2008-12-22
- 打赏
- 举报
[Quote=引用 21 楼 gooogleman 的回复:]
引用 19 楼 guopeixin 的回复:
引用 11 楼 BEYONDMA 的回复:
WinDbg还真没在ＣＥ下用过这个东东，一般都是打ＬＯＧ来ＤＥＢＵＧ：）帮顶！
^_^，我也这么用
你现在也没有搞定？
不少人使用：自己加一个SEH捕获一下异常，把crash信息输出，再利用编译器生成的map文件定位崩溃代码区间，我一直这样用感觉不错
的方法。我还没有尝试过呢。
[/Quote]
貌似这种方法有的崩溃抓不了，不过自己没有试过，不敢瞎说！
有知道的XD给正一下视听。
呵呵、、
引用 19 楼 guopeixin 的回复:
引用 11 楼 BEYONDMA 的回复:
WinDbg还真没在ＣＥ下用过这个东东，一般都是打ＬＯＧ来ＤＥＢＵＧ：）帮顶！
^_^，我也这么用
你现在也没有搞定？
不少人使用：自己加一个SEH捕获一下异常，把crash信息输出，再利用编译器生成的map文件定位崩溃代码区间，我一直这样用感觉不错
的方法。我还没有尝试过呢。
[/Quote]
貌似这种方法有的崩溃抓不了，不过自己没有试过，不敢瞎说！
有知道的XD给正一下视听。
呵呵、、
singlerace 2008-12-19
- 打赏
- 举报
看我博客文章：http://blog.csdn.net/singlerace/archive/2008/07/15/2655154.aspx
fan227 2008-12-19
- 打赏
- 举报
下回也试试这种调试方法！
wohuazhen 2008-12-18
- 打赏
- 举报
SEH结构化异常处理
看过这样的代码，我也没用过，顶一下。
__try
{
}
__finally
{
}
之类。
看过这样的代码，我也没用过，顶一下。
__try
{
}
__finally
{
}
之类。
gooogleman 2008-12-18
- 打赏
- 举报
[Quote=引用 19 楼 guopeixin 的回复:]
引用 11 楼 BEYONDMA 的回复:
WinDbg还真没在ＣＥ下用过这个东东，一般都是打ＬＯＧ来ＤＥＢＵＧ：）帮顶！
^_^，我也这么用
[/Quote]
你现在也没有搞定？
不少人使用：自己加一个SEH捕获一下异常，把crash信息输出，再利用编译器生成的map文件定位崩溃代码区间，我一直这样用感觉不错
的方法。我还没有尝试过呢。
引用 11 楼 BEYONDMA 的回复:
WinDbg还真没在ＣＥ下用过这个东东，一般都是打ＬＯＧ来ＤＥＢＵＧ：）帮顶！
^_^，我也这么用
[/Quote]
你现在也没有搞定？
不少人使用：自己加一个SEH捕获一下异常，把crash信息输出，再利用编译器生成的map文件定位崩溃代码区间，我一直这样用感觉不错
的方法。我还没有尝试过呢。
guopeixin 2008-12-18
- 打赏
- 举报
[Quote=引用 8 楼 navi_dx 的回复:]
自己加一个SEH捕获一下异常，把crash信息输出，再利用编译器生成的map文件定位崩溃代码区间，我一直这样用感觉不错
[/Quote]
是呀，这样确实是挺简单，也比较方便，我也经常这么用。
最近想找一种更加简单，更加准确的方法，因为代码量比较大的时候，这样做起来就比较复杂了。
^_^，共同学习了，等有了进展就给大家加分，只要参与就有分，分不够可以再加！
自己加一个SEH捕获一下异常，把crash信息输出，再利用编译器生成的map文件定位崩溃代码区间，我一直这样用感觉不错
[/Quote]
是呀，这样确实是挺简单，也比较方便，我也经常这么用。
最近想找一种更加简单，更加准确的方法，因为代码量比较大的时候，这样做起来就比较复杂了。
^_^，共同学习了，等有了进展就给大家加分，只要参与就有分，分不够可以再加！
guopeixin 2008-12-18
- 打赏
- 举报
[Quote=引用 11 楼 BEYONDMA 的回复:]
WinDbg还真没在ＣＥ下用过这个东东，一般都是打ＬＯＧ来ＤＥＢＵＧ：）帮顶！
[/Quote]
^_^，我也这么用
WinDbg还真没在ＣＥ下用过这个东东，一般都是打ＬＯＧ来ＤＥＢＵＧ：）帮顶！
[/Quote]
^_^，我也这么用
guopeixin 2008-12-18
- 打赏
- 举报
[Quote=引用 14 楼 pilixuanke 的回复:]
我再回复一下吧。希望能发上去。[这回学乖了，在编辑器中输好了才Copy过来的]
我在PC机上使用过WinDbg，但不知这种方法是否适用CE系统，LZ帮我验证一下吧，呵呵：
步骤如下
1. 在Release版本中添加调试信息。
2. 在程序中加入ErrorReporting崩溃处理代码，生成崩溃文件。
3. 打开WinDbg，设置好符号路径，然后打开崩溃文件。使用!analyze -v命令来分析崩溃时的情况。
一般也就是看看崩溃线程的堆栈情况。
…
[/Quote]
经验之谈呀，我也觉得是自己没有把符号给整好导致没有办法分析最终的log信息
我再回复一下吧。希望能发上去。[这回学乖了，在编辑器中输好了才Copy过来的]
我在PC机上使用过WinDbg，但不知这种方法是否适用CE系统，LZ帮我验证一下吧，呵呵：
步骤如下
1. 在Release版本中添加调试信息。
2. 在程序中加入ErrorReporting崩溃处理代码，生成崩溃文件。
3. 打开WinDbg，设置好符号路径，然后打开崩溃文件。使用!analyze -v命令来分析崩溃时的情况。
一般也就是看看崩溃线程的堆栈情况。
…
[/Quote]
经验之谈呀，我也觉得是自己没有把符号给整好导致没有办法分析最终的log信息
xqhrs232 2008-12-18
- 打赏
- 举报
[Quote=引用 2 楼 91program 的回复:]
没有用过，帮顶
学习这种调试方法
[/Quote]
同样学习一下，看来高手很多啊！
没有用过，帮顶
学习这种调试方法
[/Quote]
同样学习一下，看来高手很多啊！
加载更多回复（13）
