-1

我们有一个非托管 C++ 应用程序（MFC 框架，Windows CE），它在看似随机的时刻关闭我们。

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

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

问题：是否有可能在 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 窗口给出以下错误：Unable to Connect to ''.）
  • 重新定位应用程序，使其在常规 x86 PC 上运行（但随后运行良好，因此也没有“奢侈”的调试问题）

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

平台：在德州仪器处理器 (ARM A8) 上运行的 MS Windows Embedded Compact 7.02。

应用程序本身实现了一个基本的 VNC 查看器。它使用套接字并依赖名为 zlib CE ( ) 的第三方二进制文件ZLIBCE.DLL来解压缩 VNC 数据。

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

4

1 回答 1

0

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

于 2018-10-01T19:25:55.300 回答