如何诊断Windows CE的应用程序崩溃 .
2012-05-15 23:27
169 查看
singlerace大侠大作~
无论你是一个单纯的电脑用户还是一名高级软件工程师,都一定对程序崩溃不陌生。做为一名Windows CE应用程序开发者,你也一定遇到过下图这种场景:
这个对话框告诉你,有一个叫installer.exe的程序在地址00019320处崩溃了。如果这个程序归你负责,那么你的问题就来了:怎么找出这个BUG?这篇文章我想谈谈我在这方面的一些经验。
Windows CE的崩溃界面给出的信息十分的少,其中最有用的无疑是崩溃地址,如果你能从崩溃地址定位到源代码去,这个问题可以说就解决了一半。
从地址定位到源代码的方法有几种。一种是利用MAP文件:你可以在BUILD程序时生成MAP文件。MAP文件是一个文本文件,其中主要记录了各个函数入口对应的地址信息。比如这个例子中,崩溃地址对应的入口是:
[Csharp]
view plaincopyprint?
0001:000082f4 ??1?$CComPtr@UIImage@@@ATL@@QAA@XZ 000192f4 f i ImageViewer.obj
除了PC和RA,其他信息也可以提供一些参考作用:BVA是ARM中的Fault Address Register(FAR),是引起Data Abort的虚拟地址,比如说你的程序试图访问一个非法地址里的内容,那么Data Abort时BVA就是这个非法地址;FSR是Fault Status Register,指明导致异常的原因,FSR的解释可以看这里。要注意的是Thread和Proc给出的不是Thread
Id/Thread Handle或者Process Id/Process Handle,它们给出的是该Thread或Proc对应的内核对象的指针,类似于Window NT平台的TEB和PEB的概念。由于你看到崩溃信息时线程已经退出了,因此根据这个信息在事后你无法知道是哪个线程出的错。以后我将介绍一种系统级的logging机制,这种机制可以把每条log的Thread Id、TEB等信息同时记录下来,这样在崩溃时就可以根据Data Abort的TEB信息和先前log中出现的TEB,找到出错的线程。这样,你不但可以定位到错误的源代码,还能找到运行错误代码的线程,将大大提高解决问题的效率。
无论你是一个单纯的电脑用户还是一名高级软件工程师,都一定对程序崩溃不陌生。做为一名Windows CE应用程序开发者,你也一定遇到过下图这种场景:
这个对话框告诉你,有一个叫installer.exe的程序在地址00019320处崩溃了。如果这个程序归你负责,那么你的问题就来了:怎么找出这个BUG?这篇文章我想谈谈我在这方面的一些经验。
Windows CE的崩溃界面给出的信息十分的少,其中最有用的无疑是崩溃地址,如果你能从崩溃地址定位到源代码去,这个问题可以说就解决了一半。
从地址定位到源代码的方法有几种。一种是利用MAP文件:你可以在BUILD程序时生成MAP文件。MAP文件是一个文本文件,其中主要记录了各个函数入口对应的地址信息。比如这个例子中,崩溃地址对应的入口是:
[Csharp]
view plaincopyprint?
0001:000082f4 ??1?$CComPtr@UIImage@@@ATL@@QAA@XZ 000192f4 f i ImageViewer.obj
[Csharp] view plaincopyprint? Data Abort: Thread=8d661000 Proc=81a477c0 'installer.exe' AKY=00000401 PC=00019320(installer.exe+0x00009320) RA=00019094(installer.exe+0x0 0009094) BVA=16080100 FSR=00000007 Data Abort: Thread=8d661000 Proc=81a477c0 'installer.exe' AKY=00000401 PC=00019320(installer.exe+0x00009320) RA=00019094(installer.exe+0x0 0009094) BVA=16080100 FSR=00000007我相信Windows CE开发者一定也对这几行信息很熟悉。怎么利用这些信息诊断程序的问题?这里面最关键的信息是PC和RA给出的地址信息。PC就是上面提到的崩溃地址,根据这个地址用CrashFinder或者我的Remote Process Explorer里的Crack Address界面可以定位到导致崩溃的源代码行;RA是PC的返回地址(Return Address),根据这个地址可以找到导致崩溃的上一级函数,这个信息也很重要,因为很多时候崩溃的原因往往是上层函数往底层函数传递了非法参数导致的,比如你的应用程序用一个非法的窗口类调用MFC函数,崩溃地址在MFC函数里面,但是出问题的地方在你的调用代码里。下图是RA地址对应的源代码:
除了PC和RA,其他信息也可以提供一些参考作用:BVA是ARM中的Fault Address Register(FAR),是引起Data Abort的虚拟地址,比如说你的程序试图访问一个非法地址里的内容,那么Data Abort时BVA就是这个非法地址;FSR是Fault Status Register,指明导致异常的原因,FSR的解释可以看这里。要注意的是Thread和Proc给出的不是Thread
Id/Thread Handle或者Process Id/Process Handle,它们给出的是该Thread或Proc对应的内核对象的指针,类似于Window NT平台的TEB和PEB的概念。由于你看到崩溃信息时线程已经退出了,因此根据这个信息在事后你无法知道是哪个线程出的错。以后我将介绍一种系统级的logging机制,这种机制可以把每条log的Thread Id、TEB等信息同时记录下来,这样在崩溃时就可以根据Data Abort的TEB信息和先前log中出现的TEB,找到出错的线程。这样,你不但可以定位到错误的源代码,还能找到运行错误代码的线程,将大大提高解决问题的效率。
相关文章推荐
- 如何诊断Windows CE的应用程序崩溃
- 如何诊断Windows CE的应用程序崩溃
- 如何诊断Windows CE的应用程序崩溃
- 转:如何诊断Windows CE的应用程序崩溃
- 如何诊断Windows CE的应用程序崩溃(续)
- 如何诊断Windows CE的应用程序崩溃
- 如何诊断Windows CE的应用程序崩溃(转载)
- 如何诊断Windows CE的应用程序崩溃
- 如何诊断Windows CE的应用程序崩溃(续)
- 如何诊断Windows CE的应用程序崩溃(续) (转载)
- 如何诊断Windows CE的应用程序崩溃
- 如何诊断Windows CE的应用程序崩溃(续)
- 如何诊断Windows CE的应用程序崩溃(续)
- 如何诊断Windows CE的应用程序崩溃
- 如何诊断Windows CE的应用程序崩溃
- WINCE下如何诊断应用程序崩溃
- 如何将崩溃信息整合到应用程序-基础知识
- 如何编写Windows CE结构的应用程序
- 如何用WinDbg帮你诊断应用程序或系统故障
- windows系统如何设置应用程序崩溃自动内存转储