WWE明星.docVIP

WinCE下异常捕获方法 WinCE系统下应用崩溃原因的分析方法 做为程序员，最怕什么？Bug？大家都清楚，调试期的 Bug 并不可怕，那怕是那些神龙见首不见尾的 INT(随机、没有规律) Bug。 做为嵌入式程序员，也是一样的。一般来说嵌入式系统都提供了异常分析的方法，特别是强大的调试工具，这些工具使用在 PC 上编程使用的工具是一样的，例如：Visual Studio 系列。但是一些专用的、或小的嵌入式系统，可能会提供专用的调试工具。虽然从功能上来说，没有微软提供的 VS 功能强大，使用起来也不太方便，但也会提供类似的调试功能。这里我主要讨论的还是微软提供的工具。 目前，在车载与 PND 市场，使用 WinCE 系统的比较多。在 WinCE6.0 系统中，如果应用发生较严重的错误时，一般都会弹出系统标准的、令人十分讨论的应用错误对话框。大概提示：XXX.exe出现严重错误，必须被关闭。 如何解决此类问题呢？ 只要能接上调试串口，或与调试工具连接，如VS2008等，获取出错时的异常信息后，就可以来分析异常可能的原因。 但如果设备已经处于量产状态，无法连接输出 LOG 的串口和调试 USB 口时，如何能捕捉到异常信息呢？ 在无法彻底解决此类问题的情况下，有人就想能不能不让系统显示那个错误对话框。为了能使应用“优美”的退出(网络上的说法)，即程序退出时不出现述的错误对话框，有人曾试着去修改 WinCE 提供的内核代码，但这部分应该是属于未开源的部分。所以此方法也行不通的！ 解决此类问题的根本办法当然是提高编码的质量，然后加强质量保证（即测试），尽量将 Bug 消灭在研发阶段。因为研发阶段，有大量的调试工具可以使用，如下述的第一种方法。 在没有调试工具可以依赖时，有没有办法获取到异常信息呢？方法当然是有的，如下述第二种和第三种方法。为什么要说第一种方法呢，因为它提供的信息是最基础的，是后面两种方法都要用到的基础。在这这里，我重点推荐第三种方法。因为它的处理比较独立、在 WinCE 系统中比较有效、且方便集成到已有代码中，实现异常捕获。 第一种方法：如果有输出 LOG 串口可说时，串口输出的异常信息，加 MAP 文件一起分析错误的出处，可以到函数一级。所以要求在调试时一定要将对应版本的 MAP 文件一起保留，用于后继异常问题的分析。 对于如下的测试代码： void TestCrashFunc(void) { int *pNullPoint = NULL; RETAILMSG(1,(L-----------------------------%d\r\n,pNullPoint)); *pNullPoint = 0; RETAILMSG(1,(L-----------------------------%d,%d\r\n,pNullPoint,*pNullPoint)); } void CallCrashFunc(void) { TestCrashFunc(); } void CSmartDeviceMFCDlg::OnTimer(UINT_PTR nIDEvent) { // TODO: 在此添加消息处理程序代码和/或调用默认值 if(1 == nIDEvent) { KillTimer(1); CallCrashFunc(); // 其它的功能 } CDialog::OnTimer(nIDEvent); } 串口输出的内容与下面 WinCE7.0 的基本是相同的。 在 WinCE6.0 和 WinCE7.0 下运行时，串口的输出内容基本上是相同的，但在 WinCE7.0 下没有出错的对话框。 串口中输出的 Crash 信息如下： Exception Data Abort (0x4): Thread-Id=0780000a(pth=c08e24e0), Proc-Id=077e000a(pprc=c088da7c) SmartDeviceMFC.exe, VM-active=077e000a(pprc=c088da7c) SmartDeviceMFC.exe PCSmartDeviceMFC.exe+0 RA=4002ac4c(coredll.dll+0x0001ac4c) SP=0004f6a8, BVAException Raised Exception (0x116): Thread-Id=0780000a(pth=c08e24e0), Proc-Idpprc=8360b5e0) NK.EXE, VM-active=077e000a(pprc=c088da7c) SmartD