跟踪一个BUG的过程中,发现一个BUG的真正原因有时甚至比找出问题的解决方法更为重要,更麻烦.WINCE是一个很庞杂的系统,很多问题一开始根本无从下手,而一旦找到问题的本质,BUG也就迎刃而解了.
首先,我们需要对WINCE系统各个模块的功能,相互关系有一个基本的认识.例如,存储系统包括块设备的驱动程序,文件系统及分区管理模块.块设备驱动程序只负责读取/写入数据,对数据的内容一概不闻不问,在这个意义上讲如果应用程序读取一个文件与读取一个目录时的表现不一致,则应该先检查文件系统,而不是查驱动程序.我知道一个BUG,在WINCE4.2上,CDROM中无法读取一个子目录下的内容,即属于这个问题,根据我对CE存储系统的理解,很快就找出了问题所在. 但有时,我们不能太过相信经验,比如,我查过一个BUG,我的系统在从网络共享中拷贝文件时很慢,所以我测试了FTP,后者很正常,据此我认为是CE自身的问题,但后来跟踪的结果是我的网卡驱动引发的.但我认为,先检查FTP的状况这个做法本身没有问题,问题在于我没有继续深入调查.
其次,我们要利用调试工具,KITL就是很不错的一个,如果我们的硬件在某种情况下对时序要求并不是很严格,就可以使用KITL,比如硬盘,当DRQ信号产生以后,在数据读完之前,DRQ一直存在,数据不会丢失,串口就不是很适合这种方法,当FIFO underrun中断发生时,如果我们不及时处理,还在用KITL单步跟踪,接下来的传输就会步法大乱.
还有,要注意每一个细节,尤其是调试信息,我们可以在代码中一次多找印一些信息,这样就能比较快的找出问题,更重要的是要注意系统输出的信息.一旦看到一个不知何处输出的信息时,不用紧张,我们可以搜索一下它在哪个文件中,一般可以先根据我们所调试的模块而大概确定那些代码在什么地方,如果对WINCE的源码结构不是很清楚也没关系,实在不行,我们可以在WINCE的根目录下搜索.
最后,注意输出信息,output窗口的信息也极为重要