Windows Embedded Compact（Windows CE）程序的事后分析

Question

我们有一个不受管理的C ++应用程序（MFC框架，Windows CE），它似乎在随机的时刻关闭了我们。

没有错误消息，也没有C ++异常，它消失了。

我认为一定有不好的事情发生了，并且C运行时或OS决定终止该程序。但是我不确定在哪里继续搜索。

问题：是否有可能在Windows CE中的某个地方为什么首先终止应用程序？

Windows CE是否收集基本的崩溃信息？也许然后至少可以看到是由于访问冲突，内存不足情况，内核/驱动程序紧急情况还是其他某种导致应用程序关闭的内部或外部事件？

在一台普通的x86 PC上，人们会破坏调试器，应用程序验证程序，Windows错误报告工具，WinDbg等。但是如何（开始）分析Windows CE应用程序崩溃？

到目前为止，我已经尝试过：

• 在应用程序的战术位置创建全局C ++异常处理程序。它们构建并传输包含最少异常信息的简单UDP数据包。然后在运行Wireshark的另一台计算机上查看这些内容。
• 添加SEH异常编译器开关（/EHa），以甚至能够捕获那些非C ++异常，例如访问冲突等。
• 通过TCP / IP将Visual Studio 2008调试器与智能设备连接（成功连接到智能设备，MSVS表示，但是调试器看不到任何远程进程。Attach to process VS窗口给出以下错误：{ {1}}。）
• 重新定位应用程序的目标，使其可以在常规的x86 PC上运行（但随后运行正常，因此也就没有“豪华”的功能可以在此调试问题了）

我已经通过强制执行访问冲突测试了异常处理程序。 预期的UDP消息将完美到达运行Wireshark的计算机。但是，当真正的问题发生时，它会保持完全沉默。

平台：运行在Texas Instruments处理器（ARM A8）上的MS Windows Embedded Compact 7.02。

应用程序本身实现了基本的VNC查看器。它使用套接字，并依赖于称为zlib CE（Unable to Connect to ''）的第三方二进制文件解压缩VNC数据。

尚未验证是否针对完全相同的编译器（和/或编译器设置）构建了zlib二进制文件。

Answer 1

为穷人的调试解决方案而定。现在将应用程序状态值发送到内存映射文件。这个想法是，特制的帮助程序会沿着主应用程序运行。该程序将打开内存映射文件，并显示从中读取的值。然后主程序将其写入。如果主应用程序发生任何致命事故，则帮助程序将具有最新状态信息。由于它是共享内存，因此不会对性能产生太大影响。这样就可以找到程序中发生故障的部分。